The Nine Laws of Effective Systems Engineering Redux – Part I

Some time ago we posited nine “laws” of effective systems engineering, first in a white paper and then in a webinar which has been posted to You Tube. After some 41,000 views in six years with a number of comments and critiques, we thought it worthwhile to revisit the laws from today’s vantage point. It seems best to do this in three posts, so we will begin with the first three.

Law #1 – Begin with the End in Mind
Having stated that it is critical to identify and focus on the “end,” we must remember that the customer’s value proposition is the end to which everything else is the means. It is tempting to focus on developing the system specification as the end. Likewise, we are often tuned in to the design process itself. Diagrams and models tend to assume center stage in our view. But, even developing the system design isn’t our end. All of these are means to the real end of meeting the customer’s needs without introducing unintended consequences.

The only reason to satisfy the requirements is that those requirements are the expression of the customer’s needs. That is why we need to get the requirements right. They become the beacon that allows us to navigate to the meeting of the customer’s needs. When good requirements are truly satisfied, customers and stakeholders alike will truly benefit from the solution.

That is not to say we shouldn’t pay attention to the means by which we reach the end. (Law 9 will remind us there are always three systems that figure in our design quest—one of which is our design process.) We must not only be effective (with solutions that satisfy the needs), but we must be efficient as well. Our design process should converge on a solution to the customer’s problem. This must happen with an eye to cost, schedule and quality. But the end must guide us from needs to satisfaction.

Law #2 – It Doesn’t Help to Solve the Wrong Problem 
Russell Ackoff, business management professor and systems thinker, said it best, “We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem.” The danger is that the process of seeking a solution must be pointed at the right problem in order to solve it, and any failure to understand what that problem is will cause the process to be off the mark. Yogi Berra was right when he observed that, “If you don’t know where you are going, you will wind up someplace else.”

The first job in any systems engineering effort is to come to a shared understanding of the problem—not necessarily the problem as cast by the requirements statements, but the real problem. If nothing else, this requires the technique of asking the “five whys” to uncover the thinking behind the requirement statements that will form the understanding of the problem. This understanding allows the construction of requirements statements that fairly depict the solution needed for the customer’s real problem.

Surfacing those requirements is critically important in aligning the design team around a shared understanding of the right problem. The customer and the team can see, understand and plan from a common point of departure. That beginning provides an assurance of the best possible chance of solving the right problem.

Law #3 – Insight Is the Goal
Systems engineering seeks to shed light on the problem and by so doing illuminate the path to solution. Along the way, design choices must be made, and again, it is the job of the systems engineer to provide light by which to make these choices. Good information feeding a good process leads to insight, and insight leads to better choices. This is the power of systems engineering.

But getting that insight can be easier said than done. This is particularly true with complex problems and solutions, where the essence of the system results is in the relationships. The ways in which the elements of the solution system are tied together yield the behaviors that solve the problem under consideration. The Italian sociologist Vilfredo Pareto called the ability to see this “emergence” in a new combination the essence of creativity. Creative or “speculative” people as he termed them, are “constantly preoccupied with the possibilities of new combinations.” Building these combinations is what Einstein called “combinatory play.”

Engaging in fruitful combinatory play calls for insight into the possible combinations and their likely outcomes. This is where having a model of the design can be extremely helpful. Models allow us to unambiguously capture and communicate our understanding. Models provide a mechanism to reflect reality in such a way as to focus on the critical dimensions. Models enable us to coherently reason about the problem and the solution in a way that isn’t possible in the abstract.

In order to be useful, the model must be based in a metamodel that imparts structure and meaning to the model. It is through this semantic meaning that we can see the combinations and their results. This is the insight needed for effective systems engineering.

The metamodel allows for the integration of the design across all domains:

• Requirements
• Functional behavior
• Physical architecture
• Validation and verification across the system lifecycle

The metamodel captures the elements, their relationships and their attributes across all domains. This is the key to insight from the model.

A fully integrated model based on a strong metamodel framework offers the insight into the problem and solution that is necessary for success. This means that the model cannot be fragmented, sacrificing integration. A collection of views does not offer an integrated model of the system. Nor do view-based data dictionaries. Only the fully integrated model offers the necessary insight.

In our next installment, we will discuss Laws 4-6. (Law #4: The Model Is the Main Thing; Law #5: To Catch (Design) a System You Have to Think Like One; and Law #6: It’s All about Relationships). See you then!