Digital transformation fails long before technology is involved

This article is part of our Opinions section, where we invite industry professionals to share their views on the most pressing technology questions of our time.

We’re living in the age of AI. Everyone has a slide about “agents,” “copilots,” and “productivity.” And yet, if you look at what many enterprises actually deliver, it often feels like we’re going backwards. Features take longer. Systems get more complicated. Reporting becomes a debate club. Delivery teams burn out. Not because the cloud is hard, or Kubernetes is hard, or AI is immature. Most transformations fail upstream of all of that.

They fail at meaning.

When an organisation doesn’t share context, everything else gets contaminated: architecture, development, testing, security, reporting, and even AI augmentation. Systems can behave “correctly” and still deliver the wrong outcome. Multi-year programmes collapse under their own semantic debt. Code ships late. The business stops trusting IT. IT stops trusting the business. Everyone starts asking for “more governance.” The more tooling you pile on top of all this, the faster you scale the damage.

Startups seem to get it right

In early-stage startups, delivery often feels easy. Two or three people collectively perform every role: product owner, analyst, UX designer, architect, developer, tester. Context switching happens all the time, almost unconsciously. When the same person defines the business problem, sketches the workflow, and writes the code, misunderstandings are corrected immediately. There’s no translation layer, because there’s nobody to translate between.

Large enterprises work very differently. Roles are separate. Different departments are staffed by different people with different incentives, vocabulary, and mental models. Coordination depends on language travelling through tickets, documents, meetings, chat messages, and diagrams. That’s where things start to break.

When words stop meaning the same thing

Here’s a simple requirement I’ve seen in some form more times than I can count: “I want to disable a checklist.” A business stakeholder says, “Disable the checklist.” A user story becomes: “Set checklist status to inactive.” A developer implements: checklist.visible = false.

Everyone thinks they understood. Everyone is acting rationally. The system even “works.” But what did we encode – disabled state, or just hidden UI?

Now send that into reporting and compliance. Is the checklist disabled or merely invisible? Should an inspector still see it? Should it count toward completion metrics? And if it was “disabled,” what is the audit trail? Five meetings later, you’re debating semantics that should have been settled on day one.

Multiply this pattern across thousands of requests, dozens of teams, and years of delivery. You don’t get a broken system. You get a system that technically functions, but semantically drifts away from the purpose it was meant to serve. This isn’t incompetence. It’s what happens when you operate without a shared vocabulary.

Ubiquitous language is not optional

Domain-driven design has a name for the fix: ubiquitous language. The idea is simple and demanding: The same terms must mean the same thing everywhere: in conversation, requirements, code, tests, documentation, data, and reports.

If the business talks about an inspector disabling a checklist, then the user story should say: “As an inspector, I want to disable a checklist.” The code should expose a behaviour like Checklist.disable(). The data model should represent a disabled state, not an incidental UI property. And reports should use the same language, referencing the same concept.

When this alignment exists, developers understand intent, business stakeholders can read artefacts without having to translate them into their own mental models, and errors surface early, when they’re still cheap to fix. Without it, organisations pay an invisible tax. It just rarely gets booked under the right cost centre.

The real failure: skipping the problem space

In most enterprises, teams spend surprisingly little time in the problem space. A business stakeholder expresses a desire. Technical teams immediately start building the solution. It feels productive. It’s also dangerously premature. Without a shared understanding of domain boundaries, actors, events, and outcomes, solutions get built on assumptions rather than knowledge. Those assumptions harden into APIs, schemas, dashboards, and operational processes, and then become expensive to change.

The root cause is usually misplaced ownership. Language formation gets treated as an implementation concern: “Delivery teams will figure it out.” Business stakeholders disengage once requirements are “handed over.” Then everyone acts surprised when the delivered system is technically correct, but wrong.

Business architecture: the missing link

Business architecture defines domains, capabilities, actors, and the vocabulary that ties delivery to business intent. Yet in many transformations, it’s either missing entirely or disconnected from the team’s actual shipping code. It becomes a PowerPoint deck instead of something people actually use.

Ubiquitous language efforts that emerge only on the delivery side won’t work. Both sides have to own and enforce it: business stakeholders must insist on the agreed terms, use them, and challenge deviations, while delivery teams must reflect them faithfully in code and artefacts. They’re not separate groups running separate operations; they need a shared vocabulary to function. And shared language doesn’t survive on goodwill alone. People take shortcuts, terminology drifts, new team members introduce synonyms, and old meanings lose precision. Staying on top of this is not bureaucracy. It’s basic maintenance.

Why event modelling helps

One technique that consistently works in practice is event modelling. By focusing on commands, events, and models expressed in business language, it produces artefacts that are technically precise and still readable by non-engineers. Vocabulary emerges from the conversation itself: proposal, income, limit, interest rate. And crucially, meanings get settled before code is written, not discovered after systems are deployed.

Digital transformation is a people problem dressed up as a technology problem. Cloud platforms, AI strategies, DevOps pipelines, and platform engineering are all useful, but they depend on language working properly first. Defining domains and enforcing a common vocabulary is hard, unglamorous work. Most organisations skip it because it doesn’t look like progress. It is the work, though, and it belongs to both sides of the business, not just the delivery teams.

Until organisations start treating language as seriously as they treat their cloud strategy, their digital transformation will keep failing, long before technology is ever involved.

More from the same author

• The death of DevOps and the rise of platform engineering
• Cloud AI vs. on-prem: which to choose?
• How AI is ruining my day