In a previous post, Three Systems we have discussed the existence of three systems around any system design or improvement project. In every such project we deal with the system we are designing or improving, the context system in which it will live and the system we use to execute the design or improvement project itself. The third system is the one we use to understand and solve the system problems we encounter. Unfortunately that system, the system we use to do our work, is often orphaned or forgotten. Only rarely do we devote much intentional effort toward its design.
As we discussed in our All Systems Engineering Is Model-Based post, it is not possible to design or improve a system solution without using a model. The only way we can conceive of a design problem, its possible system solutions and then discuss our conception is through the use of a model. Most often this model resides in our mind. We developed a mental picture of the system solution we are considering from which we drive our design activities.
When we work collaboratively each member of the team must do the same thing. As our work progresses we each hold in our minds a separate model of the problem and its possible solutions. We attempt to align our models by communicating their scope and shape to each other using pictures, graphs, tables and written descriptions. The quality of our solution will ultimately be based on our ability to create and use a pool of shared understanding about the problem and our design alternatives.
We have traditionally organized our work teams around the four classic systems engineering domains: requirements, behavior, architecture and verification and validation. We create teams within each of those domains charged with advancing the design within the domain. Very early on we have recognized that a given domain team can most effectively collaborate if their model of the domain can be surfaced and maintained in a tool.
In response to this need a variety of domain specific tools has been created. For example, in the requirements domain there are several tools which handle requirements in tabular form relating the requirements to each other through a numbering system or hierarchy. This allows the requirements team to develop, derive and track the system requirements as the project design is advanced. The tool helps the team by centralizing the requirements in a single visible model (the table). Any misalignment becomes easy to spot and the team can realign itself using the tool.
The same thing has taken place in the other domains. A typical design project arranged in this way uses four or more different tools. This results in four or more conceptions (models) of the system solution. While the use of domain specific tools helps to align the teams within the domains, it does not produce a single model around which the teams can align. At best the broader team is forced to deal with four different models of the system solution design.
Just as a number of individual mental models means that the owners of those models must attempt to communicate their particular conception with their fellow collaborators, the existence of four domain specific system solution models leaves the teams in the position of having to communicate team – to – team regarding their models. The lack of a single coherent model of the system solution means that the problem of alignment on a single solution remains intact.
The issue at stake here is the development of a pool of shared understanding around the system problem and its possible solutions. Dividing the team into domain specific sub teams with domain specific tools producing domain centric conceptions of the problem and solutions does not address the creation of this pool of shared understanding at the system design level. While aligning the teams within themselves is a good step in the direction of creating a shared pool of understanding about the domain, it results in, at best, four separate understandings which still must be aligned in order to create an effective solution to the problem which drives the design or redesign effort.
The partial success of the domain specific tools does, however, point to the broader answer. If a requirements tool aligns the requirements team around a common understanding of their domain then a systems design tool which incorporates all of the domains into a single coherent and complete design will serve to align the broader team. This is the goal of tools like CORE and GENESYS.
These tools provide the alignment and shared understanding of the systems design that we are seeking. There is at the root of this a subtle shift in the theory behind the design of the design process – the forgotten system. Instead of seeing the design effort as the sum of the work of four separate teams the use of a true systems design tool is based on seeing the design team as an integrated whole.
Some tool systems have attempted to approach this unified team concept by marrying together domain specific tools. They linked together a requirements tool and architecture tool and attempt to make the transfer of information between them as easy as possible. But these tools suites do not really address the fundamental issue of seeing the design and the design effort as a single integrated and coherent whole. No matter how well Tool A talks to Tool B they are still dealing with two separate conceptions of the design. Their system designs remain the sum of four or more domain specific efforts. Good tool-to-tool communication helps but it has nowhere near the potential of a fully integrated design.
By carrying the concept of integration beyond the level of the domain specific team we can integrate the entire system solution design process into a single coherent effort. This will allow us to create a pool of shared understanding around the system problem and any potential solutions. That leads directly to a common understanding of the problem and its ultimate solution. No longer will our design system be the forgotten system. Based on the power of integration it will become an effective means of producing high-quality system solutions.
