Insight · EA program

Building an EA Center of Excellence: The 12-Month Roadmap

By Sparx Services · August 26, 2025

An EA Center of Excellence builds five things together: platform, governance, stakeholder relationships, architect skills, and an AI-augmented way of working. A team that builds only one or two of them looks like a CoE and cannot deliver like one.

This roadmap lays out what to build across the first twelve months: the sequence, the dependencies that constrain the order, and the early signs of failure. It is written for the lead architect or IT leader standing up a practice.

The goal has changed since most CoE playbooks were written. A CoE used to aim for a repository that was partly populated and partly current, because keeping a model complete by hand needed more architects than most organizations would fund. Now architects can state what the model should contain and AI can do the mechanics: building content, checking it against the rules, drawing the views and keeping them current. The goal is a finished model that stays current, and a team with the skills to direct that work.

The five dimensions of an effective EA CoE

Many CoE programs stall because they treat the build as a single thread, usually tool configuration or framework training. The five dimensions below mature together, as parallel workstreams that depend on each other.

Dimension 1: Platform

The platform is Sparx EA, configured, governed and available to the architects who need it. That means MDG Technology profiles configured for the frameworks in use, a package structure aligned to the CoE’s scope, access controls that match the team, and connections to the systems the organization already runs on, such as its PPM, ITSM, eGRC and ITFM systems. A platform that is installed but poorly configured is worse than none, because it generates inconsistent data and trains architects in bad habits.

Dimension 2: Governance

Governance is the set of rules and processes that make the EA repository a reliable source of truth: naming conventions, MDG enforcement of element types and tagged values, a model review process, change management for the repository itself, and a measurable data-quality standard. With AI doing much of the building, governance matters more. AI applies the rules it is given consistently and quickly, so written rules become what AI builds and checks against. Automation checks completeness, people own correctness.

Dimension 3: Stakeholder relationships

EA produces value when its outputs change decisions, and that requires relationships with the CIO, business-unit leaders, delivery teams and IT governance. Building them takes longer than building the repository, because it depends on delivering useful answers consistently. This is where many CoEs fail quietly: the repository grows, the frameworks check out, and the business still does not use any of it to decide anything. Designing what each stakeholder sees, where they land in the model and how they drill down, is part of this dimension.

Dimension 4: Architect skills

The team’s depth sets the ceiling on everything the CoE produces: ArchiMate fluency, TOGAF literacy, Sparx EA proficiency, stakeholder communication, and the judgment to know which framework fits which problem. In an AI-augmented practice the skills that matter most are stating intent clearly, reviewing AI output against the notation and the organization’s rules, and designing the stakeholder experience. AI is only as good as the person prompting it.

Dimension 5: AI-augmented way of working

This runs through the whole roadmap. From the first domain, architects decide what should be modeled and AI does the mechanics in the tool and the model. Once the model is complete, AI also keeps it current by bringing in data from the PPM, ITSM, eGRC and ITFM systems, and lets stakeholders ask questions of it. On a poorly governed repository, AI produces misleading output quickly, which damages trust faster than any other failure. On a governed one, it lets a small team keep a finished model. (For the approach in full, see AI-Augmented Architecture.)

The 12-month roadmap

The dimensions develop in parallel, but they come online in a sequence. Platform and governance work is front-loaded because everything else depends on it.

The 12-month roadmap
Period	Phase	Key activities
Month 1-3	Foundation	Platform configuration, MDG profiles, package structure, written governance rules, architects trained to state intent and review AI output
Month 3-5	First value	First complete domain architecture (typically business architecture and application portfolio) built AI-augmented and reviewed, navigation for stakeholders, initial briefings
Month 5-8	Stakeholder engagement	Regular architecture briefings, integration with delivery gate reviews, CIO reporting, data from PPM, ITSM, eGRC and ITFM systems brought into the model so it stays current
Month 8-12	Maturity and wider access	Cross-domain models, architecture-driven decisions tracked, skill gaps addressed, stakeholders asking questions of the model through Prolaborate, Power BI or Microsoft 365 Copilot

Month 1-3: Foundation

This is the phase organizations rush, and the rush is the most common early failure. Months 1 to 3 are where the platform is configured, MDG profiles are set up for the frameworks in use, the package structure is designed around the CoE’s scope, and the governance rules are written down and agreed. It is also where the first training happens: how we use Sparx EA here, with these profiles and these conventions, and how architects state a request to AI and check the result. Deliverables produced before governance is in place will need rework, so shipping diagrams in week two costs more than it saves.

Month 3-5: First value

