In any system design project there are always three systems of importance. The first of these is what we call the system of interest or the solution system. That is the system we intend to design. (Note: For the purposes of this discussion, the name “system of interest” may be somewhat misleading in that it can create the impression we are not interested in the other two systems. For that reason, I have chosen to use the term “solution system” instead. Regardless of the name, it should be clear at the conclusion of our consideration here that we are very much interested in all three.)
The second system is a system we always know exists, but often we do not take enough time to include it in our modeling effort. This system we refer to as the context system. This is the system where the problem we are solving currently lives and where the solution system will live once introduced.
The third system is the one we rarely consider directly. This is the system we use to design the solution system (the first system) that will address the problem arising in the context system (the second system). Although we recognize this is a very important system, very few ever think about it to the extent of intentionally “designing” it. We adopt specific practices and build our skills in particular areas of the design process, but we rarely consider this process from a systemic point of view. By ignoring this system, we can suffer as surely as we suffer from neglecting either of the other two systems.
In a sound model-based systems engineering approach, we begin our look at any system to be modeled at a high level of abstraction where the system under consideration is treated as a “black box” with inputs and outputs. From there we consider the boundary within which we will build the system. Then we begin to examine the system in the context of each of the four domains: requirements, behavior, the physical or implementation architecture, and validation and verification. Once we have considered each of the four domains, we advance the design by increasing the level of detail, thus moving it to a lower level of abstraction and closer to a full specification. This approach allows us to maintain a disciplined look at our design in which we can make our design choices in an intentional way.
Good systems engineers habitually proceed in this way with any design they undertake. The application of a disciplined, layered approach to the system under design becomes almost instinctual for the experienced systems engineer. To a somewhat lesser extent, systems engineers also think systemically and intentionally about the context system. Just as the system of interest is created layer by layer, the context system can be examined and discovered in the same manner. This can be quite helpful in locating the system problem within its context. It is also helpful to the determination of the system boundary definition for the solution system.
Our concern here is the application of this structured and disciplined thinking to the design of the system we use to solve our system problems—the oft-neglected third system.
Recognizing, as we should, the importance of a disciplined approach to creating our design process system, we should begin at the highest level to address it. Our starting point is the recognition that its purpose is to provide for an ordered process for designing the solution system. The good news is the very process we have been discussing above is the framework for the third system.
The idea is to use that framework as we add detail in the process design. First, we would undertake to study the context system and the problem that lives in it. If we short-change that effort, we will fail to adequately understand the problem itself. Without addressing the problem and its place in the context system as an integral part of our third-system process, we will miss much of what we need to know about the adequacy of our first-system design candidate solutions and the constraints that affect them. It is also important to understanding the requirements that the stakeholders facing the problem will articulate around their original initiative in kicking off the design project. Gaining that understanding of the problem should be instantiated into our third-system process design.
The process should be defined as a set of behaviors that will accomplish the analysis of the problem, the gathering of the stakeholder requirements, the generation and analysis of the logical (functional) architecture, the creation of implementation architectures to perform the behavior, and the validation and verification of the candidate solutions. Along the way, the process should provide for capturing all of these elements in full relationship to each other through the use of model-based systems engineering based in a robust tool designed for that purpose.
The design of the engineering process can be approached in either of two related ways. The first is through using the typical “systems” architecture approach, casting the elements of the process in “systems” terms: requirements, functions, components, etc. The other approach is to view these same elements as comprising an “operational” architecture and thinking of them in the terms of an architectural framework like the Department of Defense Architectural Framework (DoDAF) where requirements are denoted as “capabilities,” functions as “operational activities,” and components as “performers.”
Vitech’s Operational and System Schemas
As is clear in the above figure, the fundamental structure is the same either way. In one (the right side), components perform functions which satisfy the requirements on which they are based. In the other (the left side), performers perform operational activities which are based on required capabilities. The road signs are different along the way, but the journey to delivering the required performance is the same.
The critical task is to make, rather than ignore, the journey to an intentional design of the design process itself considering all the elements in full relationship to each other and how they will interact to accomplish their purpose—achieving the robust and effective design of the best solution to the problem at hand. Rather than forgetting this critical system, we can then treat it as worthy of reflection and design at the same level and with the same care as its two siblings. Then it will no longer be the forgotten system, but will become the system of interest for its own design effort.
