Why patterns for Systems Engineering? What are Systems Engineering patterns? These are a few topics that will be discussed on this blog. This blog is directed by Dr. Robert Cloutier of Stevens Institute of Technology.
Read More >>
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
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.
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.
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.
Seems anytime I begin to talk about patterns and systems engineering, someone in the audience will ask me if I have looked at TRIZ (pronounced Trees). While I am aware of what TRIZ is, I have never really done an indepth look at what it could offer - until now. TRIZ is an approach to inventive problem solving - that is to say, it is a methodology with 40 principles to help the inventor invent something new to address a problem. Sounds like a similar selling point for patterns - a collection of proven approaches to solving a problem, that might be useful in solving a similar problem. So now I have begun looking at TRIZ deeper to see what it offers. I have found two books that seem to be pretty good at helping one learn TRIZ, without attending a dedicated seminar. The first was written by the inventor of TRIZ, Genrich Altshuller, and has been translated into english (did I mention this was invented by a Russian?). First published in 1997, and updated in 2005, it is simply titled "40 Principles". The second book caught my attention because I am a fan of Da Vinci. The book is "Da Vinci and the 40 Answers". While both look like "lightweight" books, both require thought - real thought - to understand the approach. However, I firmly believe this is worth the effort. I will keep you posted. Finally, I would be remiss if I did not mention the Altshuller Institute, as they are a wealth of information, including a monthly eJournal.
I am always reading, looking for interesting books on patterns, systems architecture, and related bopics. Sometimes I find the books, sometimes they are recommend to me. I have come across a couple of books that may be of use to systems engineers interested in patterns. One is old, one is new - one I found, and another was recommended to me by one of my students.
"Patterns of Home" is a beautiful coffee table book. Two of the three authors (Max Jacobson, Murray Silverstein, and Barbara Winslow) studied under Alexander, and were collaborators with him on his book "A Pattern Language". It is beautifully illustrated, and covers the what the authors consider the top 10 enduring patterns for the home. Why do I care about this as a systems architect? I am glad you asked. As systems engineers/architects, I believe there is much we can learn from other disciplines, and should learn. For instance, one of their patterns is called "Parts in Proportion". The pattern is all about balance, and that each of the major parts are balance as part of the whole. When we architect systems, my experience says that systems with a well balanced architecture - functions and capabilities evenly distributed across balanced subsystems, perform best. In this pattern, the authors discuss "a well ordered cluster of forms". Good systems architecture is one that results in a well ordered cluster of functionality. Many times this results in simplified interfaces. While I have not made it all the way through the book, I do plan on using parts of it to teach/discuss the use of patterns in systems engineering.
The second book is new, and is brought to us by Mary Lynn Manns and Linda Rising. Fearless Change: Patterns for Introducing Change is about changing organizations. If you are not familiar with the software patterns history, Linda Rising was very involved in that movement while she was at AT&T. While I have not found this book as useful for actual pattern ideas, the patterns presented are a wealth of knowledge if you are trying to introduce consepts like patterns or systems modeling to your organization. Had this book been around a decade ago, I would likely have fewer scars from organizational process battles. It is worth your time if you are a change agent.
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.
During my
research, I have interviewed many systems engineers from around the world that implicitly use patterns
during their systems engineering work. Most of these systems engineers have over 15 years experience. It should not surprise anyone that the number one concern they expressed regarding the use of patterns is to manage the interfaces. Interestingly, not a single pattern form that I have come across addresses the issue of interfaces. This probably is a result of the patterns published to date are pretty simple and straightforward, and interfaces are not that critical. As we move into an era of mining and publishing patterns for more complex systems, the interfaces become more important.
Therefore, one of the most significant contributions to pattern work
that was not discussed much to date is the need to spend time discussing the
interfaces. This should come as no surprise to systems engineers since that is
where many of us live – and where many of us have had our headaches.
Using
patterns for complex systems patterns must address the interfaces. Therefore
this recommended SE
pattern form includes a discussion on interfaces. Additionally, interfaces
should be addressed in the sketch. The sketch can even be an IDEF or SysML
model extract if that makes the pattern more understandable. In a later post, I
will post an example of a complex pattern called Perform Command and Control,
or Perform C2.
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.
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.