Study guide
11.2 Change Classification: Simplification, Incremental, and Re-Architecting Changes
TOGAF Enterprise Architecture Practitioner OGEA-103
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Mechanics & Foundation Overview
1.1 OGEA-103 Exam Structure, Gradient Scoring & Open-Book Strategy 1.2 The TOGAF Standard 10th Edition Structure & Core Concepts 1.3 Enterprise Architecture in Practice: Context, Scope, and Architecture Domains 1.4 The Context for Enterprise Architecture: Purpose, Capability, Security, and the Digital Enterprise
2 Chapter 2: Preliminary Phase & Establishing the EA Capability
2.1 Preliminary Phase Objectives, Inputs, and Activities 2.2 Scope of the Enterprise and Defining the Architecture Footprint 2.3 Establishing Architecture Governance, Frameworks, and Tools
3 Chapter 3: Architecture Vision & Stakeholder Management (Phase A)
3.1 Phase A Objectives, Request for Architecture Work, and Scope Definition 3.2 Stakeholder Management: Identification, Classification, the Power/Interest Grid, and the Stakeholder Map 3.3 Business Scenarios Technique for Problem Definition and Requirements Elicitation 3.4 Architecture Vision, Communications Plan, and Statement of Architecture Work Approval
4 Chapter 4: Business Architecture (Phase B)
4.1 Phase B Objectives, Steps, and Business Modeling Approaches 4.2 Business Capabilities, Capability Mapping, and Assessment 4.3 Value Streams, Value Stream Mapping, and Capability Cross-Mapping 4.4 Business Architecture Artifacts, Gap Analysis, and Architecture Definition Document Updates
5 Chapter 5: Information Systems Architectures — Data Architecture (Phase C)
5.1 Phase C Data Architecture Objectives, Approach, and Data Principles 5.2 Conceptual, Logical, and Physical Data Models and Data Management 5.3 Data Entity/Business Function Matrix, Data Architecture Gap Analysis, and Interoperability Requirements
6 Chapter 6: Information Systems Architectures — Application Architecture (Phase C)
6.1 Phase C Application Architecture Objectives, Approach, and Baseline vs. Target First 6.2 Application Portfolio Rationalization, Component Modeling, and Application Integration 6.3 Application/Organization Matrix, Application Gap Analysis, and Boundary Definitions
7 Chapter 7: Technology Architecture (Phase D)
7.1 Phase D Objectives, Cloud & Modern Platforms, and Technology Principles 7.2 Technology Standards, the Standards Library, Platform Services, and Infrastructure Modeling 7.3 Technology Gap Analysis, Non-Functional Requirements, and Reference Models
8 Chapter 8: Opportunities and Solutions (Phase E)
8.1 Phase E Objectives, Consolidated Gap Analysis, and Work Package Formulation 8.2 Architecture Building Blocks (ABBs) to Solution Building Blocks (SBBs) Transition 8.3 Transition Architectures, Incremental Delivery, and Dependency Analysis 8.4 Architecture Roadmap Development and Trade-Off Analysis 8.5 Business Transformation Readiness Assessment and Risk Management
9 Chapter 9: Migration Planning (Phase F)
9.1 Phase F Objectives, Stakeholder Collaboration, and Governance Alignment 9.2 Business Value Assessment, Cost-Benefit Analysis, and Risk/Feasibility Scoring 9.3 Implementation and Migration Plan Deliverable, Resource Allocation, and Transition Roadmaps
10 Chapter 10: Implementation Governance (Phase G)
10.1 Phase G Objectives, Implementation Governance Structure, and Project Architecture Hand-off 10.2 Architecture Contracts: Purpose, Types, Timing, and Stakeholder Commitments 10.3 Architecture Compliance Reviews: Conformance Levels, Process, Timing, and Checklists
11 Chapter 11: Architecture Change Management (Phase H) & Requirements Management
11.1 Phase H Objectives, Drivers of Architecture Change, and Value Monitoring 11.2 Change Classification: Simplification, Incremental, and Re-Architecting Changes 11.3 Ongoing Governance, Retirement of Solutions, and Maintenance vs. New ADM Cycle 11.4 Requirements Management: Central Role, Traceability, Mid-Phase Discovery, and Scope Conflict
12 Chapter 12: Architecture Governance, Boards, and Dispensations
12.1 Architecture Governance Framework, Organizational Roles, and RACI Matrix 12.2 Architecture Board Structure, Federation, Responsibilities, and Meeting Operations 12.3 Compliance Assessment, Dispensation Process, Expiration, and Remediation Tracking 12.4 Architecture Principles, the Decision Log, and Resolving Principle Conflicts
13 Chapter 13: Architecture Content Framework & Architecture Repository
13.1 The TOGAF Content Framework and Enterprise Metamodel 13.2 Deliverables, Artifacts (Catalogs, Matrices, Diagrams), and Building Blocks (ABBs vs SBBs) 13.3 Architectural Views, Viewpoints, Stakeholder Concerns, and ISO/IEC/IEEE 42010 13.4 The Enterprise Continuum and the TOGAF 10 Architecture Repository
14 Chapter 14: EA Capability, Tailoring, and Iteration
14.1 Tailoring the ADM: Enterprise Context, Process Weight, and Agile Integration 14.2 ADM Iteration Cycles, Levels, and Classes of Architecture Engagement 14.3 Architecture Maturity Models, Capability Assessment, and EA Performance Measures 14.4 Supporting the ADM Work: The TOGAF Library, Series Guides, Patterns, and Security
11.2 Change Classification: Simplification, Incremental, and Re-Architecting Changes
Key Takeaways Explain This Topic AI
TOGAF classifies architecture change as Simplification, Incremental, or Re-architecting.
A simplification change can normally be handled via change management and is often driven by a requirement to reduce investment.
An incremental change may be handled via change management or may require partial re-architecting, and is driven by deriving additional value from existing investment.
A re-architecting change puts the whole architecture through the development cycle again, typically through a new Request for Architecture Work, to create new value.
TOGAF's guideline: a change impacting two or more stakeholders likely needs redesign and re-entry to the ADM, while one impacting a single stakeholder or allowable under a dispensation is a change-management candidate.
Last updated: October 2026
11.2 Change Classification: Simplification, Incremental, and Re-Architecting Changes
When drivers of change arise during the operational life of an enterprise architecture, the architecture organization must possess an objective, standardized mechanism to assess and categorize them. Applying the full weight of the Architecture Development Method (ADM) to every minor software upgrade would paralyze organizational delivery with stifling bureaucracy. Conversely, treating disruptive business model pivots as routine maintenance leads to uncontrolled architectural drift, fragmented systems, and catastrophic strategic misalignment. To balance governance agility against operational risk, the TOGAF Standard classifies architecture change into three categories: Simplification Change , Incremental Change , and Re-Architecting Change .
TOGAF's Three Classes of Architecture Change
TOGAF describes an approach to change management that classifies each required architectural change into one of three categories:
Class TOGAF description Typical motivation Usual handling
Simplification change Can normally be handled via change management techniques Often driven by a requirement to reduce investment Change management; update the baseline description
Incremental change May be handled via change management techniques, or may require partial re-architecting , depending on the nature of the change Driven by a requirement to derive additional value from existing investment Change management, or a partial iteration of the ADM
Re-architecting change Requires putting the whole architecture through the architecture development cycle again Driven by a requirement to increase investment to create new value New Request for Architecture Work and a new ADM cycle
To decide which class applies, TOGAF lists four activities: register all events that may affect the architecture; allocate and manage resources for architecture tasks; have the process or role responsible for architecture resources assess what should be done ; and evaluate the impacts .
TOGAF's Rule of Thumb: Count the Stakeholders
TOGAF offers a guideline for maintenance versus redesign:
If the change impacts two or more stakeholders , it is likely to require an architecture redesign and re-entry to the ADM .
If the change impacts only one stakeholder , it is more likely to be a candidate for change management .
If the change can be allowed under a dispensation , it is more likely to be a candidate for change management .
TOGAF's own examples:
A change with significant impact on the business strategy may require redoing the whole Enterprise Architecture: a re-architecting approach.
New technology or standards may require refreshing the Technology Architecture but not the whole Enterprise Architecture: an incremental change.
A change at the infrastructure level , for example ten systems reduced to one, may not change the architecture above the physical layer but will change the Technology Architecture baseline description: a simplification change handled via change management.
A refreshment cycle, either partial or complete re-architecting, may also be needed when the Foundation Architecture must be realigned with the business strategy, when substantial change is needed to components and guidelines used in deploying the architecture, or when significant standards used in the product architecture change.
The governance body must set criteria for deciding whether a Change Request needs only an architecture update or a new ADM cycle, and TOGAF warns it to avoid "creeping elegance" by focusing on changes that relate directly to business value. An Architecture Compliance report should state whether the change is compliant with the current architecture; if not, an exemption may be granted with valid rationale.
Scenario Analysis: Borderline Case Studies
Practitioners frequently encounter borderline scenarios where the classification requires rigorous architectural judgment:
Case Study 1: The Multi-CRM Rationalization Dilemma
An enterprise has six regional sales divisions running separate commercial off-the-shelf CRM instances acquired through historical acquisitions. An architectural proposal emerges to migrate all divisions to the enterprise-standard corporate CRM. Business capabilities remain identical; only complexity, maintenance overhead, and software licensing are reduced.
Classification : Simplification Change .
Rationale : The change eliminates technical redundancy and streamlines operations without altering the enterprise's strategic capabilities or principles. Governed via Phase H change management and Architecture Board approval without issuing a new Request for Architecture Work.
Case Study 2: The Core Database Version Upgrade
A high-volume payments platform running on an approved database platform requires an upgrade from version 12 to version 15 to preserve security compliance. No interface contracts change; existing data schemas and application code remain intact.
Classification : Incremental Change .
Rationale : The modification derives more value from the existing investment, by keeping the platform supported, without changing the architecture's structure, and it affects a single stakeholder group. Under TOGAF's guideline it is a candidate for change management rather than re-entry to the ADM.
Case Study 3: The Connected Vehicle Telematics Platform
A traditional automobile manufacturer decides to build an in-vehicle IoT telematics ecosystem, offering dynamic over-the-air software updates, autonomous driving telemetry streaming, and subscription-based digital features. This fundamentally disrupts the existing manufacturing-centric business architecture, introduces massive new data ingestion requirements, and establishes a brand-new direct-to-consumer revenue stream.
Classification : Re-Architecting Change .
Rationale : This initiative requires brand-new business capabilities, alters the corporate business model, and invalidates the existing Architecture Vision. A formal Request for Architecture Work is issued, triggering Phase A to define a new Architecture Vision.
Common Exam Traps & Practitioner Pitfalls
The 'Scope Creep Disguise' (Anti-Pattern) : Delivery teams attempting to implement a Re-Architecting Change incrementally across multiple minor releases to bypass executive scrutiny and formal Phase A Architecture Board approval. The enterprise architect must recognize cumulative architectural drift and mandate a new Request for Architecture Work.
The 'Simplification Panic' : Misclassifying system rationalization as re-architecting, forcing an organization through months of bureaucratic ADM restarts when the fundamental architecture vision remains unchanged.
The 'Cloud Migration Myth' : Assuming that every cloud migration is automatically a Re-Architecting Change. Migrating an existing virtual machine image unchanged into an Infrastructure-as-a-Service (IaaS) cloud ('lift-and-shift') is an Incremental or Simplification Change; refactoring a legacy monolithic mainframe application into a global event-driven serverless architecture is a Re-Architecting Change.