Systems Engineering Patterns

Interesting Pattern Books

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.

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.