MethOps, marrying Methodology and IT-Operations.

Dear friends and family, we are gathered today to witness and celebrate the union of MBSE-Methodology and IT-Operations in marriage. For years they have been eying each other and playing hard-to-get. But finally they both realized that they go hand-in-hand like the ocean and beach. 

In this blogpost we outline why we are convinced that MethOps is essential for effective and efficient system engineering. 

We’ve already met before! At the DevOPS wedding!

Okay let’s stop the wedding jokes for now and get serious. If you go to the Dev-Ops wikipedia page you find the following description: DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality.  

Alright, alright alright that sounds like something we need in Systems Engineering! So what are the goals that DevOps has, that we as System Engineers can adopt? In our humble opinion and experience with DevOps, the DevOps goals are: (a) minimize manual labour for a system release and (b) maximize system reliability over its life cycle. 

These goals result in highly automated processes and tests in varying forms (e.g unit, integration, performance, A/B, GUI tests, ect.). These are areas of development besides the main activity: the actual development of a single software system. Hence, you as a company do not want to set up all of these automated processes from scratch, every time you have new software to deliver and they are too important to consider it all as an afterthought or secondary activity. Introducing the concept of explicit reasoning about those Development Operations (DevOps), treating DevOps as a first class citizen and giving it the attention and rigour it needs.

In addition to the more efficient and reusability of the software development support processes.  DevOps puts the operations part of the software at the same location as the in depth knowledge of that software, namely within the development teams. Problems that occur during operations are immediately visible to the same people best equipped to solve them. 

Problem domain 

Let’s first consider the three pillars of MBSE. 

• The Modeling language (e.g. SysML, LML)
• The SE Methodology: a system of methods designed to develop  systems reliably and consistently  
• The Tools that enable you to model your system using the modeling language using the methodology. 

In large organizations it is not uncommon to see that these three pillars of MBSE are in the hands of several departments. Tools are the responsibility of the IT department, but they do not configure them to aid in enforcing the methodology. The methodology and language are in the hands of a single organizational entity but is the hodgepodge of several departments each with strong opinions and different views on the matter. This fragmentation makes decision making and finding (subjective) consensus difficult. Compare this scattered landscape situation with the focused and first class citizen approach of DevOps. This lack of a holistic view, focus and sense of responsibility is what we consider the root problem. 

In short:

• No explicit single organizational entity to establish and govern the trinity SE methodology, modeling language and tools. 
• No explicit single organizational entity to guide and take responsibility for the choices, adaptation and maintenance of the SE methodology, modeling language and tools. 

(WIP) Goals of MethOps

With the problem domain laid out, we can now set goals we want to achieve by adopting a MethOps approach. We currently have no fully matured list of goals so please join us on this journey, but this is what we have accumulated so far. 

• Continuously govern the model quality and adherence to the methodology. 
• Establish seamless integration of required tools. 
• Reduce integration time. 
• Alignment  of method and tools.
• Allow for fast method changes and subsequent tool changes to better support engineers
• Allow for fast feedback loops to improve engineering method and tools

MethOps principles 

Given the problem domain and the goals we aim to achieve, we laid out the following principles that any MethOps approach should adhere to. 

• The organization that is responsible for the adoption and modification of the SE methodology, is also responsible for the tools that enable and support the methodology. 
• The organization that is responsible for the tools and methodology has budget and decision authority. 
• The organization that is responsible for the tools and methodology, is deeply involved in the training of other personnel. 
• Engineers are continuously involved into the method and tool definition
• Continuous quality checks and monitoring activity to detect whether tools and methods need to be improved.

With those priciples we can make a pretty picture as well, just as the devops cylcle we can map the common steps in a MBSE approach and the processes on the operations side. Please let us know what you think of this , your feedback is highly valued.

.

Summary

As with the already established DevOps culture and way of thinking about software development, the same is needed for Systems Engineering (Model-Based or otherwise) we lay out the goals and principles of the merge Methodology and IT-Operations resulting in MethOps.