Why we need new development tools: Insights into MBSE by Pari Singh (Part 1)

Interview Part 1 | Part 2

Systems engineering as it is practiced today is broken - at least according to Pari Singh. He believes that development tools are stuck in the "dark ages" and is determined to change this. And he is well on the way to changing this with his company Flow Engineering.

Pari Singh trained as a mechanical engineer and was included in the 2019 Forbes 30 under 30 list. With his company Flow Engineering, founded in 2019, he wants to revolutionize product development.

I had the pleasure of talking to Pari Singh on June 21, 2024 about systems engineering in general and MBSE in particular. Below is the conversation in text and as a video.

Note: On August 1, Michael Jastram will host a webinar on Raiqon's AI extension for Codebeamer in automotive development. Register for free >>

This article was also published in English on the Formal Mind blog.

Pari Singh & Flow Engineering

Although Paris company, Flow EngineeringSaaS software, the company has made an incredible pivot. Pari started out as a mechanical engineer who was impressed by SpaceX, which propelled him into the aerospace industry. Around 2010, while still at university, he founded a rocket engine development company.

As a result, Pari quickly set up a company that was able to deliver rocket engine designs within hours where the competition took months. He achieved this by building a sophisticated network of interconnected models (Matlab, CAD, FEM, etc.) with feedback loops. He realized that the market agile hardware and that the commercially available tools were completely unsuitable for teams that wanted to work in an agile way.

This led to a reorientation of the business model. When he talked to investors, they realized that (1) traditional development fundamentally no longer worked, (2) he had invented a new approach to mechanical system development, and (3) that if his company could find a way to formalize this and give it as a product to their original customers, they could solve the problem they had originally founded the company to solve, which was to help the entire industry move much faster.

To gain market acceptance, Flow's top priority is the end user. Companies like Dassault or Siemens sell to the chief engineers or decision makers, which often results in a mediocre user experience. For Flow, better usability for the end user is key. The company expects decision makers to be convinced when users recognize the value of the solution.

Interview with Pari Singh

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

You clearly express your opinion on the agile engineeringwhich has now proven its worth. Why do so many companies find it difficult to introduce it?

I'd like to say something about the context of this change, because I don't think the systems engineering community has a good definition of exactly what the change is yet. A lot of people say, Agility means two-week sprints, software MVPs, but that doesn't really describe it. So I'd like to take a step back and give an overview of the context in which this change is taking place and why it is so important.

The systems engineering community is currently undergoing the kind of change that rarely happens. The last time a change of this magnitude took place was probably in the 1960s when systems engineering was in its infancy. This change is moving from a more traditional, top-down, waterfall 10-year design cycle, which is about working with external contractors and being very rigorous, to a much more agile and iterative workflow. And that means two things.

Firstly, it means that there is a mixture of top-down requirements management and bottom-up design. In the past, when our systems were less complex, we could define all our requirements from the mission to the system and subsystem level down to the component level and be right with those assumptions. But as our products have become much more complex, that's no longer possible because our systems are now so complex and cross-functional that a tiny change in one team can lead to complex changes in other teams and other organizations, which in turn cause complex changes. And in most cases, we have not developed a system of this scale or complexity. Often we don't fully understand the system interactions between software and hardware at the beginning of the project. And these things need to be understood as the development progresses.

It is therefore the change from waterfall to agile. Waterfall is largely top-down and designed to avoid change. Agile means that we have assumptions about our requirements in the initial phase, but we are open to new things because change is inevitable.

And we will certainly not be right with all our technical assumptions because we have never built anything like this before. That's why agile teams don't just break down the requirements from the mission to the system or subsystem level, but they let the requirements flow from L0, L1 down to L3, L4, L5. They therefore have a complete Traceability from the order level down to a specific component level. This is the first major change.

The second big change is the realization that the iterative approach is the way to go. An acquaintance in my network recently told this story that if you want to build a six-inch telescope, it's usually faster to build a three-inch telescope and then build a six-inch telescope than to build a six-inch telescope right away.

That's a really good analogy. The best teams in the world don't start with the most complicated version and try to lock in their assumptions early. Rather, they find the smallest unit of an integrated system that they can build to reduce risk and learn from their assumptions. And then they iteratively add more layers over time to learn and develop very quickly.

If I may rephrase that: You are proposing the MVP-The only difference is that we can continue to develop the product with the software, while you have to build a second telescope for the hardware. But the idea is the same.

Exactly. This approach sounds very wasteful. Hardware engineers don't like it because they have to build three times instead of just once.

But if you look at companies like SpaceX, Tesla and the fastest growing companies in the world, we see that this approach is much more efficient than the traditional approach. For example, if you look at the Starliner from Boeing compared with the Dragon from SpaceXyou realize that the Dragon has achieved more in half the time and at half the cost. You have built several Dragons, learned from them and discarded them. This iterative approach sounds slower and more expensive. But in practice, it has proven to be much faster, more efficient and safer to work this way.