With the foundation in place, the team builds its first complete domain architecture, typically business architecture (a capability map, process inventory, stakeholder register) and the application portfolio. Today a team builds these by hand over many months and the portfolio is out of date before it is finished. Working AI-augmented, architects state what each domain should contain and the sources to use, AI builds it and the navigation diagrams, and architects review it. These are the outputs CIOs and business leaders ask for most often, so delivering them complete is what establishes the CoE’s credibility.

Month 5-8: Stakeholder engagement

Architecture that never reaches decision-makers never influences decisions. This is where engagement gets built into the operating model: regular briefings, integration with project gate reviews, and a reporting cycle tied to the CIO’s agenda. It is also where the model stops relying on values typed in by hand. AI connects to the PPM, ITSM, eGRC and ITFM systems, the model stitches that data to the architecture, and dashboards in Prolaborate or Power BI show the relationships. Start capturing the metric that matters too: which decisions EA influenced, what the input was and what the outcome was. That record becomes the CoE’s business case in year two.

Month 8-12: Maturity and wider access

By now the CoE should hold a multi-domain architecture, an active governance process, regular stakeholder engagement and a skills assessment that names where the team needs to grow. This phase connects repository structure to formal ADM phase deliverables for the programs that require it, and widens access. Stakeholders can ask questions of a finished, current model and get answers from the repository, through Prolaborate, Power BI or Microsoft 365 Copilot. If MDG quality is not there yet, wider access waits while governance catches up, because poor answers damage trust in the EA function and the tooling.

Architecture-driven decisions is the metric that connects EA activity to organizational value.

Count the significant IT or business decisions in the period that had explicit architecture input which changed or confirmed the outcome. Repository population, framework-compliance scores and diagram counts are activity metrics. They say nothing about whether architecture influenced anything that mattered. Build the process to capture the outcome metric from month 8 onward.

Four common failure modes

CoEs that fail usually do so in one of four recognizable ways.

Tool-first failure. The organization buys Sparx EA, or adds an AI tool, and expects the tool to create a practice. Practices come from configuration, governance and architect skills. The tools support them.

Framework-compliance failure. The CoE becomes a TOGAF certification exercise. The repository fills with compliant deliverables nobody outside the EA team reads, stakeholders disengage because the output is in framework language, and the practice is eventually defunded as theoretical.

Skills-gap failure. The architects lack the modeling depth to produce, or review, good content. ArchiMate layer confusion, inconsistent notation and shallow models accumulate, faster when AI is building unchecked, and by the time the gap is recognized the repository needs significant remediation.

Sponsorship failure. The sponsor who backed the CoE moves on, is replaced or loses budget authority. Without executive sponsorship the CoE cannot get into the decision processes, so it keeps operating with no organizational impact.

Frequently asked questions

What is an EA Center of Excellence?

An organizational structure, usually a team, responsible for building and maintaining enterprise architecture capability: the tooling, repository governance, architect development, stakeholder engagement and the methods in use. An effective one keeps an architecture model that is finished and current, and uses it to influence decisions.

How long does it take to build an effective EA CoE?

The roadmap in this article spans about a year: platform, governance and first content first, then stakeholder engagement, then maturity and wider access to the model. The pace depends on sponsorship, the team’s skills and how much existing content can be brought in. Working AI-augmented from the start shortens the modeling work; it does not shorten the time it takes to earn stakeholder trust.

What governance structure should a CoE have?

At minimum: an Architecture Review Board or equivalent with business and IT representation, a repository governance role (often the lead architect), defined architecture principles, a change process for the repository, and a model-quality standard that AI can check against. The ARB supplies the legitimacy for architecture-driven decisions.

What is the most common reason CoEs fail?

Sponsorship failure paired with a framework-compliance focus: technically correct deliverables decision-makers do not read, backed by an executive who eventually loses interest. Without engagement that connects outputs to decisions, the practice cannot show value or keep its budget.

How does AI change what a CoE can deliver?

It changes who does the mechanics. Architects state what the model should contain and AI builds it, checks it against the rules and keeps views current, so a small team can keep a finished model. Stakeholders can then ask questions of the model and get answers from the repository without scheduling a review. All of it depends on architects who state intent clearly and review what AI produces.

How we help

Our Paralysis to a Plan engagement assesses what is already in place across the five dimensions and produces the roadmap. Configure the Solution sets up the platform and governance. From there we can teach your architects to work AI-augmented on your own repository, or build the model for you and hand it over. See how we work with architecture leaders.

Build a CoE that keeps a finished, current model.

We can teach your architects to direct and review AI on your own repository and mentor them until it sticks, or assess where you stand and build the roadmap for you.

Book a call

Keep reading