Recently in the INCOSE group here on LinkedIn Stephen Guine posted the following:
“Hey folks, after chatting with some of our fellow members at the recent Regional Mini Conference here in Los Angeles, I’ve come to the conclusion that many of us might benefit from a podcast focusing on “real world” MBSE stories. Topics might include “what was it like choosing a toolset,” “let’s talk about the conversations that were had on the business side of the house,” or “what’s your game plan for skill development?” The goal is to hear other SE professionals talking about real-world implementation”
One response which struck a chord with me came from Rebecca Onuschak who responded:
“If MBSE has a practical side, I’m all in for hearing it. ;). Kidding aside, not so much choosing a tool set, as the practical value to business outcomes compared to the effort expended, and how the content and results are being used without everyone on the team having to either learn a whole new communication method or accept the results on faith. Don’t get me wrong – I’m aware of its value, but its biggest drawback seems to be the lack of a straightforward direct connection process for talented discipline engineers with better things to do than learn one of these tools for its own sake. They need to be supported by their SE process, not controlled by it, and an inability to review and collaborate directly on the system without consulting a translator is a non-starter for most teams. If someone is using tools that bridge this divide, I would love to hear about that.”
Another from Jonathan Holt was as follows:
“I’m making the assumption here that MBSE refers to descriptive modelling of systems in which a formalised graphical syntax is used (e.g. SysML). In that case: what I feel is really lacking is a clear value case for the activity. How can we convince ourselves that the value received from MBSE is greater than the effort put in. My hunch is that in many cases the value proposition is negative. If so, what are the boundaries? What problems do we need to approach with MBSE and in what way to get positive value.”
I think there are number of fundamental questions here relating to MBSE and it’s worth while taking a little time to discus them:
Let sleeping dogs lie
A frequent and reasonable question asked about MBSE is “What’s the return compared to the effort?”. As Jonathan implies, why would you do it if the ‘value proposition’ is negative? Well the simple answer is, if that were the case, and it was demonstrably so you wouldn’t. The problem is it’s very difficult to measure. This leads many people to the conclusion that if it can’t be shown to ‘add value’ then we shouldn’t do it. The problem with that logic is we also struggle to demonstrate that document-centric SE (which is essentially the antithesis of MBSE) has a positive (or even less-negative) ‘value propasition’. So even if we had good data to hand about MBSE what would we compare it to? This tendency to favour current approaches over alternatives is called (not surprisingly) the status quo bias. It manifests itself as “here is OK, over-there is risky”, when actually the reality is “here is risky, over-there is also risky”.
The boy who cried wolf
Let’s imagine we have three sets of data – projects that didn’t do SE, projects that did document-centric SE, and projects that did MBSE. And let us also imagine that MBSE was shown to consistently provided the best value proposition. Would you believe the data? Well not at face value, and nor should you. Data and arguments about value propositions appear to be a sensible way to make decisions but they’re seldom persuasive when it comes to risk. Check out climate change, smoking tobacco, obesity etc..
A classic paper on this subject is ‘The Shangri-La of ROI‘, by Sheard & Miller. INCOSE’s Paul Davies (who knows more about this area than I do) summarises it as follows:
- There are no “hard numbers”;
- There will be no hard numbers in the foreseeable future;
- If there were hard numbers, there wouldn’t be a way to apply them to your situation; and
- If you did use such numbers, no one would believe you anyway.
As Paul says, that doesn’t mean we shouldn’t keep trying to collect them, but there are limits to their influence.
Old dogs and new tricks
How would you respond if someone came to you and said “I want to be an electrical engineer but I can’t see the point of circuit diagrams. Why can’t we just write what we want to build in words?”. Now it could be (but very unlikely) that they’ve realised that electrical engineering is overcomplicated and they’ve found a really great simplification. Or it could be that they don’t understand circuit diagrams or how they are used and so really aren’t qualified to make an assessment. The mistake made by this novice electrical engineer is that circuit diagrams are somehow comparable to the written word. I could be wrong, but it appears to me that circuit diagram are such a useful tool in electrical engineering that being able to draw and understand them is a minimum requirement for a practitioner. It’s a mistake to assume that any two languages (be they text, graphical or whatever) completely overlap and that whatever you can record or communicate in one you can record or communicate in another. Every language has strengths and weaknesses when it comes to a specific applications and you can only make an assessment about which is more or less suitable if you understand both.
Consider next a project where 50% of the team members only speak English and 50% only speak French. No matter which way you look at it you’ve got a communication problem. You could employ translators to sit in every meeting and listen to every conversation but it’s not ideal. What you really want is a common language amongst everyone. If we assume that English and French are (for our purposes) comparable, which one do we choose? Will you teach the English speakers French or the French speakers English? In this example it makes no difference.
Tail wagging the dog
Consider now an engineering project where we have mechanical engineers creating piping and instrumentation diagrams (P&ID), electrical engineers creating circuit diagrams and software engineers writing C++ code. Which one of these three languages are you going to choose as your common one? Well none of them because they are all too domain specific. The easy option is to use natural language i.e. text (providing they all understand the same natural language) but that is everyones second choice for describing their own domain! Is it really the best language for systems engineering, or does systems engineering (like mechanical, electrical and software) need its own language tailored to its own specific concerns e.g. SysML? And should understanding any such language be a minimum requirement for a practitioner?
Why keep a dog and bark yourself?
In conclusion:
- Discussions about value proposition and ROI are useful but people will adopt (or not adopt) MBSE regardless and based on other factors,
- MBSE isn’t a silver bullet (nothing is) but from outside you can only see the costs and not the benefits so there’s always a ‘leap of faith’, and
- Not all languages and approaches are equal. If you understand more than one, and can pick and choose as appropriate, you’re in a stronger position than if you only understand one and don’t have a choice.
