One of the biggest problems I see in enterprise software development isn’t technology, tooling, or even skills.
It’s language.
In large, multi-team organizations, there is usually no shared language and no single blueprint that everyone understands and agrees on as the source of truth. Instead, every stakeholder group develops its own vocabulary, its own mental model of “the system,” and its own way of documenting it—if they document it at all.
Take a typical insurance platform that manages the full lifecycle of a policy. You’ll have customers, agents, brokers, distribution partners, carriers, business analysts, product owners, architects, engineers, QA, SREs, TSAs, and many more involved. Each of these groups lives in its own silo, speaks its own expert language, and produces artifacts primarily for its own audience.
Over time, this leads to a scattered landscape of documentation: process diagrams in ARIS, Word or PowerPoint files in SharePoint, technical documentation in Confluence, initiatives and user stories in Jira, architecture diagrams in Miro or Draw.io. None of these artifacts are wrong in isolation. The problem is that none of them represent a shared understanding of the product as a whole. Worse, many people aren’t even aware these artifacts exist, or they can’t access them because they belong to another “tribe.”
What happens next is entirely predictable: handovers.
And handovers are inherently lossy.
We all know the telephone game from kindergarten. The message that reaches the last person barely resembles what the teacher originally said. Enterprise software delivery often works the same way. Every handover subtly changes the meaning, drops context, or adds assumptions—until what gets built no longer reflects what the business actually needs.
Interestingly, other engineering disciplines solved this problem long ago. In civil engineering, everyone gathers around a blueprint. There is a shared language. When an architect talks about a window, the engineer and the customer understand exactly the same thing. That shared model becomes the anchor for all discussions and decisions.
In software, we’ve known this concept for decades. We call it a ubiquitous language. Yet in practice, we rarely establish one that is truly shared across all stakeholders.
A common objection is: whose language should we use? After all, each group has its own terminology and concerns. But if the goal of software is to automate business processes, then the answer is fairly straightforward: it has to be the language of the business subject-matter experts.
Yes, that means technical people need to learn to speak business.
That’s not a loss of precision—it’s a gain in clarity. Especially in industries like insurance, banking, or manufacturing, business processes are not vague or fluffy. They’ve been refined over centuries, long before software existed. Our job is to model and automate them, not replace them with technical abstractions that only engineers understand.
The challenge, of course, is finding a way to express this business language so that it remains precise without becoming inaccessible. One approach I’ve found particularly effective is EventModeling, introduced by Adam Dymitruk.
The core idea is simple but powerful: bring representatives from all stakeholder groups together and let the business experts tell the story of how the business works. That story is then captured visually along a timeline. You can see who does what, when information enters the system, which actions are triggered, what information is needed to make decisions, and which facts are produced as a result.
When done well, an Event Model becomes information-complete. Business rules are expressed explicitly, often as GIVEN-WHEN-THEN scenarios. Events represent facts—things that actually happened. The flow of the business becomes tangible, discussable, and shared.
At that point, something interesting happens. Architecture, implementation, testing, and even operations stop being separate conversations. They all anchor themselves to the same model, the same language, the same understanding of reality.
Until we solve the language and shared understanding problem, no amount of new tools, frameworks, or organizational reshuffling will fix enterprise software delivery.
Originally published on LinkedIn (2026-01-01): https://www.linkedin.com/pulse/missing-blueprint-enterprise-software-gabriel-n-schenker-egome
