11.3 Ongoing Governance, Retirement of Solutions, and Maintenance vs. New ADM Cycle

11.3 Ongoing Governance, Retirement of Solutions, and Maintenance vs. New ADM Cycle

Enterprise architecture does not end when a solution is deployed to production. In Phase H (Architecture Change Management), enterprise architects operate at the interface between long-term strategic design and daily operational reality. Achieving sustainable architecture requires active ongoing governance: collaborating with operational teams, monitoring temporary dispensations, systematically retiring obsolete solutions, keeping the Architecture Repository synchronized with production, and adjudicating the pivotal decision between handling changes via operational maintenance or launching a new ADM cycle.

---

Phase H in the Operational Governance Ecosystem

In operational environments, enterprise architecture must interface harmoniously with IT Service Management (ITSM / ITIL), DevOps delivery pipelines, Site Reliability Engineering (SRE), and the Architecture Board:

• Enforcing Architecture Contracts in Operations: During Phase G (Implementation Governance), Architecture Contracts bind project teams to approved designs. In Phase H, architects ensure that operational maintenance teams do not violate these contracts through unapproved configuration changes or out-of-band integrations.
• Managing Dispensations: A dispensation is a formal, temporary exemption granted by the Architecture Board allowing a project to deploy a non-compliant component due to urgent business constraints. In Phase H, the enterprise architect actively tracks dispensations, ensuring they do not transform into permanent unmanaged architecture. Dispensations carry strict expiration dates and remediation plans that must be executed during operational life.
• Mitigating 'Shadow IT' and Architectural Drift: Business units often deploy unapproved Software-as-a-Service (SaaS) tools or cloud infrastructure to bypass central IT backlogs. Phase H establishes automated discovery and periodic governance reviews to identify shadow IT before it introduces security vulnerabilities or data fragmentation.

---

Solution Retirement and Decommissioning Architecture

A critical topic heavily emphasized on the OGEA-103 examination is Solution Retirement. In many organizations, decommissioning is treated as an afterthought—an operational task delegated to IT helpdesk staff to 'turn off the server.' This neglect leads to the 'Zombie System' Anti-Pattern: legacy applications left running in a read-only state for years because nobody understands their undocumented dependencies. These unmanaged systems consume millions of dollars in software maintenance, run on unpatched operating systems that expose severe security vulnerabilities, and tether modern architectures to obsolete data structures.

TOGAF does not prescribe a retirement procedure, but its Phase G and H steps (identify building blocks for replacement, publish new Baseline Architectures, manage risks) call for disciplined decommissioning. A practical five-stage lifecycle looks like this:

The Five-Stage Architectural Retirement Lifecycle

1. User and Workload Migration:
   • Identify all active user personas, external partner integrations, and automated batch workflows.
   • Establish phased cutover schedules, migrating users to replacement Solution Building Blocks (SBBs).
   • Execute zero-traffic verification tests in production, monitoring network traffic to confirm that no hidden enterprise processes access the legacy endpoint.
2. Data Retention, Archival, and Statutory Compliance:
   • Formulate a data archival architecture that satisfies statutory regulatory retention periods (e.g., corporate tax records retained for 7 years; clinical health records retained for 25 years).
   • Extract historical records and transfer them to compliant, immutable, cost-effective cold storage (such as write-once-read-many [WORM] cloud archives).
   • Implement legal hold policies to preserve data subject to active litigation.
   • Execute cryptographic erasure and data destruction in strict adherence to data privacy regulations (e.g., GDPR 'Right to be Forgotten' and CCPA) for customer data that has exceeded statutory retention limits.
3. Interface Decoupling and Dependency Severance:
   • Catalog all inbound and outbound API integrations, message broker queues, enterprise service bus topics, and shared database links.
   • Formally deprecate API endpoints with published sunset notices to consumer applications.
   • Sever upstream data feeds and disable recurring batch schedules to prevent orphaned job failures or corrupted database locks.
4. Infrastructure and Resource Reclamation:
   • De-provision virtual machine instances, cloud container clusters, storage volumes, and virtual private network subnets.
   • Reclaim IP address allocations, revoke SSL/TLS security certificates, and decommission DNS routing entries.
   • For on-premises physical hardware, execute certified hardware sanitization and physical asset destruction in accordance with industry standards such as NIST SP 800-88.
