Challenge 2: Some System Patterns Seem Simplistic on the Surface
I have found that the patterns community is still evolving in regards to what constitutes a good pattern. The 253 patterns documented in Christopher Alexander’s A Pattern Language contained 5 common headings as part of the pattern: Name, Example, Context, Problem, and Solution. While this form works well for many patterns, it is not very useful for many patterns.
For instance, let us look at a powered aircraft system architecture pattern. At the highest level the aircraft has a fuselage, lift surfaces (wings, tail, and ailerons), landing gears, and a power plant. Why bother documenting that? The obvious reason is that differentiates a fixed wing aircraft from a rotary wing (helicopter) aircraft – or maybe a tilt rotor aircraft. Where the more interesting aspects lie are at the next level of decomposition (whether you are doing a functional decomposition, scenario decomposition, object oriented decomposition, or any other approach, the argument is the same). This may be one of the differentiators between system/system architecture patterns and other patterns. My experience is that at the system/system architecture level, patterns are not very useful with a single graphic/model. It normally requires at least two levels of detail for it to be useful in another implementation.
Comments