After the previous post discussed the advantages of Excel and the lessons one should draw from it, the analysis continues here. No worries — not Excel again. The blog shouldn’t lose its credibility right at the beginning, and Microsoft wouldn’t pay for that anyway. The focus lies on MBSE in companies and how it is represented in existing enterprise software, or rather how well it is conceptually integrated.

Since examples are well suited to analyse and illustrate matters, this blog entry begins with such examples — though with ones that at first glance seem to have little to do with the topic:

• Germany’s elimination at the 2026 Football World Cup against Paraguay in the round of the last 32 teams
• Stuttgart 21: a German railway project that was supposed to open in 2021 and is now not expected to be completed before 2031. Cost increase from €2.5bn to over €11bn
• Berlin Brandenburg Airport. Planned opening 2011. Actual opening 2020. Cost increase from €2.5bn to over €7bn
• Mars Climate Orbiter (1999). Loss of the probe due to differing units
• Space Shuttle Challenger (1986). O-ring failure leading to the explosion of the shuttle with 7 fatalities
• Fall of Constantinople (1453) and the end of the Byzantine Empire
• Sydney Opera House (1959–1973) with a ten-year delay and a fourteenfold cost explosion
• Near-extinction of the Kakapo in New Zealand. Current population approx. 250 animals

Now the decisive question: What do all these examples have in common? As in well-known assessment centre tests, the answer is: “It depends on whether…”

Exactly like the question: Which element does not fit in the following list?

Apple, banana, pear, peach, watermelon, toilet bowl?

Obviously the answer is peach — the only element with a fuzzy rather than smooth texture. And just like in such tests, only one — a different — answer is expected above. So why deviate from this familiar pattern? Let’s keep it.

In fact, there is more than one commonality. The most obvious is failure or breakdown in the sense of an unintended outcome. Sure, in Paraguay the victory over Germany was declared a national holiday… and there are voices in England that demanded the same for the British Isles after Germany’s early exit. And the Ottomans in the 15th century would hardly have spoken of failure. These “special” perspectives are not the topic here. The correct answer is: toilet bowl.

The second commonality is a truism: hindsight is always wiser. But there is an extended observation that seems to appear after every failure: people who claim they always knew it, who foresaw the catastrophe early on. During the World Cup, everyone mutates into an expert.

A short digression must follow: Argentina and all football fans may forgive this — losing a World Cup match and being eliminated is not a catastrophe like the loss of human life, even if media coverage suggests otherwise.

Life is not fair: those who succeed have many “friends” and nothing to explain. Those who fail must justify themselves. Combined with human behaviour and self-enhancement, it becomes difficult to distinguish between substantial voices and those that fall merely into the category of self-promotion.

Of course, after catastrophes investigations take place. But in smaller or medium failures this is often not the case. Responsibilities shift and self-interest dominates.

This brings us to the third commonality — or the question of whether such a commonality exists. If, after failure, there are voices that not only claim they knew things beforehand, but are substantial voices that had spoken up earlier, why did failure occur anyway?

Let us therefore turn to the “peculiar” bird from the title — the Kakapo.

Anyone who has spent time in New Zealand knows that from the outside there seems to be more than one peculiar creature there. And this is not about the human inhabitants. They undoubtedly possess a healthy dose of self‑irony, which makes them very likeable:
How else can one explain that they use the kiwi — a flightless bird — as an emblem on their military aircraft? (You simply have to love the country and the Kiwis, as they call themselves.)

Douglas Adams describes the peculiarities of the Kakapo in his book Last Chance to See (1990) in an unmistakable way. I will only summarise here and otherwise recommend his book.

The Kakapo is, at up to 4 kg, the heaviest parrot in the world. It feeds on plants, is nocturnal, and with a lifespan of 90 years extremely long-lived. Since it is unfortunately also flightless and exhibits further curious traits, it would hardly reach such an age today without protection and in the wild.

Because New Zealand historically had no mammalian predators, the Kakapo freezes when threatened and relies on camouflage. This works with aerial predators. With dogs and cats — known for excellent sense of smell — only as well as a small child who covers its eyes and believes it cannot be seen. With the difference that children are generally not eaten — the Kakapo, however, is.

