Pragmatic modeling: Interview with Christian Tschirner

Christian Tschirner is Deputy Chairman of the Society for Systems Engineering (GfSE). Two years ago, he founded the company Two Pillars, which distributes the Japanese tool iQuavis and develops it further for mechanical and plant engineering. iQUAVIS is a lean platform for model-based product development. iQuavis does not rely on SysML, but on a lightweight data model.

On April 27, 2020, I had a conversation with Christian on the topic of modeling, which focused on pragmatism in system modeling.

Michael Jastram: What is your opinion on SysML?

Christian Tschirner: ONE opinion on the SysML cannot exist. I actually think a lot of the idea of bringing people together at the start of the project and then supporting them with a method in a language throughout. The fact that it has become SysML is a good thing and shows the importance of the task - even if the process of making something uniform out of it has now been going on for 14 years.

But there are birth defects that we are trying to eradicate 14 years later with SysML 2.0. So we are in the middle of puberty. If you then take another step back, with SysML as a profile of UML, then the idea is even older.

SysML is now 14 years old and in the middle of puberty

Christian Tschirner

UML actually had an even simpler starting point than SysML. UML only wanted to bring software engineers together. Nevertheless, paradigms have already been introduced that have turned almost everything upside down. I remember a study on the spread of UML from 2016, which stated that only 8% of the companies in the study were actively using UML. And the big shocker was actually the Systems Engineering Day 2017, with the keynote from Google. Google is the innovative company par excellence. And it turned out that even the non model-based develop.

That really was a big shock for me, but somehow also a relief in relation to my "home" of mechanical engineering. It's not just one domain, like in software engineering! And in systems engineering, the requirement is to incorporate not only technical but also non-technical domains into the project. The task is much bigger. You always stumble when you try to simply generalize the software development approach.

And in my eyes, that can only go wrong. Proof is still needed that it will work. Just because SysML tools are available that have evolved from UML and are also being purchased does not mean that the approach is successful. However, the basic idea makes a great deal of sense. Nevertheless, there are difficulties. However, companies do not have the time or inclination to wait for the difficulties to be overcome. It is important to realize that what helps today helps today!

If I have to spend too much time introducing something big that perhaps only 3%-4% of my workforce will understand at the beginning, then that can't be the panacea. Then I can't dogmatically chase after a language to be developed that is good at its core but doesn't help me today and won't help me tomorrow. Instead, I have to use something that helps me now to launch a product on the market in one to three years. And there are such approaches.

Companies need something that helps them today to bring THE NEXT product to market better. SysML does not fulfill this.

Christian Tschirner

We worked for a long time at Fraunhofer in Paderborn in my field of research SysML because we come from the world of mechanical engineering. Topics such as object orientation, inheritance and the like, which form the basis of SysML, are usually not understood at all. And the companies have even less time because they are developing directly for a customer. They cannot afford an overhead of 10% - even if it would certainly be not only courageous but also sensible to introduce systems engineering. Instead, we have placed a strong emphasis on methodology and introduced this via smaller software prototypes. I think this is particularly useful for mechanical and plant engineering, where many customer- and order-driven projects could benefit from a standardized approach.

People need to be able to document things quickly during customer meetings. Today, they do this "chaotically" with pen and paper. And if I support the technical salesperson with a bit of methodology and a bit of software support to create a boundary diagram, then much more is gained than with a complicated language. There are great approaches that support this. I always say boldly: in the end, it's not about discussing whether the port has to "turn right or left" when modeling, but about what is depicted at the back of the data model. And it's one thing how it goes in and another how it comes out of the data model. And for that I don't need SysML in the first place.

There are actually wonderful pictures of DODAF 2.0 that show that the data model is at the center. All the standards such as ISO 42010 say the same thing, and it has taken a long time for many people to understand this. But more and more are doing so!

The activities of SysML 2.0 are good and going in the right direction, even if we were almost nailed to the cross by the core community in 2012 for the topics addressed in 2.0 today. But we have since licked our wounds. However, I believe that in the long term we are moving more in the direction of an exchange format.

What is the alternative to a notation/language to get effective results in systems engineering?

That's the killer question! The alternative is democracy... the worst possible solution, even though there is no better one. So exactly what is being done today: Word, Excel, PowerPoint, because that's the status quo and therefore always the alternative in the discussion. Because that's where people feel comfortable. People are comfortable, and if nothing convinces them, they stay where they are: "Never change a running system". But keep an open mind: The new approaches are already convincing, as I said, people are just comfortable...

