On a popular online discussion group, one of the discussions I have been participating in involves the topic of changing from a document-based Systems Engineering culture to Model Based Systems Engineering (MBSE).  In this blog I discuss my views on the topic.

   While the issue seems to be an organizational issue and classical change management, I think a successful transition needs to be addressed at both the individual level and the organizational level. 

Individual Level

   An organization probably has a lot of experienced and seasoned (old school) engineers who have spent their careers engineering systems without the formal MBSE methodologies and tools we have today.  MBSE requires a different way of thinking. There are different thought processes involved.  It is really hard for many to change their fundamental ways of thinking. A very big learning curve for many.

    On top of that, some enthusiastic advocates of MBSE imply that the old school SEs have to throw out everything they hold dear and do SE in a completely different way. This is a really big turn off.  I feel that to be successful, the best approach for transitioning to MBSE needs to be a hybrid approach, adding to existing processes as opposed to throwing out the old and bringing in the new.

   Another issue is the added complexity of not only thinking about MBSE but also understanding how to use the tools that are used to capture the models and other SE artifacts generated as part of the SE lifecycle processes.  Another learning curve.

   I have found that within some organizations there exists small grass roots groups who can think in terms of MBSE AND understand the tools to be used. These groups tend to treat MBSE as a religion and preach its benefits, albeit sometimes to the extreme.  Those outside these groups can feel threatened and will naturally push back.

   To be successful in your transition to MBSE, these issues concerning the individual need to be addressed.

Organizational Level

   I view the need to transition to MBSE from a very practical viewpoint.  Capability Maturity Model Integrated (CMMI), International Consul of Systems Engineering (INCOSE), Project Management Institute (PMI), International Institute of Business Analysis (IIBA), etc. all have the common goal of improving the quality of products.

   As new tools become available to help improve the quality of products, it is advantageous for organizations to adopt/integrate those tools into their existing processes when they can benefit from the use of those tools.  Requirement and design defects introduced into the process early in the product life cycle can have serious impacts on the success of the project.  The cost to fix requirement and design defects has been shown to grow exponentially as we progress through the project life cycle. Adopting a tool that can minimize requirement and design defects early in the development lifecycle will have a high rate of return.

    The products we develop today are much more complex than those developed in the past and this complexity is increasing at a rapid rate. Non model-based methodologies have a hard time dealing with this increased complexity – both internal to the system as well with the interactions (interfaces) between their products and the outside world.

    An organization can focus on a tool to support requirement development and management only or a tool that supports not only that but supports the entire life cycle of the system development. To learn more about features an SE tool should have see my blog: “Features an SE Tool Set Should Have.”

     MBSE, to me, is accepting the fact that a tool that supports the entire life cycle of the system development including requirements, modeling, design, integration, testing, verification, and validation is necessary to manage complex systems and produce a quality system with as few defects as is reasonably feasible.

   If an organization’s management can honestly say they are happy with the existing quality of their product and the current profit margins, then maybe there is no need to change.  However, if not, then MBSE may help improve the quality of their products and increase their profit margins.

    Remember the saying: “Insanity is doing the same thing over and over again, expecting different results.” or a derivative: “Insanity is repeating the same mistakes and expecting different results.” A thought on change from Socrates: “The secret of change is to focus all your energy, not on fighting the old, but building the new.”

A couple of parting thoughts on MBSE:

MBSE and Requirements

   One major myth associated with transitioning to MBSE is the role requirements have within the MBSE world.  MBSE does not do away with requirements; note I say requirements, not requirement documents.  One of the main reasons for MBSE includes the ability to better develop a clear, concise, complete, and consistent set of requirements that communicates the stakeholder expectations to the design team.  During the product development life cycle, MBSE enhances the ability to allocate and trace requirements as well as manage change.

    It is not really a question of going from a document-based to a model based methodology. Scope, requirements, design – all need to be documented.  The real change is the method and manner of documentation.  Paper-based documents in a MS Word or Excel or in a software tool?  Documenting allocation and traceability between levels of the system architecture for complex systems is almost impossible for today’s complex systems without a software tool.

One Size Doesn’t fit All

    It is also important that applicability of MBSE is addressed. One size doesn’t fit all. Trying to force MBSE on small, simple, one-time projects is like trying to fit a square peg in a round hole.  The license, training, support, maintenance, and upgrade fees for the  MBSE tool may cost more that the project’s entire budget.  I go into more detail in my blog: “Applicability of MBSE to Different Types of Projects.”

   For more information on implementing MBSE in your organization, see my three part blog “Developing A Model-Based Systems Engineering Capability That Meets the Needs of Your Organization.”

Comments to this blog are welcome.

If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.