Matching the hide‑instead‑of‑flight concept, it also emits no warning calls when threatened. This would contradict the principle of hiding and would be pointless, as it is a solitary animal. But pure solitary animals cannot form a species, so mating occurs regularly. Regularly for Kakapo females means only every 2–4 years, when there is an abundance of Rimu fruit. The more active role falls to the females. They must first find the males. As mentioned: solitary.

The males do make an effort: they build bowls — depressions — and emit low‑frequency mating calls (“booming”) to attract females.

This has two drawbacks.

1. Low‑frequency sound travels far but is harder to localise. Anyone with a subwoofer knows the phenomenon.
2. The more difficult localisation succeeds more easily or quickly for predators than for the intended females, so when the latter do manage to find the origin of the call, they often find only the bowl and some feathers. The rest of the suitor is in the digestive tract of a predator.

In summary, the Kakapo has a massive communication problem — amplified by the lack of adaptation to changed conditions.

Insufficient, poor or missing communication is exactly one — or the decisive — reason for failure in the examples listed above. It forms the central third commonality.

We now change the scene: away from the peculiar bird and towards Lifecycle Management and MBSE — but without losing sight of the Kakapo’s communication problem.

Lifecycle Management

We begin with an overview of Lifecycle Management and what it denotes or means in the context of product manufacturers.

The term “Lifecycle Management” suggests using a circle for illustration:

The lifecycle of a product can be roughly divided into five phases:

1. Ideation & Concept
2. Development
3. Production
4. Service & Operation
5. Retirement

Neither the division nor the names are fixed. Finer subdivisions and deviations are common.

The structure simply follows the temporal sequence a product undergoes: from the first idea, through concept, development, manufacturing and distribution, to disposal or recycling.

At this coarse level, there is no complexity. It would be a simple linear process. If one wanted to integrate the V‑model commonly used in engineering, one would simply straighten its legs and insert it into the circle in place of the development phase.

But the V is chosen for a reason. It itself represents cycles. The above cycle representation is not wrong, but incomplete regarding complexity.

An extended illustration is shown in the following figure:

The earlier blog post pointed out the usual distinction between projects and systems as associated with products. Curiously, the term “lifecycle” would be more fitting for large projects than for product development. It suggests that only after the end of a product’s life a new generation begins. This may be true for highly individualised craft products, but not for industrially manufactured ones. Especially in software, cycles are much shorter and do not run through the entire product lifecycle. Once the first concept is completed, work begins on a new or revised concept while other phases still work on the previous one. If speeds were identical, processes would only be phase‑shifted. Due to unavoidable differences in effort and duration, multiple assets exist in parallel. Products consist of components with their own revision cycles. Complexity increases enormously. Not one asset, but several parallel ones must be managed.

Before revisions, reviews often take place. Depending on industry, company size and product complexity, these vary in scope and involve more than one department and more than one specialist.

In addition to these cycles, another factor arises: not only versions and revisions are processed in phases and in parallel, but also variants — from fixed product families to highly individualised customer‑specific products.

This aspect is illustrated in the following figure.

For product families, the lifecycle begins like for a single product in the ideation and concept phase. Here markets are targeted and features per customer segment and regulatory region are defined. They can be divided into two groups: those shared by all products in a family and those possessed only by a subset.

Further differentiation may occur in development if the concept‑phase differentiation is insufficient. Ideally it follows the variant strategy of the concept phase. Development is also the phase where solutions can be tested and discarded and customer‑specific adjustments made. Depending on perspective, requirements specifications are created at the end of concept or beginning of development. Manufacturers do not develop alone but use suppliers. The concrete specification is part of the supplier’s specification. Over time, further variants arise. Additional differentiation follows from different test sites. Different test environments require specific procedures and parameters — both in development and production quality assurance.

Further differentiation follows the same pattern in service and operation — think of service protocols or user manuals.

Another differentiation, essentially part of development, follows a different objective: modularisation. It aims to offer many end variants with as few identical components or subsystems as possible. Modules are formed, achieving consolidation. Module decomposition can cut across functional features — only multiple modules together achieve a functional feature.

