Enterprise Architecture in Action: Turning Frameworks into Real Impact

When people hear I’m TOGAF certified, they often assume I live in a world of thick binders, endless process diagrams, and governance checklists. Truth is, I’ve seen more enterprise architecture efforts die under their own weight than from lack of intent. The irony I guess is this; EA is supposed to create clarity, not complexity. Done right, it’s not a theoretical exercise. It’s a living practice that connects capabilities, systems, and infrastructure to the business outcomes we’re chasing. Over the years, I’ve learned that the difference between EA that adds value and EA that gathers dust lies in how you practice it, not whether you can recite the architecture framework phases from memory.

When I started out, I used to think good EA meant documenting everything. The more artefacts, the better. Capability maps, current-state diagrams, future-state diagrams, dependency matrices; you name it, I built it. But over time, I realised something: no one reads a 70-page architecture deck. Not the CIO, not the product heads, not even the architects themselves after a month. What works better is a lightweight, structured approach. Just enough architecture to make decisions with confidence, but not so much that it slows the organisation down.  My rule of thumb: if an artefact doesn’t influence a business or technology decision, it’s just decoration. I have in one instance  reduced a client’s EA documentation from 120+ artefacts to 15 critical ones, each tied to a key decision point (invest, modernise, retire, integrate, or monitor). Suddenly, stakeholders stopped seeing EA as bureaucracy and started seeing it as a decision-making partner.

Frameworks like TOGAF can sound abstract until you use them to model capabilities, i.e what the business actually does to create value. When I talk to business leaders, I don’t start with systems or applications. I start with capabilities: What are the things your organisation needs to be great at to achieve its strategy? For example, in a retail client, instead of jumping straight into CRM modernisation, we started with “Customer Insight Management” as a capability. That changed the conversation from “Which tool should we buy?” to “What data and processes do we need to truly understand our customer?”

Capabilities are the Rosetta Stone of EA; they let both business and IT speak the same language. Once you map them, you can overlay:

• The processes that support them
• The applications that enable them
• The infrastructure that runs them

And suddenly, you have a clear, navigable picture from strategy to servers.

I respect TOGAF immensely. It gives a solid structure, the ADM cycle, the architecture views, the governance principles. But I’ve seen too many teams treat TOGAF like a religion, not a framework. I have also seen other enterprise architects that treat the framework they like as religion. Its a framework and as such can be adapted. I blend TOGAF’s discipline with Agile delivery principles. For instance:

• I treat each ADM phase as an iterative loop, not a stage gate.
• I maintain versioned architecture artefacts that evolve like product backlogs.
• I embed architecture sprints to deliver incremental value; like updating capability maps or rationalising an application cluster.

This way, EA becomes part of the organisation’s rhythm, not a parallel process that everyone avoids until a review board meeting. Any frameworks real power lies in its adaptability, I use TOGAF because of its ability to be rigorous without being rigid.

Here’s another truth I learned the hard way: if your architecture lives in PowerPoint, Visio or some kind of UML diagram, it’s already outdated. Architecture needs to be dynamic; connected to data sources, updated automatically, and accessible across teams. That’s why started using tools that allow me to link capabilities to real infrastructure components.

Imagine this:
You’re looking at the “Order Fulfilment” capability, and right there in the tool, you can see:

• The microservices and APIs that support it
• The underlying infrastructure. Say, the bare metal servers or Kubernetes clusters or Azure components
• The teams that own those systems
• The dependencies on third-party vendors

Now, when a system change or incident occurs, you can instantly trace which capabilities are at risk. That’s architecture in action; not static documentation, but a living model that lets you go from business strategy down to infrastructure impact in a few clicks. When I introduced this kind of tooling at a financial services client, it transformed how they handled change requests and ran the change advisory board. Instead of endless email chains, they could see the ripple effect of every change, visually and instantly. Sadly Visio or Powerpoint can’t do this and it makes sense to invest in a purpose built tool. 

The best architectures are not owned by the EA team alone. They’re co-created with business, engineering, and operations. In every transformation I’ve worked on, success came when EA stopped being a separate ivory tower and started being a shared discipline across teams. Here’s what that looks like:

• Product teams map their features to business capabilities.
• Operations teams feed real-time metrics into capability dashboards.
• Security architects contribute controls that directly tie to risk mitigation across capabilities.

The EA team becomes the integrator, the glue that makes sense of it all. It no longer is or needs to be seen as the gatekeeper that blocks progress. When people see architecture as something that helps them make faster, better decisions, they engage. They care. And that’s when EA truly comes alive.

When I look back at the most effective EA programs I’ve been part of, they all shared three traits:

1. They were business-driven. i.e grounded in capabilities, not systems.
2. They were iterative and adaptive. i.e frameworks served the team, not the other way around.
3. They were living and connected. i.e powered by tools that linked strategy to execution in real time.

That’s the kind of Enterprise Architecture we need . Enterprise Architecture should not be a binder on a shelf, but a bridge that lets the business move with confidence and clarity. EA should be the glue between what the enterprise wants to achieve and how it actually gets built, deployed, and run and not about control.  And when you practice it that way, EA stops being misunderstood. It becomes indispensable. 

Cirvesh