I can only agree with that. I have to think about the Starship test flights: what really bothered me was the headline I read on Tagesschau the other day: "Starship" test flight successful on fourth attemptwhich implies that the first three were not successful.

We really need a paradigm shift where people understand that an exploded rocket (on a test flight) is not a failure, but a successful test because it delivered data. So how can we achieve this paradigm shift?

This is very difficult. The key is to focus not on meeting requirements, but on learning. This is one of the things that SpaceX is always doing in the live stream for IFT-4 has repeated. You said the payload is the data. It's not about the successful flight, it's not about us meeting all our requirements, it's not about us successfully completing our V&V. But the payload is the data.

And if we're able to get really good data from the vehicle and understand its exact limits, where we do well and where we do poorly, then we can develop the IFT-5 or the next rocket much faster, much better and much quicker. So in essence, it's about focusing on learning. The next step that follows from this is: How can we learn as quickly as possible?

The second major difficulty for systems engineers is getting out of the "land of requirements, analysis and thinking" and into the "land of action". This is a very difficult transition for systems engineers. I can empathize with that: I'm a mechanical engineer by training. I spent my entire early career developing analytical models to develop rocket engines. But you learn a lot by just building the smallest thing, testing it and then building the next and the next and the next. And if you look at Apollo, that's a big part of what they did.

The engineers have realized that although they have to carry out the Apollo missions in order to fly to the moon, they will not be able to land on the moon directly from "here". Before they can land on the moon, they have to orbit the moon. To do this, they need several rocket stages. Before that, they have to orbit the Earth. To do this, they have to pass through the Kármán lineto get into orbit. And the fastest and cheapest way to overcome the Kármán line is to fit a rocket, as it existed at the time, with a human at the top and launch it. The fastest way to learn was to retrofit a human on an ICBM rocket and then 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 feasible with the technology available. But I don't agree with the statement that the systems engineers don't want to deviate from the requirements.

I think it's more about the fear of decision-makers who think that an exploded test rocket will be seen as a failure, which is not the case. So again, how can we make this paradigm shift? How can we talk to decision-makers and enable them to give engineers the freedom to work in an agile way?

Let me give you two or three answers and some context again. I think context is really important for our industry: if you just look at where we are today, the way we develop makes no sense at all. But if you look at it in the broad context of the last 20 or 30 years, it suddenly becomes clear why we work the way we do. Systems engineering emerged from the first publicly funded missions, the space missions. Those were the beginnings of what I call real systems engineering. And that is usually funded by the taxpayer.

It's usually a mission that we've never done before and it's very, very difficult. And that's the result of those two things: When Congress appropriates money, when taxpayer money goes to missions that are very, very complex, that involve a lot of people. Then the paradigm is that you have to get it right the first time. If a politician spends 10 billion dollars or a billion dollars on this big mission and it fails, then it looks really bad. That's the origin of systems engineering But now we're seeing private companies copying all the mistakes of publicly funded missions. And that's the mistake. The mistake is to assume that the same rules apply as a private company that wants to make money and make really great, safe, reliable products and move very quickly. That's the fundamental change that we need to understand and implement.

This explains why start-ups have managed to adopt these approaches and why large existing organizations are struggling. Do you have any idea whether and if so, how existing large organizations can make this change?

If you had asked me this question three years ago, I would have said it was impossible. There is a great principle in science that says the way to revolutionary change is to let the old people die out and let the new generation grow up. I am really glad that I have been proven wrong on this point.

So I look at certain companies like Blue Origin, which actually started with a much more traditional, conservative model. They hired a lot of executives from Northrop Grumman and other traditional aerospace companies and embraced that culture, which almost killed them. They're currently transitioning to a more agile approach, and they're doing quite well. We'll see if it works and if such a transition is possible in a company with 10,000 employees.

But I am now cautiously optimistic about this change. The easiest and quickest way to achieve this is to build a Skunk Works Teams. Instead of taking the existing people and the existing culture and trying to retrofit a new method, let's build a new team with a new mission to do something difficult where the only way is agile. And then we take that team and deploy it in different places in our organization to create cultural change that way.

Cultural change happens through a mixture of "bottom-up", "top-down", decision-making powers and - to be honest - a trigger. And that trigger is usually a major fire, something that has gone horribly wrong and forces us to re-evaluate our processes. And my concern is that we're going to be waiting for a lot of major fires to happen. When I look at companies like Boeing, I see fire after fire, mistake after mistake, recall after recall causing these things. And I hope that we will find a way.

End of part 1

The second and final part of the interview will be published on 11.08.2024 (the link will not work before this date). If you would like to know what happens next, you can watch the video embedded above or read the full interview here in English.