Everyone Says Their Architecture Maturity Is Low. But What's Actually Holding Them Back?

Most enterprise architects reach for the same diagnosis, and then the same prescription. After enough first conversations, I've started to wonder whether we're quietly solving the wrong problem.

I've lost count of how many enterprise architects have told me the same thing during our first conversation:

"The enterprise architecture maturity here is low."

Whether they work in insurance, manufacturing, healthcare, logistics, government, or technology, the diagnosis is remarkably consistent. The repository is incomplete. There are no real standards. Projects bypass architecture reviews. Nobody maintains the capability maps. Business stakeholders don't understand what architecture is for. The team lacks influence.

And often, they're right.

But what I've found genuinely interesting is what tends to happen next.

The typical journey

An experienced enterprise architect joins a company. Within the first few weeks, they spot the gaps quickly, because they have seen what "good" looks like elsewhere. So they write the list of things the organisation should have:

• An application portfolio
• Architecture principles
• Governance processes
• Capability maps
• Technology standards
• Better documentation
• Roadmaps

The list is usually correct. These are, after all, common practices in organisations with more mature architecture capabilities. So the architect starts building. A repository is introduced. Standards are written. Models are created. Governance meetings appear in calendars.

Then, roughly two years later, they look around and notice something uncomfortable.

The maturity has improved, but nowhere near as much as they hoped.

The repository exists, but few people open it. I've sat with an insurer whose repository held thousands of meticulously catalogued applications that almost no one outside the architecture team had looked at in months. The standards exist, but projects still find quiet ways around them. The governance process exists, but stakeholders experience it as a hurdle. The capability map exists, beautifully, yet few business leaders can explain how it helps them.

So what happened?

Enterprise architecture is the how, not the what

One thing I keep noticing is that architects and business leaders are often talking about completely different things, even when they're in the same room discussing the same problem.

A capability map can surface duplication and investment opportunities. A repository can reveal dependencies before a project starts. Governance can avoid expensive mistakes. Standards can reduce complexity. These are all valuable practices, but they are means to an end.

Enterprise architecture is the how. The business cares about the what.

When architects focus exclusively on improving the practices, they sometimes lose sight of the outcomes those practices are meant to enable. The most successful architects I've met are very good at translating between the two. They don't open with the repository. They open with better decisions. The repository is just one of the tools that gets them there.

Why experienced architects see low maturity so quickly

Part of the reason experienced architects conclude that maturity is low is that they already know what good looks like. They know the repositories that should exist, the governance that should be in place, the deliverables that would help, and the conversations that should be happening.

The mistake is assuming that implementing those things automatically creates maturity. More often, the organisation first needs to experience enough value to want them. If stakeholders don't see value in architecture, the repository becomes an administrative burden. If project teams don't see value in reviews, they will route around them. If leadership doesn't see value, budget and sponsorship stay thin.

Adoption follows value. Not the other way around.

Why some architects create more influence than others

The most influential architects I've worked with were rarely the people with the most detailed repositories. They became trusted advisors instead. They were in the conversation when initiatives were still ideas. They helped stakeholders spot dependencies before projects kicked off, challenged assumptions, connected people across departments, and reduced risk before it became expensive. They shaped decisions long before anyone started drawing solution diagrams.

In other words, they influenced decisions.

And influence is often a far better indicator of architecture maturity than the number of diagrams that happen to exist.

The trap many solo architects fall into

This is especially common when you're the only architect in the company. Because you're one of the few people who genuinely understands both business and technology, stakeholders naturally start relying on you. You help shape projects, facilitate workshops, translate business needs into technical implications, identify risks, and connect teams.

At some point you might even catch yourself wondering:

"Am I still an enterprise architect, or have I become an IT business partner?"

Ironically, that isn't necessarily a bad thing. Many architects create their greatest value precisely because they operate at the intersection of business and technology. The danger isn't being involved. The danger is becoming so operational that you no longer have time to improve the broader architecture capability of the organisation.

Maybe we're asking the wrong question

When architects discuss maturity, the conversation usually revolves around deliverables:

• Do we have capability maps?
• Do we have governance?
• Do we have standards?
• Do we have a repository?

Those are important questions. They just might not be the first one. Perhaps the first question is:

"Why should this company care about enterprise architecture in the first place?"

Because once the organisation experiences value, many maturity problems get easier to solve. Stakeholders start asking for architectural input. Projects involve architects earlier. Leadership takes an interest. Budgets appear. Additional architects get hired. Governance becomes easier because people can finally see the benefit.

Maturity becomes the outcome, rather than the objective.

A different way to think about maturity

Maybe maturity isn't measured by the number of artefacts you produce. Maybe it looks more like this:

That's a very different lens. And, I think, a more useful one.