In this blog, we recap a webinar discussing Best Practices for Data Migration Towards MBSE (model-based system engineering.)
Data is one of the most valuable assets for organizations, but are we giving it enough attention? The prospect of moving to Model-Based Systems Engineering (MBSE) is tantalizing but often seems difficult when considering the move from existing engineering assets.
In this webinar, Richard Watson, VP Practice Director at Jama Software, will discuss this topic and give best practices on how to formalize the process of MBSE migration to reduce risk of data loss. He will also walk through the risks of legacy requirements management tools and provide solutions for migration.
In this session we will cover:
- What MBSE is and how it differs from SysML
- Benefits of building a common data model for engineering
- How to approach moving data towards MBSE
- Best practices for data migration when moving away from legacy solutions
Below is an abbreviated transcript and a recording of our webinar.
Best Practices for Data Migration Towards MBSE
Richard Watson: Hi, everybody. Today, we’re going to look at what MBSE is, and also, how you can get data into MBSE to provide benefits to your organization to get more consistency. So we’re going to jump straight into looking a little bit about what exactly is MBSE. So MBSE, model-based systems engineering, is something that is a concept come up from the OMG. So I thought it would be a good idea to give you their definition. I’m going to read it out. It’s the formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design for… Oh, wait a minute. So, looking at this words, it’s really, really complicated to read, and really, by the end of it, you don’t fully understand well what actually is model-based systems engineering.
If you read between the lines, model-based systems engineering is the elimination of documents to combine all of your different engineering datas. So that’s requirements, architecture, behavior, verification, and validation into single data-driven model environments, all tied together with relationships. So, many people think MBSE is modeling, and modeling does form part of it but it’s not only visual modeling. It’s actually data modeling.
If we take another angle of what is MBSE, again, lots of words, this is, for this time, from Lou Wheatcraft. Lou is co-chair for the INCOSE’s Requirements Working Group, which is the largest working group in INCOSE. He explains that MBSE can’t be effectively practiced when viewed from just one perspective. Now, that means, if you do just look at MBSE from a modeling perspective, you don’t see the whole of MBSE. If you just look at MBSE from a requirements perspective, you don’t see the whole of MBSE. So, it’s lots of different types of data interconnected together with relationships, viewed from different angles or dimensions.
Drawing an Information Model
Richard Watson: I’ve tried to draw this in a picture. So here you can see the different site types of data that you might have, but we all know that you can’t look at architecture without seeing how it ties to behavior. You can’t do verification without seeing how it ties to requirements. All of these different disciplines tie themselves together, and they tie themselves together with relationships. Okay, this test case must verify that requirement or this architecture realizes that requirement, this design iterates that architecture. Once you understand how your data relates together, you can draw an information model. And that information model, the bit in the middle, is an MBSE systems model. This is MBSE, not the model itself, but the fact that it’s data and relationships with between data.
This is tool agnostic, you’ve not looked at any systems that will manipulate this yet. Once you have an understanding of all of the different engineering data in your organization, then you can break it down and say, “Well, what would be the best tool to look at and manipulate the data in your MBSE framework?” So you might have requirements, tools, modeling tools, change management systems, development tools, et cetera. All of those different applications will have some visibility into your MBSE data model. And collectively, this is MBSE. So MBSE is a collection of all of these different systems interacting with all of your engineering data and making sure that when you’re sitting in any of these systems, be it requirements, design, test, deployment, simulation, you have access, not just to the data that that system itself manages, but also you have a view of the relationships to the data that sits inside of other systems. So from the design, you can see relationships to the requirements. From simulation, you can see relationships back to the design, back to the requirements. So, MBSE is the data model-based systems engineering.
So if you’ve followed so far, it’s quite a strong structure, and once you have an understanding of it and once you can move your organization towards it, it brings a lot of benefits. Jama Software have actually produced an MBSE framework, it’s almost like a kick starting your process. So you can use Jama Software to have a beginning of an understanding of what your MBSE data model should look like. And then you can look to figuring out which aspects of it are tied to different tools to manipulate your engineering information. The benefit of that framework is that, it saves you time and it accelerates the speed that you can get to actually doing some engineering and the speed that you can produce actual systems at the end. It makes requirements and all of the data, all of the relationships between the data accessible across your organization and anybody that you work with. So these frameworks are a really good way of accelerating that process.
How do we get your legacy data into an MBSE framework?
Richard Watson: But there’s a big question. So if you start MBSE framework, is that assuming that you’re going to start with a blank page, that you’re going to start without any information or any data? And of course, it’s very rare these days for an organization or a project to sit in a room and say, “Right, we’ve got absolutely nothing. What are we going to create today?” More commonly, we’re finding that projects build themselves from other projects and existing datas.
So now, not only are you understanding what is an MBSE framework and how does your engineering data relate to each other, but also you’ve got existing data. How do you get that existing data into your MBSE framework, such that then you’ve got a consistent set of data that you can deploy to your teams? Consistent data is very significant because, firstly, it makes it far cheaper for your engineers. Engineers can move from project to project and understand what the data should look like. It also makes it far quicker to integrate other systems too. So you do want this consistent data approach, this model-based systems engineering approach, but you don’t want to forget your legacy, your original data.
So let’s see how we make that switch. How do we get your legacy data into an MBSE framework? If you consider the value of your data, it’s far higher, typically, than money that you’ve invested in anything else. The money that you spend in the tools to manipulate your data around MBSE, actually they’re not expensive compared to the value of the actual data that you’re manipulating. One reason migration typically either fails or it fails to leave users satisfied is that, we are not giving the data the respect it demands and deserves because of its value. Organizations have approached migration literally just with a give-it-a-go attitude. What I mean by that is, they simply press the button and say, “Okay, migrate.” They migrate until something goes wrong, and then they fix the thing that goes wrong.
Richard Watson: And then they press the button again, and say, “Well, continue to migrate,” and they continue to do that over and over and over again until the migration process is finished. The difficulty with that is, it’s very, very difficult to predict how long will that migration process take. And even once you’ve done migration using this mechanism, when you go to your users, your users will be very distrusting because they will have witnessed the process that you just went through to do data migration, and they’ll have very little reassurance that the data that’s in the new system has any or all of the resemblance of the data that it had in your original place. So for example, if you’re migrating data from DOORS into Jama Connect, you need to know and recognize the data in Jama Connect was the data you originally worked on in DOORS.
Now, the problem is not necessarily about a single tool vendor. The process side of migration can be wholly generic. Okay? And that’s the key, having a process around migration gives you a way of making it predictable. And I’m just about to share with you a process for migration that is tool agnostic. It doesn’t matter where your data comes from or where your data goes to. It gives you a holistic process that you can use to migrate your data. And each step of the process, you just decide where is the data coming from and how do I take it and transform it into where it’s going to. Jama Software do provide migration tools towards an MBSE framework. And the examples through this presentation will be showing you how to migrate data from DOORS, IBM DOORS, into Jama Software’s Jama Connect product.