Systems engineering can be characterized by many dualities – architecture and analytics, process and innovation, technical and communication. Perhaps most critical is the duality of inspiration and perspiration. Good systems engineering is defined by fresh thought, creativity, and ideation. But inspiration alone is not enough. There is a tremendous amount of bookkeeping (“perspiration”) in systems engineering – managing requirements, maintaining traceability, tracking budgets for key performance parameters, managing risks, assessing impacts, and more.
Emphasizing one aspect at the expense of the other is not the answer. If we focus purely upon inspiration, we overlook the technical details necessary to successfully engineer a system. Perhaps we end up with a catastrophic systems failure simply by making a units error. Perhaps we deliver a system but ultimately fail validation, losing sight of the driving customer needs. In either case, we fail to deliver the required value to the customer and the stakeholders in an effective and efficient manner. If we tilt in the other direction and focus purely upon perspiration, we do little more than clerk for the project manager – unfortunately an apt description of systems engineering in some circles. We manage requirements, police processes, and produce specifications, but we fall well short of delivering the necessary business value. Systems engineers are not the source of all innovation, but done well, systems engineering is a team activity that “collects and organises all the information to understand the whole problem, explores it from all angles, and then finds the most appropriate solution” (Richard Beasley, Rolls Royce Fellow). We must embrace both inspiration and perspiration. But that does not mean that we should not manage – and perhaps even mitigate – the cost of bookkeeping.
When systems were simpler, the chief engineer maintained in his mind a complete picture of both problem and solution at the systems level. Traceability matrices, cross reference matrices, and other key artifacts served as detailed checks and communication tools, but the chief engineer facilitated design discussions and tradeoffs based upon that mental model. Living in the full context of the system, immersion was never broken. The inspiration and perspiration of systems engineering went hand in hand, the potential impact of design choices seen immediately with artifacts prepared to support more detailed design excursions, trade studies, and reviews.
Today’s systems are far more complicated, if not complex. One human mind cannot maintain the full breadth of information and range of interactions, even when limited to the systems level. We must rely upon various work products and artifacts to serve as critical design aids. With this, the hidden costs of bookkeeping creep in.
The most costly issue is simply the disruption of immersion. There are countless scholarly studies on the subject, but each of us has experienced the time required to achieve immersion when working on a given subject and the cost when that immersion is broken. Whether it’s “I lost my train of thought” or “where was I?”, we understand the impact when the phone rings or the co-worker interrupts us while immersed and in a state of flow. Interrupts are not limited to external stimuli. Inspiration itself results in disruptions in the form of bookkeeping necessary to maintain design consistency and coherence: “if I add a signal here to synchronize my subsystems, that will enable me to do the job…I need to remember to update the activity diagram as well, and do I have the necessary interface in place to carry that signal?” and “if I change the allocation of this function, that will better position us for future in-service upgrades…hmm, now I need to update the interface spec and account for the break in control flow.”
Almost any design question, exploration, or decision immediately triggers a chain of important bookkeeping. If we stop to handle the bookkeeping in the moment, we lose ourselves in detail, breaking the state of immersion and flow necessary for creativity and innovation. If we fail to address the bookkeeping immediately, we put the design at tremendous risk of inconsistency as it is difficult to catch all of the details later. We can use the David Allen Getting Things Done approach of jotting a note on a list, but completing the bookkeeping later may reveal insights that invalidate the design path – something we would like to know sooner rather than later.
The most common technique used is some combination of the three along with an attempt to decouple systems engineering – separating requirements from behavior, form from functions, the various engineering artifacts as disjoint entities. Unfortunately, this violates the concurrent and holistic aspect of the practice, putting our heads in the sand rather than embracing the highly coupled nature of systems engineering.
Systems engineering requires that we get the details right in the context of the big picture. We can’t solve the interesting problems by looking solely from a 30,000 foot level or through a jeweler’s loupe. We need both … connected. It’s all about effectively maintaining context – from statement of need through solution to verification & validation and across design levels within the system. Artificially decoupling systems engineering discards this critical context. Rather than managing or mitigating the cost, it simultaneously limits the effectiveness of systems engineering while increasing the bookkeeping. Without the full context, we fail to understand both the impacts of decisions and the full range of opportunities before us. As we decouple, we find we must manually manage the severed aspects in a disjoint manner, often resulting in the engineer serving the artifacts and processes rather than having them serve the engineer.
A related context issue emerges from the dangerous practice of instantiating a group of modelers responsible for model-based systems engineering separate from the systems engineers. If this group of modelers is doing modeling and simulation within the context of systems engineering, that is modeling in systems engineering, not MBSE. This is perfectly valid with the modelers acting as subject matter experts working as part of the greater project team. If this group is capturing the architectural model – effectively serving as “tool jockeys” or “MBSE clerks” documenting the work of the systems engineers – we have decoupled the systems engineers from the context itself. Done well, systems engineers live within the evolving context of the system problem and design solution. This is the antithesis, creating an artificial separation between the engineer and the context. This both increases the bookkeeping (if nothing else, the communication back and forth between systems engineers and those capturing the design) while limiting the effectiveness by denying the systems engineers the benefit of context.
How can we address the problems of immersion and context? The A3 Architecture Overview approach championed by G. Maarten Bonnema and others advocates for using both sides of an A3 sheet of paper (roughly the equivalent of an American 11”x17” sheet) to convey all the critical information about a system: key requirements and parameters, functional view, physical view, system concerns, design constraints and choices. Model-based systems engineering champions capturing the systems in a “single source of truth” repository where the repository provides not only automated support for the capture of systems engineering information but also the systems context within which to operate. Done properly with automated consistency between domains and views, MBSE can allocate much of the bookkeeping to the computer freeing the human to engineer and innovate.
Whether you choose A3 Architecture Overviews, MBSE, classic document-centric approaches, or anything else, the key is to embrace both inspiration and perspiration. Intentionally engineer your engineering approach and environment to fit the problem at hand – its level of precedence and complexity – as well as your organizational priorities and culture. Deliberately allocate tasks to humans, processes, and tools remaining conscious of the interfaces created and the associated costs – in immersion and context; to bookkeeping and inspiration. If we engineer our design system well, we match the design system to the problem at hand, managing the expected and emergent costs of bookkeeping as we innovate. If we do it poorly, we find ourselves serving our artifacts and our processes at great expense rather than engineering our system and creating new business value for our customer.
