TOGAF provides the architecture process framework; Sparx EA provides the tool. Neither is sufficient alone. Organizations that implement TOGAF in Sparx EA without tailoring it to their context get process overhead without value: ADM phases that produce documents nobody reads and compliance checklists that nobody enforces. Organizations that use Sparx EA without any process structure get a filled repository without organizational impact: well-drawn diagrams that don’t connect to decisions. The combination: TOGAF governance, ArchiMate notation, Sparx EA as the platform: is the industry standard for a reason. Executing it well requires treating TOGAF as a governance framework, not a documentation framework.
Key Takeaways
The Architecture Development Method (ADM) is TOGAF’s iterative process for developing and managing enterprise architecture. Each phase has a defined purpose and produces defined outputs. In a Sparx EA implementation, those outputs have specific forms: and the quality of those artifacts, not the completion of the phase, is where practice value is created or lost.
| Phase | Purpose | Primary Sparx EA Artifacts |
|---|---|---|
| Preliminary | Framework customization and architecture principles | Principles catalog; Architecture Repository package structure; MDG Technology profile configuration |
| A: Architecture Vision | Scope, stakeholders, and high-level requirements | Stakeholder register; Architecture Vision document; Requirements in the Motivation layer (goals, drivers, constraints) |
| B: Business Architecture | Current and target business layer architecture | Business process and function models (ArchiMate Business layer or BPMN); Capability map; Organizational actor models |
| C: Information Systems Architecture | Application and data architecture | Application portfolio (ArchiMate Application layer); Data architecture models; Application interaction diagrams |
| D: Technology Architecture | Infrastructure and platform architecture | Technology layer models (ArchiMate Technology); Infrastructure diagrams; Technology standards inventory |
| E: Opportunities and Solutions | Work packages and transition planning | Gap analysis; Architecture Building Blocks; Solution Building Blocks; work package definitions |
| F: Migration Planning | Prioritized, sequenced roadmap | Architecture Roadmap (ArchiMate Implementation layer); Project dependency diagrams; transition architecture states |
| G: Implementation Governance | Architecture compliance during delivery | Compliance review checklists; architecture decision records; Implementation Governance Model |
| H: Architecture Change Management | Triggers and management of architecture change | Change requests; impact assessments; Architecture Contract updates |
| Requirements Management | Cross-phase requirements traceability | Requirements repository in Sparx EA; traceability matrices; requirements-to-architecture element links |
The Preliminary phase is the most commonly underinvested. It is where the MDG Technology profile is configured, the Architecture Repository structure is established, and the Architecture Principles are defined. Practices that skip or rush the Preliminary phase are building on an unstable foundation: and the structural debt shows up in every subsequent phase.
TOGAF defines the Architecture Repository as the mechanism for storing and managing all architecture assets. In Sparx EA, the Architecture Repository is implemented as a package hierarchy that reflects these TOGAF concepts:
Architecture Metamodel: the MDG Technology definitions that govern element types, relationship constraints, and tagged value schemas. This is the machine-readable equivalent of your architecture language definition. In AI-enabled practices, this is the structure through which EA GraphLink exposes repository data.
Architecture Landscape: models organized by scope: Strategic Architecture (enterprise-wide, long-horizon), Segment Architecture (domain or business-unit-level), and Capability Architecture (specific capability domains). Most practices need all three levels, with clear relationships between them.
Architecture Capability: principles, standards, governance processes, and the Architecture Board charter. This is where the practice’s rules live: what element types are mandatory, what review gates exist, what compliance means.
Reference Library: architecture patterns, reference models, and templates that architects draw from when developing new architecture work. In Sparx EA, this includes MDG profile templates, standard view templates, and reference architecture diagrams.
Governance Log: decision records, compliance reviews, dispensations, and Architecture Contracts. Practices that maintain a Governance Log in Sparx EA have a queryable record of architecture decisions linked to the elements those decisions concern.
The package structure matters because it determines what can be searched, reported on, and queried: by architects, by stakeholders, and by AI tools. A flat or ad hoc package structure makes Sparx EA a drawing tool. A structured package hierarchy makes it an architecture management system.
TOGAF and ArchiMate are designed to work together, and the industry standard TOGAF implementation uses ArchiMate as its notation language. The relationship is simple: TOGAF defines what to produce; ArchiMate defines how to express it.
Sparx EA supports both TOGAF and ArchiMate natively. The TOGAF MDG profile provides the process artifacts (Architecture Vision documents, ADM work products), and the ArchiMate MDG profile provides the notation. They coexist in the same repository, with TOGAF process artifacts linking to ArchiMate models as their outputs.
The integration is not automatic: it requires deliberate package structure and cross-reference discipline. The Amplify service develops this integration as part of practice capability work. The Discover assessment evaluates whether your current implementation connects TOGAF process artifacts to ArchiMate models or treats them as separate tracks.
The most common TOGAF implementation failure is structural, not technical: organizations use TOGAF as a documentation checklist rather than as a governance framework.
The checklist pattern looks like this: an ADM cycle is initiated, each phase produces its mandated work product, the Architecture Definition Document is completed, and the architecture is delivered to implementation. No one refers to the Architecture Definition Document during implementation. The architecture decision record does not exist. The compliance review in Phase G is a box-checking exercise. When the project encounters a design decision that touches the architecture, no one queries the repository.
TOGAF creates value when it connects architecture decisions to business outcomes: when the principles defined in the Preliminary phase are enforced in Phase G compliance reviews, when the requirements captured in Requirements Management are traceable to the application components that implement them, when the gap analysis in Phase E is based on a current-state model that architects trust.
Sparx EA makes this connection possible. It does not make it automatic. The Discover engagement establishes whether your current TOGAF implementation is a governance framework or a documentation exercise: and where the specific gaps are between your stated TOGAF process and your actual architecture practice.
TOGAF-governed repositories are structurally better prepared for AI integration than ungoverned ones: for the same reason that any well-structured system is easier to query than an ad hoc one.
When TOGAF’s Architecture Repository structure is reflected in Sparx EA’s package hierarchy, when the Architecture Metamodel is implemented as a governed MDG Technology profile, and when artifacts follow defined templates with populated metadata, the repository has the properties that EA GraphLink needs to expose useful data to AI systems.
Specifically: TOGAF’s emphasis on artifact standards, principles documentation, and governance logs creates repository content that is high-value for AI queries. “Which architecture principle applies to this application component?” is a query that Kernaro AI Hub can answer when principles are documented as Sparx EA elements and linked to the components they constrain. Without that link: which requires a TOGAF-informed repository structure: the query has no data to resolve against.
The MDG Technology definition is, in effect, the machine-readable version of TOGAF’s Architecture Metamodel. An organization that has invested in a governed MDG profile has already done the foundational work that AI integration builds on. An organization that has not faces that investment before AI integration can proceed: which is precisely what the Discover assessment surfaces.
What is TOGAF and do I need it if I’m using Sparx EA?
TOGAF (The Open Group Architecture Framework) is a framework for developing and managing enterprise architecture. It provides the Architecture Development Method (ADM): a structured process for producing architecture work: along with concepts for the Architecture Repository, Architecture Governance, and Architecture Capability. You do not need TOGAF to use Sparx EA. However, Sparx EA without any process framework produces a repository that accumulates content without organizational governance. TOGAF provides that governance structure. The question is whether you use TOGAF, another governance framework, or something custom: not whether you need structure.
Is TOGAF still relevant in 2025/2026?
Yes. TOGAF remains the most widely adopted enterprise architecture framework globally. TOGAF 10, released in 2022, modernized the content: making the ADM more modular and adding guidance for digital and agile contexts. The most common critique: that TOGAF is heavyweight and slow: reflects poor implementation more than the framework itself. TOGAF is designed to be tailored; organizations that apply every ADM phase in full to every initiative are misapplying the framework. A well-tailored TOGAF implementation is a governance backbone, not a methodology overhead.
What is the TOGAF ADM and how does it work?
The Architecture Development Method is TOGAF’s iterative process for developing architecture. It has nine phases: Preliminary, A through H: plus Requirements Management, which runs continuously across all phases. The ADM is designed to be iterated: organizations cycle through the phases for each significant architecture initiative, building on previous cycles rather than starting from scratch. The phases move from architecture vision and business architecture through information systems and technology, into transition planning, governance, and change management. Each phase has defined inputs, outputs, and steps: which in Sparx EA correspond to specific artifact types.
What is the difference between TOGAF and ArchiMate?
TOGAF is a process and governance framework: it defines what an architecture practice does and how it governs that work. ArchiMate is a notation standard: it defines the visual language for expressing architecture models. TOGAF tells you to produce a Business Architecture in ADM Phase B; ArchiMate tells you how to draw it using Business Processes, Functions, Actors, and Roles. They are complementary: TOGAF without ArchiMate produces process structure without notation consistency; ArchiMate without TOGAF produces notation without governance. The industry-standard combination is both, implemented in Sparx EA.
How do I structure my Sparx EA repository for TOGAF compliance?
The package structure should reflect TOGAF’s Architecture Repository concepts: a top-level Architecture Metamodel package (containing MDG profile documentation), an Architecture Landscape package (with sub-packages for Strategic, Segment, and Capability levels), an Architecture Capability package (principles, standards, governance artifacts), a Reference Library package (templates and patterns), and a Governance Log package (decision records and compliance reviews). Within the Architecture Landscape, organize packages by architecture domain (Business, Application, Technology) and state (Current, Transition, Target). This structure is not a TOGAF mandate: it is a Sparx EA implementation pattern that reflects TOGAF concepts in a queryable repository hierarchy.
Do I need TOGAF certification to implement TOGAF in my practice?
No. TOGAF certification: Foundation (Level 1) and Architect (Level 2): validates knowledge of the framework. It does not validate implementation capability. Many certified architects implement TOGAF poorly; many uncertified architects implement it well. Certification is useful for establishing a common vocabulary and showing credential to stakeholders. It is not a prerequisite for building a governed EA practice. What matters is whether the people leading the implementation understand how to tailor TOGAF to organizational context: which is a consulting and practice development skill, not a certification outcome.
What are Architecture Building Blocks vs Solution Building Blocks in TOGAF?
Architecture Building Blocks (ABBs) are architecture-level components defined to meet business and architecture requirements: they are vendor-neutral and defined in terms of capability. Solution Building Blocks (SBBs) are specific, implementable representations of ABBs: a specific product, technology, or component that realizes the architectural capability. The ABB defines what is needed; the SBB defines what will deliver it. In Sparx EA, ABBs are typically defined in the Technology Architecture phase (Phase D) and SBBs are mapped in the Opportunities and Solutions phase (Phase E). Maintaining the ABB-to-SBB mapping in the repository enables technology rationalization queries: “which SBBs implement this architectural capability?”
How does TOGAF relate to government EA frameworks?
TOGAF is the foundation for many government EA frameworks. The US Federal Enterprise Architecture Framework (FEAF) references TOGAF. Australia’s Whole of Government Architecture framework aligns to TOGAF principles. DoDAF (Department of Defense Architecture Framework) has different viewpoint requirements but is commonly implemented alongside TOGAF governance concepts in Sparx EA. For defense and government organizations, the practical question is usually how to implement TOGAF governance alongside the mandated viewpoint framework (DoDAF, MODAF, NAF): which is a layering problem that Sparx EA supports well.
What is the most important TOGAF artifact to get right first?
Architecture Principles, defined in the Preliminary phase. Principles are the standing decisions that govern all subsequent architecture work: they constrain the solution space, define what compliance means, and give Phase G (Implementation Governance) its enforcement criteria. An architecture practice without documented, agreed, and enforced principles has no consistent basis for architecture decisions. Every subsequent ADM deliverable is easier to produce and more useful to stakeholders when principles are clear. In Sparx EA, principles should be defined as Principle elements in the Motivation layer, linked to the architecture domains they govern.
How does TOGAF governance connect to Kernaro AI Hub queries?
TOGAF-governed repositories have two AI-readiness advantages. First, the Architecture Repository structure creates a package hierarchy that EA GraphLink can map to structured data categories: making it possible to scope queries by architecture domain, state, or governance status. Second, TOGAF artifacts: principles, compliance records, decision logs: are high-value content for architecture intelligence queries. “Which architecture principle constrains this technology choice?” or “What decisions have been made about the integration platform?” are queries that Kernaro AI Hub can resolve when TOGAF artifacts are maintained as Sparx EA elements with relationships to the architectural components they concern. Ungoverned repositories cannot answer these questions because the data does not exist in structured form.
Discover ($25K–$75K): A practice maturity assessment that evaluates whether your TOGAF implementation is functioning as a governance framework or a documentation exercise. Includes MDG readiness evaluation, Architecture Repository structure review, and a gap analysis with prioritized recommendations.
Architect Development: For EA teams that need to develop TOGAF implementation capability: ADM tailoring, ArchiMate integration patterns, governance model design, and architect enablement.
See also: ArchiMate 3.0 in Sparx EA: the notation standard that pairs with TOGAF in the industry-standard EA stack.
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.