⏱ 7 min read
Recommended Reading
Executive summary
Real architecture practice is about repeatable decisions and reusable patterns, not producing artifacts for their own sake. TOGAF includes governance practices like architecture compliance reviews and architecture boards; operationalizing these with decision records (ADR) and tool-backed evidence (baselines, audits, reviews) makes governance practical and measurable. TOGAF certified training
- Decision-centric governance (ADR + boards)
- Compliance-by-exception
- Tool-based evidence and publication
- Pitfalls and success metrics
- TOGAF standard overview.
- Compliance review.
- Architecture board.
- ADR practice.
- EA baselines and auditing.
Tailoring TOGAF: keep vs skip
TOGAF explicitly states organizations should tailor the ADM. Yet most either implement it literally (heavy, unused artifacts) or abandon it entirely (losing governance). The middle path — pragmatic tailoring — is where value lives. ArchiMate in TOGAF ADM
Keep: ADM Phases A–D. Vision, Business, IS, and Technology architecture form the analytical core. Run them in compressed cycles (1–2 weeks) aligned to your governance cadence.
Keep: Phase G. Implementation governance is where architecture becomes authoritative rather than advisory. Without Phase G, architecture is a suggestion.
Simplify: Phase E–F. Replace heavy transition documents with ArchiMate Migration views — plateaus, gaps, work packages. One view replaces a 50-page document.
Skip: Full artifact catalog. TOGAF defines dozens of artifacts. Most organizations need 5–8: Architecture Vision, Capability Assessment, Target Views, Gap Analysis, Migration Roadmap, Contracts, Compliance Reviews, Decision Records.
Skip: Requirements Management as separate phase. In agile organizations, requirements flow through the backlog as enabler stories, not a separate architecture process.
The 90-day test
Apply this to every TOGAF artifact: "Will this improve a decision within 90 days?" If not, defer it. EA programs that cannot demonstrate value in three months lose stakeholder support — no framework can fix that.
The maturity journey: from framework to practice
Transitioning from TOGAF-as-framework to TOGAF-as-practice follows a maturity journey. Most organizations stall at Level 1 or 2 — they have the framework but not the discipline. Understanding the maturity levels helps set realistic expectations and plan the next step.
Level 0: No EA. Architecture decisions are made project-by-project with no enterprise view. Duplication is rampant. Technology choices are inconsistent. Nobody can answer "what applications support this business capability?"
Level 1: Ad-hoc. An EA team exists and has adopted TOGAF, but architecture work is reactive. The team responds to requests rather than driving strategic direction. The repository is incomplete, governance is advisory, and stakeholders view EA as overhead.
Level 2: Repeatable. Architecture reviews happen consistently for major projects. The repository contains enough content to support impact analysis. Standards exist and are occasionally enforced. But the ADM is followed rigidly rather than tailored, producing heavy documents that few people read.
Level 3: Defined. The ADM is tailored to the organization's cadence. Architecture deliverables are model-based (not document-based). Governance is lightweight and fast. Architects are embedded in delivery teams. The repository is the authoritative source for architecture information.
Level 4: Managed. Architecture value is measured (cost avoidance, risk reduction, decision acceleration). Governance is partially automated (compliance scripts, quality dashboards). The EA function has a defined operating model with clear roles, responsibilities, and KPIs.
Level 5: Optimizing. Architecture is integrated into the organization's decision-making fabric. The EA function continuously improves its own practices based on measured outcomes. Architecture insights proactively inform strategy rather than reactively supporting delivery.
Five practical steps to move from Level 1 to Level 3
Step 1: Pick one high-value deliverable. Do not try to produce all TOGAF artifacts. Choose the single deliverable that would most help your organization right now — typically a capability map, a portfolio rationalization view, or an integration landscape. Produce it well, demonstrate its value, and build from there.
Step 2: Embed one architect in one product team. Stop producing architecture in isolation. Place one architect in a product team for 50% of their time. Their job: help the team make better technical decisions faster. This demonstrates EA value at the team level and builds demand for architecture involvement.
Step 3: Replace documents with models. Convert one heavyweight architecture document into a set of ArchiMate views in the repository. Demonstrate that a 3-view model answers the same questions as a 50-page document — and stays current because it is maintained as part of the architecture workflow, not as a separate documentation effort.
Step 4: Automate one governance check. Pick the most common architecture review finding (naming violations, missing documentation, non-standard technology) and automate it. A script that catches 80% of violations frees the review board to focus on genuine architectural decisions.
Step 5: Measure and report one outcome. Track a single metric that business leaders care about: "Architecture analysis prevented $X in duplicate technology spending" or "Impact analysis reduced change assessment from 3 weeks to 2 days." Report it quarterly. One credible number builds more support than a dozen aspirational claims.
Common objections and how to overcome them
Every EA team attempting the framework-to-practice transition encounters the same objections from stakeholders and leadership. Having answers ready accelerates the transition.
"We invested in TOGAF certification — why are we skipping phases?" Tailoring is not skipping — it is what TOGAF recommends. The ADM is designed to be adapted. Certification teaches the full framework so architects understand the complete toolkit. Practice means selecting the right tools for the current job. A carpenter who owns every tool does not use all of them on every project.
"How do we justify the EA team if we produce fewer documents?" EA value is measured by decision quality, not document quantity. Track the decisions EA influenced and their business outcomes: cost avoided, risk mitigated, delivery accelerated. A 2-page ArchiMate view that prevents a $500K duplicate technology purchase is infinitely more valuable than a 100-page architecture description that nobody reads.
"Our auditors require TOGAF documentation." Auditors require evidence of governed architecture decisions, not specific TOGAF artifacts. ArchiMate views in the repository, architecture decision records, baseline comparisons, and compliance reports satisfy audit requirements more effectively than static documents. Work with your audit team to define evidence requirements — most auditors prefer queryable, traceable models over PDFs.
"The ADM provides a structured approach — without it we will have chaos." The tailored approach retains the ADM's structure (phases, governance, deliverables) while compressing it into practical timescales. The risk of chaos comes from having no process. The risk of irrelevance comes from having a process that takes 6 months to produce its first output. Tailoring mitigates both risks.
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.