Why Engineering Tools Need an Overhaul: Insights on MBSE from Pari Singh

Why Engineering Tools Need an Overhaul: Insights on MBSE from Pari Singh

Systems Engineering, as practiced today, is broken — at least according to Pari Singh. He believes that engineering tools are stuck in the “dark ages” and is determined to change this. And he is in a good trajectory for fixing it with his company Flow Engineering.

Pari Singh has an education as mechanical engineer and was featured in the 2019 Forbes 30 under 30 list. With his company Flow Engineering that was founded in 2019, he intends to revolutionize product development.

I had the pleasure to talk to Pari Singh on June 21, 2024 to discuss systems engineering in general and MBSE in particular. Read on for the transcript, or to watch the recording of the conversation.

Announcement: On August 1st, Michael Jastram will moderate a webinar on Raiqon’s AI enhancement for Codebeamer in automotive R&D. Register for free >>

Pari Singh & Flow Engineering

Even though Pari’s company, Flow Engineering, provides SaaS Software, the company made an incredible pivot. Pari started off as a mechanical engineer who admired SpaceX, which drove him towards the space industry. Around 2010 when he was still at university, he started a company for designing rocket engines.

To make a long story short, Pari built up a company that managed to deliver rocket engine designs in hours, where competitors required months. They achieved this by building a sophisticated network of interconnected models (Matlab, CAD, FEM, etc.) with feedback loops. They realized that the market demanded agile hardware, and that the tools of the trade were completely unfit for teams that wanted to work that way.

This led to a pivot in the business model. When they talked to investors, they realized that (1) engineering is broken, (2) that they invented a new approach to doing mechanical systems engineering, and (3) if they can find a way to formalize and “fitting it in a box”, to give to their original customers, then they can solve the problem that they started the company for, which is to help the entire industry move much much quicker.

In order to achieve traction, end users have the highest priority for Flow. Organizations like Dassault or Siemens, sell to the chief engineers or decision makers, which often leads to a mediocre user experience. For Flow, building a better experience for the end user is key, and they assume that they will win over the decision makers if they can demonstrate the value of the solution to the end users.

Watch the full interview, conducted by Michael Jastram
Another insightful interview, conducted by Mo Islam on Payload

Interview with Pari Singh

Michael Jastram conducted this interview with Pari Singh on June 21, 2024

You are vocal in your posts on agile engineering, which by now has a proven track record. Why are so many organizations struggling with adopting it?

I would love to give some context on what this change is because I don’t think the systems engineering community yet has quite got a good definition on exactly what the change is. A lot of people say, Agile is two week sprints and is software and is MVP and that’s not really the case. So maybe let me take a step back and and give a broad view on context on what this changes and why it’s such an important change.

We really see a once in a generation transition happening in the systems engineering community right now. It’s the the last time a change in the scale happened was probably in the 1960s when systems engineering was forming in the in the early days. This change is from a more traditional top down waterfall orientated 10 year design cycle where everything is about working with external contractors and being very rigorous to a much more agile and iterative workflow. And this means two things.

First, it means there is a mix between top down requirements management and bottoms up design. Early on, when our systems were less complex, we could mandate all of our requirements from the mission level to the system to the subsystem all the way down to the component level and be correct in those assumptions. But as our products have got much more complex, that’s no longer possible because our systems are now so complex and so cross functional that a tiny change in one team can cause complex changes across other teams and other organizations, which then cause complex changes. And more often than not, we’ve not designed a vehicle of this scale or this complexity. More often than not, we don’t fully understand the systems interactions between software and hardware at the start of the project. And these things need to be understood over time.

So it’s the first big change in the waterfall to agile. Waterfall is is largely top down driven and largely built to avoid change. And agile is largely built to say, we have assumptions in the early days around what our requirements may be, but we are open to learning because change is inevitable.

And we probably won’t be right around all of our technical assumptions, because we’ve never built something like this. As a result, agile teams don’t just break requirements from the mission to the system level or the subsystem level, but they actually flow down requirements from L0, L1 all the way down to L3, L4, L5. So you’ve got full traceability from the mission level all the way down to a specific component level. That is the first big change.

The second big change is to realize that iterative is really the way to go. One of the people that we know very well recently gave this story which said if you want to build a six inch telescope, it’s typically faster to build a three inch telescope and then build a six inch telescope than it is to build a six inch telescope.

It’s a really great analogy. The best teams in the world don’t start at the most complicated version and try and lock down assumptions early on. But they find the smallest unit of integrated system that they can build, to be able to de-risk and learn from their assumptions. And then they add layers to that over time iteratively to be able to learn and develop very rapidly.

