Applying MBSE 2.0 with Intent Aforethought

Abstract

The objective of this paper is to provide guidance to the practitioner initiating a model-based systems engineering (MBSE) approach to a system design process. The principles discussed here are applicable irrespective of the domain subject matter of the design and reflect experience drawn from across a range of domains from military-aerospace to property and casualty insurance process to healthcare delivery and subsea oil and gas operations. It is well recognized that the oil and gas industry has a substantial problem with cost overruns and schedule delays. Citing a 2014 Ernst and Young study of 365 projects with a proposed capital investment of above US$1b that reviewed project performance in the oil and gas industry They found that 64% are facing cost overruns and 73% are reporting schedule delays. [EYGM, 2014] Matthew Hause and Steve Ashfield tied the solution to much of the overrun and delay problems to a disciplined and integrated approach to systems engineering using MBSE. Hause (2018) All too often the move to MBSE begins with an embrace of the idea of MBSE as implemented in a particular configuration. Having heard of MBSE, "seen" MBSE in a particular tool, or heard a pitch for some "industry standard" approach, the practitioner is tempted to adopt outright the implementation of the MBSE solution that was presented. The reasoning is that, "the source of the presentation solved their problems by using Tool X so if we buy tool X and start building models, it will do systems engineering for us and solve our problems/make our lives easier." This reasoning contains a number of misconceptions that can get the adopter off to a bad start on an important journey. It is the aim of this paper to see that this temptation is avoided and the quality of the choices made is improved. NOTE: At many points in the initial journey to MBSE it will seem that the process suggested here slows the progress and makes the choice of MBSE less productive, perhaps even less productive than remaining with the status quo. But this is a confusion of operational speed with strategic speed. The good news is that the slowdown to carefully navigate the considerations and choices on the front end of the journey pays off in a higher quality solution at implementation. The "opposition" to instituting an organizational MBSE practice most often appears well-taken on the front end. By rejecting MBSE it appears that the design teams avoid creating "needless" diagrams, interviewing numerous stakeholders and refining large numbers of requirements. The time not "wasted" on paperwork and documentation can be spent on "real" design work. But this is an illusion. The MBSE process that is avoided turns out to be the very thing that would have mitigated or eliminated the inevitable problems that result from the shortcuts and skipped process steps. Design choices that are illuminated by the MBSE practice often fail to appear and are lost to the team. Preventable problems are missed and come back to haunt the design. In fact, project performance has been directly tied to the maturity of systems engineering practices. In a 2007-2008 study by the National Defense Industry Association (NDIA) and Carnegie Mellon University's Software Engineering Institute (SEI), only 15 percent of projects with a "low" systems engineering capability achieved a high level of performance while 56 percent of those with a "high" level of systems engineering capability exhibited a high level of performance. Elm (2011) This study provided confirmation of earlier studies of the benefits of systems engineering practices. It is critical to realize from the outset that the process of adopting model-based systems engineering is a journey and not simply a matter of making a choice. It is a journey in which we seek to move from where we are in our systems engineering practice to a desired state of that practice. Starting the journey without a clear picture of what we are seeking is as foolish as starting a long trip with no idea of where we are going. As Yogi Berra astutely pointed out, "If you don't know where you are going, you'll end up someplace else every time." The first step, therefore, is the definition of the destination for the journey.