5. Commercial and Contractual Termination:
   • Issue formal contract termination notices to commercial software vendors prior to penalty cutoff deadlines.
   • Terminate third-party maintenance, support, and managed services agreements, realizing immediate operational expenditure (OpEx) savings.
   • Release or reallocate enterprise software license entitlements across other business units.

---

Maintaining the Architecture Repository in Phase H

The Architecture Repository serves as the enterprise's authoritative single source of architectural truth. If the repository does not reflect the reality of production operations, downstream architecture initiatives will design target solutions against inaccurate assumptions. During Phase H, the relevant areas of the TOGAF 10 Architecture Repository must be updated:

• Architecture Landscape: Update baseline models across Business, Data, Application, and Technology architectures to reflect retired components, newly deployed SBBs, and updated operational interfaces.
• Standards Library: Move outdated technologies through the standards lifecycle (for example, from Standard to Phasing-Out or Retired) and promote successful provisional standards to Standard.
• Reference Library: Archive obsolete architectural patterns and publish new reusable reference models, design patterns, and templates derived from operational lessons learned.
• Governance Repository: Record decisions in the decision log, along with compliance assessments, closed dispensations, and changes to the project portfolio. The Solutions Landscape should also stop showing the retired SBBs.

---

The Strategic Decision Point: Maintenance vs. New ADM Cycle

One of the most consequential decisions an enterprise architect makes in Phase H is determining how to respond to an approved change driver. When an operational change request or capability demand arrives, the Architecture Board evaluates it against rigorous governance criteria to determine whether it can be handled via maintenance governance or requires initiating a new ADM cycle.

Evaluation Criteria for Initiating a New ADM Cycle

TOGAF's guideline (Section 11.2) is a useful first test: changes impacting two or more stakeholders are likely to need redesign and re-entry to the ADM, while changes impacting one stakeholder or allowable under a dispensation are candidates for change management. The Architecture Board then also considers four practical questions:

1. Does the change breach the approved Architecture Vision and Statement of Architecture Work? If the proposed change alters the strategic intent, boundaries, or core principles established in Phase A, it cannot be handled as an operational maintenance change.
2. Does the change require the creation of new enterprise business capabilities? Incremental enhancements to existing capabilities can be handled via maintenance; establishing brand-new capabilities requires a new ADM cycle.
3. Does the financial investment or operational risk exceed pre-authorized thresholds? If the change demands significant capital expenditure (CapEx) or introduces enterprise-wide operational risk, it requires executive sponsorship through Phase A.
4. Does the cumulative impact of past maintenance changes represent architectural drift? Multiple minor incremental changes can gradually distort system cohesion. When cumulative drift degrades architectural integrity, a new ADM cycle must be triggered to re-baseline the architecture.

Issuing the Request for Architecture Work (RfAW)

When a change exceeds maintenance thresholds, Phase H terminates its operational pathway and formulates a formal Request for Architecture Work (RfAW). The RfAW is the official document that sponsors and initiates Phase A (Architecture Vision). It contains:

• The strategic business problem or opportunity statement.
• Business mission, strategic drivers, and executive sponsorship context.
• Organizational boundaries, budget limits, and time-to-market constraints.
• Current architecture baseline summary and target capability expectations.

Upon authorization of the RfAW by the executive steering committee and Architecture Board, the enterprise formally re-enters Phase A, restarting the ADM cycle with dedicated resources and clear executive mandate.

---

Common Exam Traps & Practitioner Pitfalls

• The 'Zombie System' Trap: Retaining legacy systems in production indefinitely because no one understands their undocumented dependencies, incurring perpetual licensing costs and security risks.
• Out-of-Sync Architecture Repositories: Failing to update the Architecture Landscape after decommissioning, leading subsequent ADM cycles to design against ghost systems.
• Unilateral Project Authority: Allowing individual project managers or engineering leads to decide whether a scope expansion is maintenance or re-architecting without Architecture Board oversight.