Why Model-Based Systems Engineering? 8 pointers
Model-based systems engineering is a big buzz right now. Should you hold out on that new project or should it be seen as a good opportunity to introduce the model-based approach? Despite all the talk, it seems like a hefty investment riddled with risk and you just don’t know what to expect.
Take the leap, you won’t look back, but only after carefully considering the following words of advise:
1. It's not a Silver Bullet
Most of your systems engineers are all hyped about model-based systems engineering. They heard a lot of good things from their peers, read about it or even attended some workshops. They join the internal battle for resources and are fighting as hard to convince decision makers of their model-based plea. Despite all their passion, a downside of their flawless arguments is, even without realising, that they begin to believe in a MBSE silver bullet.
Sorry to burst everyone’s bubble, but there’s no such thing.
To engineer is to create something new, something that has never been. So, a bit of unprecedented systems engineering will always be needed for every unique project. If not, there’s no point in systems engineering at all. Whether your team relies on a model-based approach or not, the actual systems engineering work still needs to be done. The model-based approach is just that, an approach. None of the work will be done for them.
2. The Groove Runs Deep
“I create my information in this way, capture it in that document and in those spreadsheets. Finish and klaar!”
As soon as the larger team begins to collaborate in an integrated model-based environment, they quickly become aware of the differences in their respective approaches. They also begin to question this new approach of small, simple information bits that describe the system’s complexity through their relationships, instead of large complicated information bits - like documents and reports - that try to describe some part of the system’s complexity in an isolated fashion.
More experienced engineers will bring a huge amount of value to your fledgling model-based culture, but greater experience also leads to a big challenge, the ability to bring about the very necessary changes in each team member’s respective approach.
3. Get the Right Champions - with an S
Why more than one? A great team needs two. Model-based systems engineering relies on a database and an associated meta-model, as well as getting comfortable with a new software enabler.
Recent engineering graduates don’t have the right systems engineering experience, but when applied well, they can be very cost effective. They were also raised with computers under their arms. Getting the hang of the tool environment and the database will be a jiffy, but being a good systems engineer takes a lot more than that. Experienced engineers are great at keeping a new project’s systems engineering well on track, but they come with a price tag and can be fairly set in their ways (see 2 above). Learning even the basic navigations of a new tool can be a long, tedious and expensive process to them.
Teaming the young and old goes a long way to get the most from your model-based systems engineering investment. Some young blood with an unshaped mind does wonders when an experienced engineer needs to break some old habits. In turn, experience in this matchup is the perfect opportunity to mentor and develop a young engineer into another valuable systems engineer.
4. Set Aside Enough Resources
It’s a steep learning curve. At first, your engineers won’t be more efficient at their job. If anything, they’ll be less productive. Even though, it is important that they embrace the new approach and that their systems engineering in the model-based environment is more effective and more complete.
It’s only when everyone is through the learning curve that both the efficiency and effectiveness gains will far outweigh the initial investment. Don’t underestimate the investment.
Engineers without enough upfront resources and with a lot of work pressure will naturally try to revert back to their document-centric ways. It can be very detrimental, as some of your systems engineering information ends up in the model-based environment, and some not. It breaks the completeness and consistency of your systems engineering approach which can leave you in an even weaker position than before.
Before taking the plunge, make sure enough resources are set aside for training and capability development, especially man-hours. You can also bring a model-based expert on board to kick-start your project environment and to help your team through the learning curve.
5. Beware the Information Overload
There’s way too much information floating around and all the systems engineers will try to squeeze everything into your model-based enabler. Packing all your information in one database is the first thing everyone thinks is great and valuable, but it can stall your whole model-based effort like a slow turning cementmixer.
The model-based approach relies on small, simple information bits and relationships among those bits. Spreadsheets are great with storing large amounts of information bits and reports great at capturing big isolated descriptions. So you’ve got a lot of spreadsheets and a lot of documents. Don’t pump the information into your model-based environment. Don’t.
I see far too many engineers who jump for joy at automating their work. To engineer is human, an explorative endeavour not to be automated. Developing a systems model should be an iterative process that relies on human ingenuity. The simplest feasible solution will be the best, but getting there requires a lot of human-in-the-loop refactoring.
Begin your model-based endeavour by capturing small, crucial information bits and their relationships, building the system description bit by bit, with continuous cleaning, simplifying and refactoring. You will end up with a well understood, simple and valuable system solution great at addressing requirements in the most effective way.
6. Choose One Activity, Do It Well
You can do all your systems engineering activities in a model-based environment, but choosing not to do the most important activity first, and to do it well, results in none of your systems engineering activities transferring successfully to this new environment.
In a great systems model, every information bit traces to every other information bit. However, team members tend to specialise over time. One guy takes charge of requirements, another looks at all the risks. Some guys are concerned with test and evaluation information and others only with functional allocation and the associated design decisions.
When everyone starts populating the model with their respective contributions, they forget that their information bits relate to the rest of the model. The result is a poor, over complicated model. Your team also loses the early opportunity to learn how a great systems engineering model works.
7. Set Achievable Goals
The ultimate objective is to show management a positive return on your model-based systems engineering investment, but you have to define and agree upfront on what the return is.
Without a well defined systems engineering goal and a timeframe in which to achieve it, there’s no way of determining the return on investment and no way of guiding your team in any meaningful way through the learning curve. Set a goal and know why it is valuable to achieve it. Without an upfront goal, your team won’t be able to identify and schedule any interim steps, crucial for guiding them to their goal.
Asking an experienced model-based systems engineer to evaluate the feasibility of your goal and to help with the development of interim steps can be very valuable.
8. The Enabler is not a Toy
Potential users will be very excited about a new tool, while management tend to chew fingernails about the investment.
It is not a toy. Doing good systems engineering is equally hard with or without a model-based systems engineering enabler. It takes a lot of dedication to learn a new tool. Model-based systems engineers should also have a relentless drive towards simplicity, without compromising on system requirements.
The prize is not efficiency at first, but effectiveness. The value is in the ability to re-trace your thought processes throughout solution development, tracing requirements and design decisions upward, downward and horizontally across all levels of your system hierarchy. It’s also about knowing that all your systems engineering information is stored once and in one place only. .
It is only when the system definition of an unprecedented solution is captured in a great model, that you can really leverage the model for both efficiency and effectiveness!
Go on, take the leap.
Comments