Systems Engineering Patterns

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.

Patterns for systems architecting and systems engineering

I have been studying and working on this topic since 2002. I was first introduced to the concept of patterns some friends that were software engineers working on a large defense program. Our goal was to use software design patterns to improve software quality by using consistent designs in UML, and thereby, consistent implementations across many of the different subsystems. Even our complex UML diagrams representing our software architecture began to take on recognizable attributes across the different subsystems.

Most people in the software pattern community attribute Christopher Alexander as the first to formalize and articulate the concept and value of patterns. Throughout the 60's and 70's Alexander, a civil architect, worked to improve on the art of urban design by discovering and documenting patterns that other architects could use.

 It began to dawn on me that the concept could be abstracted to the systems engineering level, whereby systems with common goals may have common architectural attributes captured in a UML model and that those commonalities could be captured and documented as patterns. Since then, there have been a number of articles appearing in professional journals, and conference papers and presentations discussing complex patterns for systems engineering. This blog has been created to support this growing body of systems engineers interested in the topic.

I am interested in your thoughts and experiences mining and using patterns in systems engineering. Welcome to the discussion.