If I want to do model-based systems engineering, then I believe very much in what Sandy Friedenthal said somewhere in his famous book about 12 years ago, namely a hybrid approach. Maybe he meant it a little differently, but I also interpret it in terms of change: I work paper-based and bring people into the methodology, and what I use on the software side is almost irrelevant as long as I can access all the data. This can also be a proprietary approach, because in the end everything is entities and relationships. And digitalization with topics such as artificial intelligence will help me to formalize informal content in the short or long term anyway.

If we are talking about entities and relations, then a DOORS or a modern alternative like Jama should be sufficient, right?

These tools have good approaches, but their usability is designed in such a way that they are quickly misunderstood and used as improved Excel. The fine granularity of data elements can quickly be used differently. The danger of incorrect use is now so firmly anchored in people's minds that it is no longer enough in my view. There have to be two changes:

Firstly, we need clear usability. People need to be limited in what they can model, which brings us back to methodology. Secondly, the price. This is not a plea for open source, but for a finely modular, easily understandable structure of the software I offer. Pricing must be based on the needs of the customer.

Then you would have to use the Capella with the Arcadia method, right?

That's the theory. The approach is fine, but still: BMW, Audi and other manufacturers all build good cars that can be placed on the market. I don't think the monopoly of a single software is expedient.

I come across Capella more and more often. I still have to invest a lot if I want to make good progress with this approach. I know that a well-known automotive supplier relies heavily on Capella, which makes me happy. It's a smart approach. But I come back to mechanical and plant engineering: if I don't invest, it's difficult to get beyond simple painting, even with Capella. I need a connection to methods in product development, I want to fuel an FMEA, track issues, and so on. You have to invest a little in order to do more than just paint. But as a mechanical and plant engineering company, I'm at a loss if I either have to have everything developed for every customization and every request or have to buy it in at a high price from the outset.

If I don't invest in modeling, I can't get beyond simple painting

Christian Tschirner

How does your product solve iQuavis this dilemma?

Our approach is "Do Systems Engineering". We manage to get a team working independently with the software within half a day. It makes sense - yes, classic consultant! - however, process support. But: iQUAVIS can also be introduced without process customization. I can map the current way of working and still have the advantages of model-based systems engineering. I have the collaborative aspect with me. Hence the company name Two PillarsThe two pillars of a good engineering project: a good system specification coupled with project management + collaboration, which also includes methods and processes. We are actually a small, simple platform.

Where does the development methodology at iQuavis come from?

There are three streams. iQuavis means "Quality Visualization". The use of data was the actual trigger for quality purposes at Toyota. Project management issues arose in parallel. Both are based on a database. Thirdly, classic development methodologies were added and meticulously implemented. The whole thing is strongly influenced by Japanese culture: As simple and lean as possible. At some point, our Japanese colleagues came into contact with the research work of my department at Fraunhofer, where we had been supplementing SE methodology from the perspective of mechanical and plant engineering for years. We first did this at project level in Japanese automotive engineering and then decided that we would rather bring it to Europe. We then transferred our work into the tool that we are now developing further in Germany.

What will be the biggest challenges in systems engineering over the next five years?

In my opinion, these are three things:

Firstly, a lifecycle approach! But I don't necessarily mean just PLM. I find it fascinating what is technologically possible, including the products for smart maintenance that are coming onto the market, for example. But I have the feeling that they are all islands again. The best smart maintenance solution is of no use to me if I don't close the life cycle forwards and map the problems that I find in the field to the requirements and draw a benefit from this for the new product development. As long as Word, PowerPoint and Excel are the blunt weapons in the hands of creative and good engineers, I will have great difficulty closing this circle. The knowledge is still in people's heads, but nobody can know what effect the changes will have - it's beyond their cognitive capacities.

The second is the leap from technical specification to communication. If I don't go into something that is model-based, I can't start effective problem- and solution-oriented communication. This is a major problem in collaboration and this realization has hardly been accepted so far. Through Corona perhaps a rethink could take place here.

My third point, however, is that I am concerned that there is too much irrationality when it comes to digitalization and business processes. People are only ever looking at the one big thing, the complete end-to-end digitalized development environment, which in my opinion is technologically, procedurally and cognitively impossible as things stand today. Any smaller solution is seemingly unattractive, but actually makes more sense - because it involves people and can also evolve.