The retirement phase is not discussed further here. It is becoming increasingly important due to sustainability laws. The mechanisms are similar.

Organisational Structure and Information Flows

A functional division into organisational units looks like this:

1. Product Management
2. Sales
3. Engineering
4. Quality Management
5. Procurement
6. Manufacturing
7. Logistics
8. Service & Operation

External actors:

1. Regulators
2. Suppliers
3. Customers

As with the subdivision of the phases, this structure and these labels do not represent a specific company structure, but functional groups. Additional ones are subsumed here for the sake of simplicity.

The interesting part emerges only when placing them in a matrix together with the phases:

In this representation, it is illustrated in which phase each actor is active. As a reminder: this refers to the phases, not to real time. Otherwise, one might consider outsourcing product management for cost‑saving reasons, since it appears to be underutilized. A translation into real time would reveal differing levels of effort as well as parallel work. Depending on the chosen subdivision, slightly different activity matrices are also conceivable. Hence the repeated note: in a company, the assignment of departments to functional organizational units may differ from what is assumed here.

This form of representation enables something else: it marks the space of all conceivable information flows. That is, it allows potential communication points to be delimited. The sequence of phases corresponds to the processing direction. This describes the horizontal dimension. Vertically, information flows arise between actors or organizational units that are involved in the same phase at the same time. This is where results are aligned, supplemented, or refined. This is where the review cycles take place.

Diagonally, information flows arise between actors that are involved in adjacent phases.

Information flow means nothing other than passing on a result — in short: communication. Since I don’t know whether italics alone are sufficient and Lilu already threatened to leave Configena if I attend a training course in operant conditioning, here’s the hint: Kakapo!

MBSE in Context

Let us now turn to the topic of MBSE and its classification. As a reminder, here is the definition as used by INCOSE:

“MBSE is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.”

If one compares this definition with the lifecycle landscape outlined above, one would locate the main focus of MBSE in the development phase. However, it also states quite clearly that the application of MBSE is not limited to this, but instead covers the entire cycle, from the first to the last phase. That MBSE is more than SysML, diagrams, and system architecture was already emphasized last time. This raises the question of what other software exists in companies in the area of Lifecycle Management?
The short answer: a great deal.

Here comes a list:

Apart from the fact that very few people are likely to know all of these abbreviations, many of them would hardly be associated with Lifecycle Management — and even less so with MBSE. A description of all of them is omitted here, as is any claim to completeness of the list. Instead, the following presents an attempt to classify these tool categories within the lifecycle‑activity matrix shown above, and then to examine one example in more detail.

The stars in the figure mark the focal area in which the respective tool category is situated. The organizational and phase domains each extend beyond this focal point. SE and RM here stand for Systems Engineering and Requirements Management — meaning that SE represents precisely those tools one would most readily associate with MBSE. Contrary to the placement just mentioned earlier, both of them appear here in the ideation and concept phase.

These terms are not protected designations but categories originating from for example research work and shaped by individual authors. Companies assign their solutions independently — and driven by marketing — to one segment or another. This leads to the situation that individual solutions from vendors may cover very different areas. Company and product acquisitions in recent years have resulted in more areas being addressed, although the respective focal points may differ. The impression one gains is that integration is hardly addressed adequately. In some cases, identical or at least overlapping areas within a vendor’s portfolio are covered by different product solutions; in other cases, gaps emerge. Beyond strategic considerations, the expansion of product portfolios reflects the realization that the complexity outlined above — and the resulting needs of customers — must be addressed comprehensively. In addition to acquisitions, alliances and partnerships play a role. Little new legacy is created; instead, existing legacy is expanded. This makes true integration more difficult.

Two competing customer wishes stand in opposition here: on the one hand, the desire for maximum integration — the all‑from‑one‑hand solutions that large vendors are most likely to promise — and on the other hand, vendor independence and diversification. There is therefore a perhaps not entirely new but more recent domain addressed by small to medium‑sized companies and startups. They are not true connecting elements. Put simply, they do not operate within the existing data but on top of it. That is, they take the existing data and integrate it into their own perspective — nowadays often marketed with AI approaches. Another frequently used term in this context is Single Source of Truth. This works until they are acquired. Then they become a component in the so‑called Digital Thread. And the legacy grows.

