Building an Enterprise Architecture Capability

Enterprise Architecture is widely recognised as an essential capability to drive and manage technology strategy; yet many organisations still don’t have an enterprise architecture capability that actively shapes strategy, investments, and day‑to‑day delivery. Too often, EA is either a documentation factory, a gatekeeper that slows change, or a theoretical function divorced from execution. Without a dedicated EA capability, organisations are trapped in a chaotic cycle of overlapping functionality, legacy "zombie" systems, and a Total Cost of Ownership (TCO) that is barely understood.

CIOs, CTOs, and Heads of Architecture need to either build or rescue an EA function. The C-suite is asking for value realisation and risk reduction delivered through technology leadership that understands the landscape and drives strategic decisions that support the organisation’s value drivers. The C-Suite is not looking for another inventory of systems; rather, building an EA capability, whether from scratch or by uplifting existing processes, is the only clear, actionable path to deliver that value. The EA capability is not a project; it is an ongoing operating capability that must be funded and run like any other.

This article sets out a practical way to build an effective enterprise architecture capability, whether you are starting from scratch (greenfield), modernising a long‑standing function (brownfield), or doing what most organisations actually do: evolving a messy hybrid.

The core idea is simple: treat enterprise architecture as a governance and decision‑support capability that connects business strategy to technology execution, not as a set of diagrams or standards. Everything else follows from that.

• Phase I: Discover.

• Phase II: Design.

• Phase III: Govern.

• Phase IV: Operate and Optimise.

Defining the Context: Greenfield, Brownfield, or Hybrid

When developing EA practices, most organisations fall into one of three starting patterns:

EA Start Type	Typical Situation	Key Risks	Key Opportunities
Greenfield	Little or no formal EA; often in high‑growth scale‑ups or post‑merger “blank sheet” contexts	Over‑engineering, creating bureaucracy before trust; misalignment with existing delivery rhythms	Design lean, outcome‑driven EA from day one; bake governance into ways of working rather than adding layers later
Brownfield	Existing EA or architecture-like function; documents, standards, and boards exist but have low credibility	Legacy artefacts no one uses, “ivory tower” perception, misaligned with agile and product teams	Rationalise, simplify, and re‑position EA around decisions and value; re‑use what still works, retire what does not
Hybrid	Multiple partial EA functions across regions/BUs; some standards, some federated architects	Fragmented views, inconsistent decisions, duplicated effort, competing power centres	Create a light, central spine with federated engagement; align principles and guardrails while keeping local autonomy

The starting point influences change management and expectations, but the method is deliberately similar across all three. The first job is not to design an ideal future EA function; it is to understand the current state of the organisation and its decision‑making.

My recommendation for a starting point in each of these models:

• Greenfield: focus on relationships and one or two flagship wins.

• Brownfield: start with a reset of purpose and a clean-up of existing artefacts.

• Hybrid: start with principles and a federated engagement model.

  
  

2. Phase I: Assess the Current State – The Discovery Groundwork

Enterprise Architecture always starts by understanding the current state, context and background. This is the Discovery Phase, which is critical in laying the groundwork for the EA practice.

A. The Organisational Context

First, establish how the organisation currently operates: the processes, governance bodies, and executive formalities.

• Map how the organisation is structured globally, regionally, and by business unit or division.

• Identify where decisions are really made: corporate HQ, regional leadership, BU boards, product councils, or major programmes.

• Note which functions are centralised (e.g. infrastructure, security, finance) versus federated (e.g. product, digital, local operations).

  
  

This organisational map will determine where EA needs to plug in and at what level: portfolio, Business Unit, product line, or programme.

B. Map the technology landscape at a usable level

A first pass does not need to be exhaustive. Aim for:

1. Top‑50 strategic applications and platforms

2. Major integration patterns and data platforms

3. Critical infrastructure or cloud providers

4. Key security, identity, and observability services.

At this stage, you are not building the perfect repository; you are creating just enough shared truth to support governance and roadmapping.

C. Surface existing governance – business and technology

Before defining any “EA governance”, catalogue what already exists:

• Business governance: investment committees, steering groups, product councils, transformation boards.

• Technology governance: project approval forums, change advisory boards, security review boards, architecture review boards (even if informal), cloud review, data protection, etc.

• Operational governance: incident/problem review, service reviews, release management, reliability/SRE forums.

  
  

The aim is not to create more governance but to integrate architecture into existing forums, and selectively replace inefficient ones over time.

D. Audit and Report the Current State

• Review the documents, meetings, processes, and systems: Search for the hidden costs, "shadow IT," the redundant steering committees, and the communication gaps between the executive floor and business and technology teams.

• Report on Feedback and Recommendations: Consolidate your findings into a data-driven executive summary. This report must quantify the financial leakage and risk exposure of the current state. This is your primary tool for securing the funding and mandate for the EA uplift.

  
  

Some examples of findings from a Current State Discovery exercise to help identify quick wins:

• “Four different CRM platforms in one region”

• “Critical apps on unsupported OS versions”

• “Portfolio board approves projects with no reference to target architecture”

3. Phase II: Define the Future Vision – What is the Enterprise Architecture capability

With the pain points quantified, the next step is to define the achievable target state that directly addresses the documented gaps. Often the EA capability is defined in unison with the CIO’s IT Strategy, with EA forming a core pillar of that strategy.