If I may rephrase that, from a software point of view, you’re proposing the MVP approach, except that in software you can continue to evolve the product, while in hardware, you have to build a second telescope. But the idea is the same.

That’s exactly right. That approach sounds very wasteful. Hardware engineers don’t like the sound of this, because the have to build it three times, rather than just once.

But if you look at companies like SpaceX, Tesla and the fastest moving companies, you see that this approach is much more efficient than the traditional approach. For instance, if you compare Boeing’s Starliner to SpaceX’s Dragon, you see that Dragon has done more in half the time with half the cost. They’ve had lots of Dragons when they build it and they’ve learnt something from it and they put it away. This iterative approach sounds slower and more expensive. But in practice, it’s been demonstrated to be much faster, much more efficient, and much safer to operate in this way.

I agree with that. It reminds me of their Starship launches. What really bothered me was the headline I read the other day, “forth test flight finally successful“, which implies that the first three were not successful.

We really need a paradigm shift where people understand that a blown up rocket is not a failure, it’s a successful test because it delivered data. So how do we achieve this paradigm shift?

It’s very difficult. The key is not to focus on the requirement delivery, but instead to focus on the learning. So this is one of the things that SpaceX iterated again and again on the live stream for IFT-4. They said the payload is the data. It’s not the successful flight, it’s not us meeting all our requirements, it’s not closing our V&V successfully. But the payload is the data.

And if we’re able to get really great data off of the vehicle and understand it’s exact limits, where we’re doing well and what we’re doing poorly, then we’ll be able to design IFT-5 or the next vehicle much faster, much better and much more rapidly. So, so the core is to focus on learning and. Then the next step that you derive from that is, how do we learn as quickly as possible?

The second big thing that systems engineers find very tough is to come out of “requirements land”, “analysis land” and “thinking land”, and they need to move into “doing land”. That’s a very difficult transition for systems engineers. I can relate to that: I’m a mechanical engineer by training. I spent my entire early career building analytical models to design rocket engines, hybrids, and liquids. But actually you learn a lot from just building the smallest amounts, testing it and going end to end on that and then building the next one and the next one, the next one. And if you look back to Apollo, actually, that’s a lot of what they did.

They realized that in order to go to the moon, they need to build the Apollo missions, but they can’t go straight from “here” to the moon. So before they go up, have multiple stages, then go around the moon and then land on the moon, they need to be able to go up and have multiple stages and get to orbit. And before they get to orbit, they need to be able to pass the Kármán line. The fastest, cheapest way of getting past the Kármán line is to get a missile that we have today, to put a human on the top of that missile and to launch it. If you think about just the scale of that at that stage, it’s insane, but the fastest way for them to learn was to retrofit a human to a missile on ICBM and then to learn as quickly as possible. And that’s how we got to the moon.

I agree with that. The Apollo engineers did the iterations at the pace that was doable with the available technology. But I disagree with the statement that systems engineers don’t want to get away from the requirements.

I think it’s more about the fear from the decision makers who feel that a blown up test rocket is perceived as a failure, which is not. So again, how do we realize this paradigm shift? How do we talk to decision makers and allow them to give the engineers the freedom to do these things?

Let me give you two or three answers and some context. I think context is really important for our industry: If you look at just today, the way we do engineering doesn’t make any sense whatsoever. But if you understand it in the broad context of the last 20 or 30 years, suddenly you can see why we’ve come to the conclusions that we’ve come to. Systems engineering came from early publicly funded missions, space missions. That was the early days of what I call true systems engineering. And that is typically taxpayer funded.

It’s typically a mission that we’ve never, ever done before, very, very difficult. And as a result of those two things, when you’ve got congressional allocation, when you’ve got taxpayer money driving missions and missions that are very, very complex then, missions that employ lots of people. Then you’re in this paradigm of needing to get it right first time. If a politician spends $10 billion or a billion dollars on this big mission and it blows up, that looks really bad. So that’s where systems engineering came from. But now we’re seeing private companies copy all of the sins of publicly funded missions. And that’s the mistake. The mistake is assuming that the same rules apply as a private company that’s in the game to make money and to build really great, safe, reliable products and to move really quickly. That’s the core shift that we need to make.

That explains why start-ups managed to embrace these approaches and that large existing old organizations are struggling with that. Any thoughts on if at all, and if so, how existing large organizations can make this change?

Three years ago, if you asked me this question, I’d said it was impossible. There’s a great principle in science which says the way to create revolutionary change is to let the ancients die out and let the new generation come in. I’m really glad that I’ve been proven wrong on this.

