⏱ 6 min read
Recommended Reading
Executive summary
An EA operating model defines how architecture governance works in practice: what services the EA function provides, how decisions are made, and how compliance is verified. TOGAF provides governance primitives for this operating model: architecture boards for strategic architecture maintenance, compliance review processes, and architecture contracts that formalize expectations between sponsors and delivery partners. TOGAF certified training
Operationalizing this in tooling (e.g., EA) enables evidence continuity via baselines, audits, and review records, which is especially important in regulated or high-risk contexts.
- Service catalogue: standards, reviews, enablement, portfolio insights
- Roles: board, domain architects, EA librarians
- Workflow: intake → review → approval → publication
- Metrics: decision cycle time, rework reduction
- Pitfalls and key takeaways
- Architecture Board definition.
- Compliance review process.
- Architecture contracts definition.
- Architecture governance framework deck (Open Group).
- EA baselines.
- EA auditing.
- EA model reviews.
The four layers of an EA operating model
An EA operating model defines how the architecture function itself operates. Without it, EA drifts into ivory tower (producing architecture nobody uses) or help desk (reacting without strategic direction).
Strategy layer: Define the EA mission (specific, measurable: "Reduce architecture change risk by 50%"), value proposition ("Why should leaders invest in EA?"), and alignment with business strategy.
Delivery model: Embedded architects (50% in product teams), central platform team (20% maintaining repository and standards), strategic initiatives (30% on target architecture and roadmaps).
Governance: Lightweight review board meeting bi-weekly. Automated compliance for routine checks. Clear dispensation process. Target: 95% of reviews completed within 5 business days.
Enablement: Sparx EA or Archi with shared DBMS repository. Training program (ArchiMate certification + tool skills). Knowledge base with patterns, decisions, and reference architectures published via WebEA.
Measuring the operating model
Track: architecture team utilization (embedded vs central), stakeholder satisfaction (quarterly survey), decision turnaround time, and model adoption rate. Report monthly to the CIO — the EA operating model is itself subject to continuous improvement.
Architect time allocation: the 50/20/20/10 model
The single most common failure in EA operating models is misallocating architect time. Teams that spend 80% of their time producing centralized documents and 20% interacting with delivery teams have the ratio backwards. The 50/20/20/10 model corrects this.
50% embedded in product/project teams. Architects are physically (or virtually) present in delivery teams. They participate in sprint planning, review technical designs, and produce architecture content that directly supports delivery decisions. This is where EA builds credibility — by helping teams make better decisions faster, not by producing documents nobody asked for.
20% central platform work. Maintaining the architecture repository, updating standards, managing the modeling tool, and handling cross-cutting architecture concerns (security patterns, integration standards, technology radar). This work keeps the EA infrastructure functional but should not dominate architect time.
20% strategic initiatives. Developing target architecture, building capability roadmaps, conducting technology evaluations, and supporting M&A due diligence. This is the forward-looking work that justifies EA's existence at the strategic level. It should be time-boxed and outcome-driven: "Deliver the target application portfolio by Q3" rather than "Work on strategic architecture."
10% governance and administration. Architecture review board preparation, training new architects, maintaining the knowledge base, and reporting to leadership. This should be minimized through automation — automated compliance checks reduce review preparation, and self-service training materials reduce ad-hoc mentoring.
Staffing the operating model
The right staffing level depends on the organization's size and architecture maturity. A rough guideline: one architect per 50-100 developers in a mature organization, one per 30-50 developers in an organization undergoing major transformation. For a 500-developer organization, this means 5-10 enterprise architects. Sparx EA guide
Organize architects by specialty rather than by organizational unit: one or two focus on business architecture (capability maps, value streams, operating models), two or three on application architecture (portfolio management, integration patterns, microservice design), one or two on technology architecture (infrastructure, cloud, security), and one on data architecture (data platform, governance, lineage). This ensures coverage across all TOGAF domains while allowing architects to develop deep expertise. ArchiMate in TOGAF ADM
Measuring the operating model's effectiveness
Track four metrics quarterly. Stakeholder satisfaction: survey business and IT leaders on EA's perceived value (target: 4.0/5.0 or above). Decision turnaround: average time from architecture review request to decision (target: under 5 business days). Repository adoption: percentage of active projects with up-to-date architecture models (target: above 80%). Value delivered: documented cost avoidance, risk reduction, or speed improvement attributed to EA analysis (target: at least 3x the EA team's fully loaded cost).
Starting the operating model from scratch
Organizations without an EA operating model should not try to build the complete model on day one. Start with the minimum viable operating model and expand based on demonstrated value.
Month 1-2: Foundation. Hire or assign 2-3 architects. Deploy the modeling tool (Sparx EA or Archi) with a shared repository. Produce one high-value deliverable: a capability map or application portfolio view. Embed one architect in the highest-priority product team. Establish a monthly governance cadence (informal at first).
Month 3-6: Expansion. Expand the repository with traceability from capabilities to applications. Conduct the first portfolio rationalization analysis. Formalize the governance process: architecture review board meeting bi-weekly with clear scope (what needs review, what does not). Produce the first ROI report based on rationalization findings.
Month 7-12: Maturation. Implement automated compliance checks. Expand architect coverage to additional product teams. Build the knowledge base (decision records, patterns, standards). Measure and report operating model effectiveness quarterly. Adjust time allocation based on where architects are generating the most value.
The operating model is itself an architecture artifact — model it in the repository, measure its effectiveness, and iterate. EA teams that treat their own operating model with the same rigor they apply to business architecture build lasting credibility with leadership.
If you'd like hands-on training tailored to your team (Sparx Enterprise Architect, ArchiMate, TOGAF, BPMN, SysML, Apache Kafka, or the Archi tool), you can reach us via our contact page.
Frequently Asked Questions
What is TOGAF used for?
TOGAF (The Open Group Architecture Framework) is used to structure and manage enterprise architecture programmes. It provides the Architecture Development Method (ADM) for creating architecture, a content framework for deliverables, and an enterprise continuum for reuse.
How does ArchiMate relate to TOGAF?
ArchiMate and TOGAF are complementary. TOGAF provides the process framework (ADM phases, governance, deliverables) while ArchiMate provides the notation for creating the architecture content. Many organisations use TOGAF as their EA method and ArchiMate as the modeling language within each ADM phase.
What is the TOGAF Architecture Development Method (ADM)?
The ADM is a step-by-step process for developing enterprise architecture. It consists of a Preliminary phase and phases A through H: Architecture Vision, Business Architecture, Information Systems Architecture, Technology Architecture, Opportunities and Solutions, Migration Planning, Implementation Governance, and Architecture Change Management.