Mightier than the Pen

In 1839, Edward Bulwer-Lytton wrote in his play Richelieu, “The pen is mightier than the sword.” In this, Bulwer-Lytton meant to say that communicating thoughts was more powerful in effecting change than committing acts of violence through war. But might there be something more powerful than the pen?

Systems engineers have a notable challenge as we seek to communicate lifecycle concepts and system designs with diverse audiences. We are in the business of communicating technical concepts with a host of stakeholders—including the ultimate user, those responsible for acquisition and sustainment, the internal business manager, and other engineering team members as well. For a few generations now, systems engineers have used the pen to write specifications and produce drawings. Our undertakings in the 21st century grow in detail and complexity every day, such that we now need a modern “pen” to compose and keep track of our thoughts.

The answer to this challenge is a well-crafted model-based systems engineering (MBSE) representation of our systems capable of simultaneously reflecting both breadth and depth of concerns. Modern MBSE tools enable systems engineers to capture requirements, draw behavioral and structural diagrams, maintain traceability across the design, and generate the required design artifacts (documents, architecture framework products, and more) directly from the “single source of truth.”

But it’s not enough to simply capture the final design specification. Often, when we think of MBSE, we think of requirements, behavior, architecture, and test. If this is all we capture, we are simply writing the conclusion to the story. Our “pen” must be far mightier. We must capture the journey—the alternatives considered, the reasoning and rationale behind our decisions, the risks identified and mitigated. To be truly effective in engineering modern systems, our pen must capture story and conclusion, design journey and design specification.

During the initial design of a system, engineers make many decisions typically preserved in meeting minutes, emails, or deleted requirements. But often the documentation of a decision is weak at best. For example, a particular feature may be deemed too expensive or risky, so it’s dropped. The team in place at the time of the decision may or may not be aware of the details, but often the details are not adequately captured—for future team members, for reference during the operational phase, and for potential future revision. Similarly, systems engineers may conduct a trade study comparing alternative selection criteria for the most holistic design but then inadvertently fail to retain the study. The loss of the record of this decision—to not pursue a certain avenue—may seem insignificant at the time, but often proves tremendously costly down the road when later engineers and managers re-litigate the same ground.

Fielded (delivered) systems may work, but we rarely have clarity into the “why” behind the design. Engineers intimate with the design phase—the people who resolved the incremental challenges—may no longer be accessible, having retired, changed companies, or been assigned to other areas in a business. With changes in engineering personnel more frequent than ever, the knowledge of what information was used, how a design decision was made, and the issues that arose during integration are simply lost.

The reality is it’s often quite difficult to attach the necessary context of the design journey when using our classical pen—paper-based and word-processed specifications. And for designs created many years ago, the newly assigned engineers don’t know the questions to ask, so even if they find the trade studies—which in itself is not a given—they struggle with the design context. As we adopt the modern pen of MBSE, we should do more than simply digitize past approaches. To mitigate this challenge and leverage the full breadth of MBSE, we should look to capture all of the knowledge in the journey of engineering a system rather than limiting ourselves to the specification. In fact, in a good MBSE environment, concerns, rationale, risks, and trade studies can be captured organically as part of the systems engineering model, providing essential context to the system specification.

My modern pens of choice are CORE and GENESYS—MBSE environments that served me well on multiple US Navy efforts. (They in fact served me so well that I decided to join Vitech!) CORE and GENESYS are both integrated MBSE environments spanning requirements through behavior, architecture, and test. Performing and documenting design via one of these tools also enables one to conduct analyses in order to derive implementation-specific requirements that are linked to their sources and rationally tied to the overall system context. They also enable the capture of concerns, risks, trade studies, and more (the journey) integrated with the design specification (the destination). The relationships between programmatics are captured just as clearly as the relationships between aspects of the specification – for example, how specific design decisions caused risk, and how those risks were mitigated via further design decisions. Without this design decision history, engineers are at risk of reinventing a broken wheel or, even worse, injecting an error through lack of understanding of the complete design story.

At the start of this blog, I referenced MBSE being mightier than the pen. In doing so, I don’t mean to disparage or dismiss documents. A document remains a great communications vehicle. The MBSE difference is that a model is used to both support and document the engineering. When needed, documents are then produced from the model. Formal specifications and informal working documents become queries of the integrated model—both design specification and rationale—in the same way that a requirements diagram or an internal block diagram are structured graphical views from a given viewpoint. Generating diagrams, documents, and architecture framework artifacts directly from the model with the push of a button eliminates hours of manual view generation and the subsequent consistency reviews as you work from a single source of truth. Now that’s a mighty tool!

The penning of the U.S. Declaration and Constitution are proof of the 18th century power of the pen. As you tackle your 21st century systems, avail yourself of the 21st century power of MBSE to communicate both the outcome (the design specification) and the journey (the considerations and decisions) for the benefit of today’s team and the teams to come.

Leave a Reply