So I look at certain companies like Blue Origin, who actually started out with a much more traditional conservative model. They hired a lot of VPs from Northrop Grumman and from other traditional aerospace companies and they bought in that culture and it almost killed them. They’re currently transitioning to a more agile approach and they’re doing a fairly good job. We will see if it works and if that level of transition is possible at the scale of a 10,000 person company.

But I’m cautiously optimistic about that change. I’d say the easiest, fastest way of doing this is to build a skunk works team. Rather than taking the existing people and processing culture and trying to retrofit a new way, let’s actually build a new team with a new mission to go do something difficult where the only way is agile. And then eventually we’ll take that team and seed them into different places in our organization and create cultural change that way.

Cultural change happens through a mix of bottoms up, buying top down, decision making authority and honestly a trigger. And that trigger tends to be a big fire, something that’s gone horribly wrong and it requires us to reevaluate our processes. And my worry is that we’re going to wait for a lot of big fires to happen. When I look at companies like Boeing, I’m seeing that play out where you have just fire after fire, failure after failure, recall after recall causing these things. And I hope that we can find a way to do it.

I would like to shift the focus to a more technical topic. Do you think modelling plays a role in this transformation and if so, are we going in the right direction? Any thoughts on SysML v2? Are we in a dead end? Are we on the right track? Is it an enabler? Any thoughts on the idea of making our development artifacts more digital through modelling?

I’ve got very strong opinions on this. I am likely to make a lot of people very angry. I went to an INCOSE conference a few years ago and I held back my beliefs. First point here is MBSE is the future. And in my mind there are two big parts of MBSE:

There’s model based definition: Having a view of a system in a model based way and then using digital models, analysis tools, numerical models to help augment that and to make that model richer and more alive. So, unequivocally, if you look on paper, moving from a document-centric view to a model-centric view is, is the future unequivocally. That being said, we think MBSE tools completely miss the mark, we think MBSE tools suck. And if you just show SysML v1 or v2 to anybody in any other industry and you say this is the future of engineering, they will laugh at you. The reason why it’s so disastrously wrong is because the core need for MBSE is to build one unified model that every stakeholder across the organization can use as a source of truth. That’s the core goal for MBSE.

That’s why MBSE was created to build one unifying model that everyone can use as a source of truth. SysML and MBSE tools are so difficult to use that users need lots of training, they need to think about the ontology and they need to think about the structure. And the only people that can use that tool are a few very well educated systems engineers who then put all the information into SysML v2. They sit in a corner and they export out to documents to send to the rest of the team, which means the rest of the team is just using documents, which means the whole point of MBSE is useless! So for MBSE to be successful, it needs to democratize systems engineering.

MBSE needs to give non systems engineers the same view that a systems engineer has and it needs to enable systems engineers to graduate level from doing the documentation work to actually thinking about the system in a more holistic way and to help mechanical, electrical, software engineers all take that same view. So the the biggest things that SysML and MBSE tools get wrong is usability. We need to make these tools beautiful and usable for non systems engineers.

The non systems engineers should be able to pick up an MBSE tool and just go, “Oh, hey, I understand stage one and stage two and the inside of stage two. I live in the engines team. So let me click into the engines team and then let me see the three or four interfaces across the other systems that I need to talk to and let me see the latest versions of those interface requirements with interface values”, and really become a unified model for the whole team. So more often than not, the people that I see in the systems engineering community, they’re the most advanced with MBSE have a a giant wall, they print out a model and they put it on the wall and everyone can use it.

Printing out a Miro or a draw.io diagram and putting it on the wall is actually a better fit for an MBSE than some of the existing tools like SysML v2. I think the intention behind these tools are amazing, but I I don’t think the tools are usable for non systems engineers.

Tooling is certainly an issue, but the modelling language is another one. Proponents of SysML v2 say that the simplification, the text notation and the API will actually make it much more fit for supporting the vision that you described. So: What about the modelling language? And is SysML v2 possibly the future or is it another dead end?

I don’t have strong opinions on the actual modelling language itself. I think all tools have have strengths and weaknesses, but I noticed a lot of systems engineers over index on ontology. Ontology is really, really important and it gets me excited because I can start to think in layers and philosophy and I can start to create structure. I can start to create objects and classes.

But I think it’s probably the wrong approach to start with. I think eventually we get there. But starting with it turns off a lot of people and it creates structure and imposes structure where you don’t necessarily need it. And this is the whole point. If I had to point out one thing that I wished our community was better at, it’s understanding the difference between good process and actually delivering a product.