A. Setting the North Star

• Set the Vision and Strategy: The EA Vision must articulate how the function will enable the business strategy. It must move beyond simply supporting IT and focus on enabling speed, resilience, and security.

• Example vision statements:

“No major investment without architectural review.”

“All critical platforms have a published, funded roadmap.”

“No new technical debt without a conscious decision and remediation plan.”

• Establish a maturity standard and baseline: To measure the maturity of the EA function and broader IT capabilities, a maturity standard provides a means to record, benchmark and set a target for the capability maturity.

• Defining the EA Capability Charter: What Products and Services does EA provide e.g. architecture guardrails and standards; solution optioning and trade‑off analysis; portfolio and platform roadmaps; technology and data risk advisory; M&A and major change impact assessments.

• Target Governance and Operating Models: Define how the EA team will function. Establish the roles (Enterprise, Domain, Solution Architects) and the interaction model (centralised vs. federated) that best support your organisational velocity. Also, how EA roles interact with product owners, platform owners, and the PMO in practice.

• Target Architecture: Define the high-level desired state across Business, Data, Application, and Technology domains. This is the architectural ideal we are building towards.

• Define and Deliver Foundations: Principles, Standards, reference models and frameworks provide immediate value alongside documentation of the landscape from the Discovery and Target state.

  
  

B. The Path: Gap Analysis and Roadmaps

• Gap Analysis: Quantify the gap between the Current State and the Target Architecture in terms of capability, risk, and cost.

• Roadmaps: Create pragmatic, multi-year Roadmaps sequenced by business value and risk reduction.

• Interim Architecture: Crucially, define the necessary Interim Architecture states. The transition won't be instant; these milestones ensure incremental value delivery and risk management along the journey.

  
  

4. Phase III: Establishing the EA Governance Mandate

Governance is the mechanism that translates strategy into executable, controlled decisions. The next step is to define how EA will work, day‑to‑day: when it is involved, what it owns, and how it interacts with other governance bodies.

A. Operationalising Decisions

• Governance Model Uplift Strategy: Define the charter, decision rights, and roles for the new Architecture Review Board (ARB). Prepare to communicate this across stakeholders.

• Programme Governance Strategy: Ensure tight integration with the PMO. All new programs must be validated against the Target Architecture before receiving material funding.

• Operational Governance: This manages architectural debt and the exceptions process on a day-to-day basis.

  
  

B. The Critical Control Points

Two components are essential for enforcing architectural standards and driving value:

1. The "Front Door": This is the mandatory single point of entry for any significant technology initiative. It ensures early engagement, architecturally sound design, and alignment with the roadmap. We stop architectural rework by intervening in misalignment early.

2. Security Governance: This must be tightly integrated. Security, compliance, and regulatory adherence (like GDPR, DORA, or NIS2) must be baked into the architecture at the design stage.

   
   

5. Phase IV: Tooling, Buy-In, and Arch2Ops

The success of an Enterprise Architecture is measured by the value it delivers. The EA capability is judged by repeated delivery of its value. In other words, Enterprise Architecture needs to be commoditised, repeatable and consistent – we need to Enterprise Architect the Enterprise Architecture capability!

We need to move the Enterprise Architecture capability from architecture to operations!

A. Tooling for Insight

Your EA capability must be a live asset, not a one-off report. As such, suitable tooling should be in place:

Tooling Category	Function and Architectural Mandate
Repository/CMDB	The “single source of truth” for all business capabilities, applications, and their dependencies.
APM Tooling	Essential for dynamic visualisation and institutionalising the process (e.g. ServiceNow, LeanIX, Ardoq, Orbus, Colloquial or the Excel/PowerBI option – check the Gartner Magic Quadrants, for reference)
Roadmapping/ Portfolio Mgmt	Links investment decisions and TCO directly to business value and risk scores

B. Stakeholder Management: The Political Capital

Building the function is inherently political, requiring continuous stakeholder management:

• Communicate Value, Not Technology: Frame EA success as faster time-to-market and TCO reduction, not technical purity.

• Start small: a light touch involvement, analysis and feedback to gain buy-in for a more structured and mature method for EA. Early, quick wins build the essential political capital required to enforce the governance later.

  
  

C. Architecture to Operations (Arch2Ops)

The true measure of maturity is the EA function's influence on the day-to-day. The transition from Architecture to Operations is non-negotiable.

• EA principles must govern BAU (Business As Usual). This includes managing exceptions and technical debt.

• The EA function must be the body that mandates the Retire/Rationalise strategy, ensuring that projects are funded to safely decommission systems, not just leave them running as "zombies".

• The level of effort and resource required to maintain the EA capability, depending on the maturity and complexity of the EA practice and programme journeys, may vary considerably.

  
  

Conclusion: Stop Documenting. Start Deciding.

Whether the assignment is Greenfield or Brownfield, the mandate is the same: establish, maintain, run and optimise a strategic governance body.

When built correctly and guided by a rigorous, fact-based approach (such as the Application-Data-Technology model), the EA capability enables Enterprise Architects to shift from a defensive, firefighting role to an offensive role, proactively driving and tracking measurable savings.

By establishing a robust, governed EA capability, you secure the financial and political foundation needed for long-term, complex digital transformation.

Stop documenting. Start deciding. The enterprise is waiting to be streamlined, from Architecture to Operations.