I speak with people in the systems engineering community all the time. When I hear systems engineers say, “Yeah, I’m doin’ SysML,” it makes me cringe. I’m not bashing SysML views in any way, shape, or form. I think SysML 1.5 diagrams are a great communications tool. But they don’t constitute a method or activity. Creating the diagrams is not “doing SysML.”
By the way, I’m not alone in this recognition. SysML experts from the Object Management Group (OMG) say:
“SysML provides a means to capture the system modeling information as part of an MBSE approach without imposing a specific method on how this is performed. The selected method determines which activities are performed, the ordering of the activities, and which artifacts are created to represent the system.” From: Friedenthal, S., Moore, A., and Steiner, R. A Practical Guide to SysML, Morgan Kaufmann OMG Press, 2009.
OMG says SysML views are ways of communicating engineering data, and a pretty good way at that.
I say, what systems engineers should be discussing is how they’re doin’ the engineering. SEs should be doin’ functional analysis—examining the sequence of events and control (a.k.a. behavioral analysis) and then using an Activity Diagram to communicate the information generated by that process. SEs should be doin’ information analysis to understand how information enters and exits the system to show how information is exchanged among design elements and then using IDEF diagrams or Sequence diagrams to communicate the ideas. SEs should be doin’ requirements analysis, ensuring completeness, clarity and testability, communicating the information using a requirements diagram. SEs should be doin’ interface analysis to understand connectivity among external systems and the system under design and among internal subsystems and how they communicate by using an internal block diagram.
What concerns me in all this is attempting to apply a prescriptive standard to systems engineering. In my mind, that’s a monumental failure. Thinking we can engineer views is inadequate. Granted, we appear to have engineering data, but there is more to systems engineering than pictures. The pictures should reflect our work—not be our work.
Let’s step back for a moment. In the 1960s, the Mercury program had very simple computing capability, mainly provided by the women famously portrayed in the movie “Hidden Figures.” Engineers have been communicating using pictures forever, and this situation was no exception. The Mercury folks started out with hand-drawn images that were formalized by draftsmen. These pictures were successful not because they looked nice, but because they grew out of an engineering activity and contained critical information in a form and format that allowed the engineers to clearly communicate with one another.
Not all that much has changed since the days of Mercury. Some things have changed—the systems are hugely more complex and complicated. The amount of information is mind-blowing, and systems engineers have to be able to communicate the information clearly, but, as was true for the NASA engineers, we also have to be doin’ the engineering in order to have some substance to communicate.
Model-based systems engineering (MBSE) offers design teams the tools to perform the critical systems engineering task in a consolidated, integrated, consistent, distributable, and really fast environment. Because of MBSE, systems engineers should be able to—have to be able to—generate consistent communications views from engineering data, not just standalone graphics. And, the graphics need to be consistent from one type of representation to another. When one changes, they all should change accordingly. I always hated having to make the same change on a bunch of diagrams to manually ensure that they were consistent with the change.
During my career, I’ve been, and am again, a practicing systems engineer. I’ve led teams as a technical director and program manager. On one program, very talented engineers worked as part of an integrated product team. In that instance, the group focused on generating a group of DoDAF views—another set of standard views comparable in that sense to SysML. The output was nice, but had little or no impact on the overall project, because the major design efforts were independent of the team’s preparation of views.
When I came to the realization that my engineers were “checking the boxes” regarding the production of the DoDAF views, it was cause for alarm. My experience has led me to be wary when people are relying on a canned process to ensure success, or worse, to have something to blame if problems arise. Simply checking all of the boxes does not equate to program success. The check-boxes were never meant to be an end in and of themselves, but to serve as good and sound reflections of actually doin’ the engineering.
We’ve all said it: that tools, process adherence, and MBSE in general are no guarantee of a program’s success. Nothing replaces talented systems engineers who follow excellent processes, apply quality methodologies, use great tools and communicate using mature view definitions as aids to exercising sound engineering judgment and making good design choices. This, in my mind, captures what “doin’ systems engineering” really means.
Happy Engineering!