A lot of systems engineers, especially young systems engineers, read the NASA Systems Engineering Handbook and they read the INCOSE Handbook. And they say if I just follow all thousands of these steps on 200 of these pages to the letter, then I’m guaranteed to have a good product. And then ten years later, they follow every single step and they follow every single directive, and they write shell statements and they don’t release a good product.

What we’ve seen in other parts is maybe too far of the extreme approach, but we say with zero process, zero steps, zero requirements, we’re just going to build stuff and and deliver it. And that actually delivers a product, which is great, but is it safe and reliable? And what we’ve got to find is this nice middle ground. So we’ve got to find a middle ground where we empower non systems engineers to have more of a systems mindset where we help people come into the requirements process and into the MBSE process. And we move it from a silo to something that sits the heart of the team that’s a live model. And to be able to do that, a systems engineer needs to be able to give up a little bit of control on their team to enable non systems engineering teams to better collaborate with them.

I come from the software world from the very beginning. I remember in the 90s, there was much discussion about software components and reuseability. It feels like we are repeating what happened back then, because today all this is provided you, just pick the right architecture for your software project and all those pieces fall in place and you can start being productive in shipping working software.

This is really important to say. UML was rejected by the software engineering industry, right? They tried it, it was a great idea and they didn’t find it useful and it was rejected. And then we cloned it: We’ve changed UML to SysML, we’ve added some features and we we think that that it might work for our use case. I agree with the philosophy and the intention behind MBSE, but I think the specific implementation we might have missed mark.

What role does traceability play in this transformation, and can also comment on Flow Engineering and how you intend to solve this systems engineering problem with your company?

Absolutely. So first of all, traceability is one of the most important things that a systems engineering team needs to get right. It’s the reason systems engineering exists. It’s to help glue all these different functions together, to understand when a change happens in one place, the impacts of that change and to make sure we’ve got really good process to be able to sort that out. Now, traditional systems engineering only really tracks requirements, and it only really tracks requirements at the mission system and maybe subsystem level, but it sort of stops there. So you lose two really important parts of traceability. The first part is requirements at the deeper domain engineering level.

So how do we break a system or a subsystem requirement into specific low level requirements that an engineer can deliver on their V&V? And second, then it loses the design traceability. So we’ve got all these amazing requirements that say here’s what we need to go do. Then we’ve got zero traceability other than linking to it, like maybe a camera or taking a photo of aircraft to actually prove that works. And what we’re seeing happen is a real need for deeper more granular traceability as our systems become more complex and more cross functional.

And this is being reflected in the quality control standards that are happening, too. So if I take one example that I know very well is nuclear. In the nuclear industry are new regulations like NQA-1 now require full traceability, not just on the requirement side, but to specific design assumptions and specific design parameters that drive different elements of the system. So we think traceability is is great, but if you just trace system mission system subsystem level, you’re losing 80% of your design and you’re losing 80% of the value that comes from having traceability. So we need more traceability is my bottom line.

Regarding how Flow Engineering fits into that: Flow is building a modern agile next generation requirements tool. We’re building the the platform that systems engineers have been dreaming of. I’d say it’s the first modern systems engineering tool that looks like it was built in the 2020s and doesn’t look like it was built in the 1990s. And our core thing that we get right is we help systems engineers breakdown requirements from the mission all the way down to the component level and then have live traceability and live integration with non systems engineering teams.

The other big systems engineering philosophy that has been pushed around for a while is continuous integration and continuous verification. And this is something that was adopted in the software industry and that worked, which is to say, hey, we have requirements which are effectively tests. Can we link these tests to our design? And then the moment a design change happens in one team that affects another team, that affects the third team, that breaks my requirement. Rather than waiting three or four months to find that information out, I can find it out instantly. And rather than dropping the ball, I can actually use the computer to automate all the V&V work and to give me faster information on exactly what requirements are and not being there.

So that’s what Flow is doing. Flow is building a next generation requirements tool that links systems engineering and requirements to design and gives you continuous integration and verification across your entire team rather than just one team. We’re now working with some of the best engineering companies in the world.

We’re working with some of the largest and most sophisticated space companies, but also automotive, nuclear, medical device, every major vertical that we operate in. And we’re probably working with the fastest and the best teams out there. I’d say we’re the market leader of the modern requirements tool space, which is quickly becoming a hotly contested market. But we’re probably ahead in every single dimension and our magic is our product. So if you would like to learn more, please take a look at flowengineering.com and you can get a very quick sense of our MBSE capabilities or our requirements capabilities and our integration capabilities.

Pari, thank you very much for your time and your insights.