Many pattern communities that have emerged seem to have many patterns identified and documented. Yet, the systems engineering community seems slow in identifying and documenting patterns. It seems that many systems engineers are interested in the topic. I have been the guest speaker at a number of different venues to discuss patterns. So while the interest seems high, the follow-through seems weak. I have given this a lot of thought, and over the next few postings will offer some possible reasons for this – especially as it relates to patterns for complex systems/architectures.
Challenge 1: The rule-of-three
Within the patterns community there is the notion of the “rule-of-three”. Basically this pattern states that something is not a pattern unless one can identify 3 or more instances of the solution to really identify it as a pattern. Within the software community, or business process community for instance, there are large code bases, and a large number f companies implementing the same business process which can be mined for patterns.
However, as the systems grow larger and more complex, there are fewer of them which can be mined. And, some number of those systems will have limited design reuse. So, why is this important? While the rule-of-three may work for domains that create considerable opportunity for patterns in successful applications, the rule-of-three may not be as useful in the systems engineering pattern domain. Maybe it is sufficient to have two instances of success instead of three. What do you think?
Next time, we will look at the value and challenge of documenting some patterns which too simplistic.