A provocative question: How is a Digital Thread supposed to be realized under such conditions?

ALM (Application Lifecycle Management), PLM (Product Lifecycle Management), and CLM (Configuration Lifecycle Management) already carry the term ‘lifecycle’ in their names. Semantically, they all address the holistic, cross‑phase approach most strongly.

As an example, let us now consider PLM. The term ‘Product Lifecycle Management’ suggests a continuous coverage of all phases of the lifecycle. In practice, however, it becomes evident that PLM does indeed address central areas, but by no means covers the entire space of information flows. The following figure represents an attempt to capture what PLM actually encompasses. As a reminder, this does not imply that specific software solutions cannot deviate from it.

In direct comparison, the following shows the same figure for ERP (Enterprise Resource Planning).

The form of representation with connecting lines from the focal point to the additional points of linkage is freely chosen. It highlights the area of coverage, but does not depict the information flows — or, more precisely, the communication paths.

Three points stand out:

1. A real digital thread is not a linear thread but a net of interconnected thread pieces.
2. The examples of PLM and ERP clearly show overlapping or adjacent areas. In a holistic view, these represent the boundaries or barriers that must be overcome in communication. They are typical points at which Excel or CSV file imports and exports occur.
3. Conceptually almost identical solutions exist in different domains. Examples include state machines and activity diagrams in engineering, compared with BPM models and business processes in the commercial environment. Although they represent similar mechanisms, they are used in different domains, given different names, and developed separately. As a result, parallel but independent descriptions of the same subject matter emerge.

All three points are essentially matters of communication.

Before diving deeper, a fundamental question arises beforehand:

Why should one even want to strive for a continuous information structure? For what purpose should the realization of a Digital Thread be made a goal — or even elevated to a strategic instrument?

The answer is simple: Ultimately, it is about enabling well‑founded, transparent, and at the same time faster decisions.

Take as an example the image sketched above, illustrating the complexity of the product lifecycle shaped by variants, modularization, and product and component versions that must be maintained in parallel:

A single component can exist in multiple variants and versions. It is part of one or more modules that are installed in several products with multi‑year operating lifetimes for which spare parts must be kept available. For manufacturing, subcomponents are required that can be sourced from different external suppliers. There are various production sites for the component with differing manufacturing times. There are inventory stocks of the component, it can be assigned prices, and modules containing this component can be offered as product options in sales. Additionally, applications run on the module and component or integrate it.

Thus, the component is not merely an engineering asset but becomes the subject of decisions ranging from product management to sales strategy. A kind of emergence arises that goes beyond — for example — dimensional measurements.

It is this perspective shaped by multiple viewpoints that enables an asset item to be represented within a larger model space with multiple layers of information, and that constitutes the value of MBSE.

This requires a shared information space in which, so to speak, a common language is spoken — one in which each party is responsible for its own domain, yet communication between them can take place without major obstacles.

What was observed above describes the opposite: fragmentation, obstacles, multiple languages requiring constant translation.

A Peculiar Bird Returns

It is time to return to the Kakapo and its “own” communication problems — to see what can be learned.

Anyone who has been out and about in European major cities in recent years could observe a behavior there — especially on mild summer nights — that is strikingly reminiscent of the Kakapo.

The reference is to male individuals who — in their demeanor reminiscent of teenagers, though their appearance suggests they must be older while still not having reached middle age — drive powerful vehicles around city centers. From the perspective of this group, the louder and more low‑frequency the noise emitted by the vehicle, the better. Whether the courtship sounds produced by the vehicles achieve the presumed intended effect on the fairer sex has not yet been scientifically demonstrated. Doubts are warranted. What is, however, confirmed is that it attracts the police — comparable to the predators in the case of the Kakapo male. Here, too, a communication problem exists.

Despite these similarities, there is a decisive difference that helps to understand communication. Following Douglas Adams’s example, a context was established that makes the Kakapo’s courtship behavior — and the production of low‑frequency sounds within it — appear completely absurd.

