Zane Scott, Vitech Vice President of Professional Services
Often our mistakes do not result from failing to understand the nuances of complex aspects of our problems. Instead, they are a result of becoming too comfortable with the fundamentals of our processes. That is exactly why athletic teams who experience a slump in performance return to a focus on the basic skills that undergird their execution.
The same is true in our systems engineering practice. Unless we understand and practice the fundamentals of our craft, we will be led into costly mistakes. To see how this works, let us revisit some fundamental concepts and then identify the mistakes that can emerge from not treating these concepts seriously.
Just what is a system?
INCOSE’s definition of a system contains three aspects common to most, if not all, of the rigorous definitions of a system. Under these definitions, a system involves different elements arranged in a construct such that they produce results not possible for any of the elements alone.
A system may be viewed from either an external or internal perspective. The external view looks at the system in its context. It depicts the system’s interactions with the environment. In contrast, the internal view of the system focuses on the internal working of the system and its processes. The dividing line between external and internal is the system boundary.
Understanding the boundary is a critical design consideration. Most often we are free to design inside the boundary but not outside. We develop the system side of the interfaces and interactions across the boundary, but must adapt them to the system context. Therefore, it is important to know the location and nature of the boundary.
The fundamental task of engineering
By aggregating an understanding of the internal and external functionality of the system solution, we are able to proceed with the fundamental task of engineering – creating and maintaining systems to accomplish their purposes efficiently and effectively.
As we look at the elements and their interactions, we must be cognizant of their properties and characteristics (otherwise known as “attributes”). We assign values to the attributes. Where the attribute values are constant for a significant period of time, the system status is called a “state.” Changes in state reflect changes in attribute values. The values can be altered by the system processes within a “domain” of values. This works through the interaction of the elements within the relationships established by the system construct – causing the attribute values to change over time, which then causes the system states to evolve.
Emergent aspects of behavior
The product of the evolution of system states is the dynamic behavior of the system. The emergent aspects of that behavior, which can’t be understood as the linear product of constituent behavior, are often critical to the functionality of the system.
This understanding is basic – perhaps to the point of tediousness. So why review it? It is surprising how often and in how many ways this fundamental understanding is forgotten, ignored, or even intentionally contradicted.
In designing or working with systems, we inform our work with a representation of the system of interest. The adequacy of this representation is the key to understanding the functionality of the system, particularly the dynamic and emergent behavior of the system. The foregoing discussion of system fundamentals provides a working description of what it takes to construct such a representation.
The importance of a robust model
Despite this, we often choose to work from less than adequate representations. Instead of a robust model that tracks elements, relationships, and attributes across dynamic behavior within well-defined boundaries, we substitute limited models targeted to other purposes and miss the real value of system modeling. Sometimes we are tempted to adopt fragmented models consisting of a collection of snapshots of the system but incapable of providing either a comprehensive portrait of the system or any picture of its dynamic behavior.
Another self-imposed limitation comes through the use of tools designed to construct databases of particular classes of design information, such as requirements or physical architecture. The effect is the same as fragmenting the representation into snapshots. The loss is the integration of the representation in the model leading to a loss of insight.
In other instances, we focus on physical performance models that offer information about the performance of individual system components or subsystems. These fragmented representations also do not provide insight into the integrated system that is critical to system understanding.
Whether the system is fragmented into snapshots, particular classes of design information, or limited performance models, the end result is the same. The model completely misses an opportunity to gain the insight that comes from a focus on an integrated and complete fundamental representation of the system. By ignoring the fundamental concepts of the nature and characteristics of our system, we limit our capability for understanding and insight.
Like a football team that loses sight of blocking and tackling, we get caught up in nuance and miss the value of our fundamentals. There is a price for that, and we pay it with our customers’ money.
The bad news is that that price is unnecessary. The good news is that it is avoidable. That is the reason that Vitech has adopted a schema and tool structure that provides for a fully integrated system model. Our approach and solution offer the true insight that comes from a fully integrated view.
