Systems Engineering Patterns

Reference Architectures

More and more, the topic of reference architectures is crossing my workspace. A recently published article*  in the INCOSE Systems Engineering Journal was well received. In many ways, reference architecture are like system architecture pattrerns, though they provide more guidance, may be strongly based or influenced by standards, and my be driven by industry. I will begin blogging more on reference architectures in the future.

*Cloutier, Robert, Gerrit Muller, Dinesh Verma, Roshanak Nilchiani Eirik Hole & Mary Bone, The Concept of Reference Architectures, INCOSE SE Journal, Volume 13 Issue Number 1, ISSN: 1098-1241, p. 14-27, January 2010

Mining patterns

What is meant when it is said that patterns are mined? For the software community, that means actually looking at code, and finding the essence across multiple implementations. But what does it mean to mine a pattern for a system level pattern? At the hightest level, the pattern may be so abstract it is meaningless. Aircraft systems, for the most part, have a fuselage, wings, tail, and landing gears (hopefully). Not very useful. But what other system level patterns can be found? What are the common missions; or sub-missions? What does it mean to document the "transport passengers" operational pattern as opposed to "perform high altitude observation" operational pattern? The differences between those two patterns will affect the decomposition of the system as it is architected. What about the "perform maintenance" operational pattern that captures that mission for the two different types of aircraft? Something to consider.

The Challenges of System Patterns

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.

The Challenges of System Patterns

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.

  

A Perform Command and Control Pattern

Patterns are not invented or created from a clean sheet of paper. The term normally equated with patterns is that they are mined from previously successful implementations. The Perform Command and Control (Perform C2) pattern was first implemented successfully as the logical architecture, and then reused in later projects with similar requirements. In fact, most of the logical architecture was reusable, though some of the terminology had to be changed for the new customer domain. A year later, a mid-grade architect assigned to a similar project and his mentor told him about this previous work.

The two architects went back to the earlier project models, and used them to guide the future logical architecture. Soon after this, these architects found out about my research in systems engineering patterns. We went back and mined the logical architecture in all 3 systems. Each was documented using IDEF diagrams, which made the effort a bit easier. Using the SE pattern form discussed last time, the Perform C2 pattern was documented and published.

When mining patterns of this nature, it is recommended the pattern author generalize the inputs and outputs into terminology that may be more meaningful for the individual wanting to reuse the pattern. For instance, “battle damage assessment” may be simplified to “damage assessment”, or even simply “assessment”.

When using the pattern for a new implementation, study the requirements and decide which interfaces are needed, and which are missing. If an interface is not necessary, delete it when you implement the pattern (be sure to trace it through the pattern to remove all traces). If a new interface is needed for the specific domain implementation, feel free to add it to the implementation.

I am in the process of developing a separate website for systems engineering patterns. The site is found at http://www.patterns4SE.com and it will allow others to submit patterns to be shared with the broader systems engineering community. I am interested in your thoughts and feedback, and how we can provide a greater service to the SE community.

What is a Pattern Form?

I received an email the other day from someone interested in how to actually use patterns in their systems engineering work. Systems engineers are coming across pattern discussions, but most are documented using using Christopher Alexander’s straightforward pattern form – a problem, a context, and a solution.

Patterns are typically documented using some form. Think of a form as a template for documenting patterns so there is a consistency of information across multiple patterns. While this The problem with expressing a pattern in this simplistic form is that while it is useful for identifying a pattern, it tends to look more like a heuristic. However, it does not serve the real benefit of engineering patterns – helping the next person to implement the pattern. Documenting a pattern requires putting yourself in the position of the person using your pattern. Try to express the pattern in broader terms, and give specifics.

In a later post, I will discuss the SE Pattern form which resulted from my research, and provide some examples of patterns documented using this form.