What sense does it make to produce signals that cannot, or can only barely, be located? Quite simple: the actual purpose of emitting the signal was never localization!

The described group of male individuals does not perform its courtship behavior with their vehicles on remote fields in rural areas, expecting that the female sex will be attracted from afar by the sound. They do it where an appropriate audience can be expected! The city is the tacitly agreed‑upon mating ground.

The Kakapo population before the arrival of cats and dogs in New Zealand is estimated at up to around 100,000 individuals. The population density was correspondingly high, so that random encounters worked better. In that moment, the task was to convince — not merely to draw attention.

How Communication Works

1. It requires senders and receivers who can switch roles during communication. Put differently, it requires the right addressee.
2. It requires functioning signal transmission.
3. It requires a shared protocol allowing shared interpretation and possibly decryption.
4. It requires a filter allowing the receiver to separate the intended message from simultaneous information.

If one of these is missing, communication fails.

What goes wrong in the Kakapo’s communication? What would the Kakapo need to change?

The answer, as so often, is ‘It depends on whether…’.

One would spontaneously tend toward ‘Lack of functioning signal transmission’. Assumption: the mating call says, ‘Come here, I am here!’ Then the information of ‘here’ is missing, simply not transmitted appropriately. Correct? Only if one interprets the mating call that way. Otherwise, rather not. No one would come up with the idea of saying that two people had communicated when a phone call was missed.

Communication begins only when the Kakapo female sees the male and hears or feels his call. The communication is more complex; it is audio‑visual, it is multimodal, and it includes the male sitting in the bowl and producing sounds. Together, this says ‘Take me!’ — not the mating call alone.

A communication problem that exists for the Kakapo is that the mating call is indeed part of perfect communication — unfortunately with the wrong addressee. Here, the problem is the appropriate communication protocol. When the Kakapo sends out ‘Toujour amour!’, the cat hears: ‘There is something juicy to eat. You just have to find me. Come! I am delicious!’

Incidentally, in scientific circles the thesis is also put forward that the mating behavior of the described group of male individuals represents a double communication problem of the third kind: sexually receptive female individuals are said to feel rather repelled by it. Just a side hypothesis.

Hypothetical Solutions

What would the Kakapo hypothetically need to change?
Since this concerns a hypothetical solution, one can consider various approaches:

1. The Kakapos take their cue from the group of male car enthusiasts and relocate their courtship behavior to a tacitly agreed‑upon place. Searching and finding are shortened, and thus the courtship itself as well. The problem: just as the police do not look for their ‘candidates’ in remote fields, mating sites will soon become known to predators.
2. The Kakapos supplement their ‘call’ with a location indication — say, by modulating the call or in the style of Morse code. The female can find the male more quickly.

Both solutions address part of the problem. These approaches correspond, in a figurative sense, to what happens today in the software landscape — how tool and information integration is carried out. The information space is additionally expanded.

However, in the approaches mentioned, one essential point has not been addressed at all: if the message ‘Take me’ continues to be communicated through a clearly visible bowl, the male visibly sitting in it, and booming, the risk of being found by predators remains high. This audio‑visual structure follows an evolutionary, unwritten rule.

The fragmented tool landscape follows the same pattern. That is why parallel solutions for essentially identical questions persist.

Semantics, Structure, Rules

The hypothetical solution for the Kakapo male would be to focus on the semantics — that is, the meaning and core of the message — and convey it differently. To establish a structure and new implicit rules as a protocol for the female.

Here, as said, hypothetical, since evolution is not a process adjustment within a single generation. For the group of sports‑car enthusiasts, it would likely be difficult to persuade them instead to — say — write poetry. But with regard to MBSE according to the INCOSE definition, there is hope.

This is both conclusion and bold thesis.

The distinction between semantics, structure and rules may be key. One final remark:

When people with different languages come together, they still learn to communicate over time. Creole languages are exactly the result.

They follow the principle: rules follow structure, structure follows semantics.

Why then do today’s IT tools still follow the opposite paradigm — and why is it not broken even with AI?

So far up to this point. More — and also examples — in subsequent posts.

Stay tuned!