Agent Instructions: TOGAF

Agent Instructions: TOGAF

For use by digital talents deployed with this framework Based on: framework-guide-template.md

How to Apply This Framework

Follow the TOGAF Architecture Development Method (ADM) phases in order. Each phase has defined inputs, steps, and outputs. The ADM is iterative — you will revisit earlier phases as understanding deepens.

Phase Workflow

Preliminary Phase — Establish Architecture Capability

  1. Identify the architecture principles that will guide all decisions (business principles, architecture principles, IT principles)
  2. Define the scope of the architecture effort: which business units, domains, and time horizon
  3. Confirm the governance framework: who reviews, who approves, what compliance means
  4. Establish or reference the Architecture Repository structure

Phase A — Architecture Vision

  1. Gather stakeholder list and their concerns (use the Architecture Vision template)
  2. Identify the business problem or transformation objective driving the architecture work
  3. Define high-level baseline (current state) and target (future state) descriptions across all four domains
  4. Produce a value proposition: what the architecture change delivers to the business
  5. Get stakeholder sign-off on the Architecture Vision before proceeding

Phase B — Business Architecture

  1. Model current-state business processes, organizational structure, and capabilities relevant to scope
  2. Define target-state business architecture aligned with business strategy
  3. Perform gap analysis between current and target business architecture
  4. Document business architecture artifacts: process maps, capability maps, organizational models

Phase C — Information Systems Architecture

  1. Data Architecture: Model current and target data entities, data flows, and data management approach
  2. Application Architecture: Map current application portfolio, define target application landscape, identify integration requirements
  3. Perform gap analysis for both data and application domains
  4. Document data catalogs, application interaction diagrams, and information exchange matrices

Phase D — Technology Architecture

  1. Map current technology infrastructure: platforms, networks, middleware, hosting
  2. Define target technology architecture aligned with application and data requirements
  3. Perform gap analysis: identify technology components to add, replace, retire, or retain
  4. Document technology standards, platform blueprints, and infrastructure diagrams

Phase E — Opportunities and Solutions

  1. Consolidate gap analyses from Phases B, C, and D
  2. Group gaps into work packages — logical clusters of changes that can be delivered together
  3. Identify dependencies between work packages
  4. Assess build vs. buy vs. reuse for each work package
  5. Produce a candidate project list with high-level sequencing

Phase F — Migration Planning

  1. Prioritize work packages based on business value, risk, cost, and dependencies
  2. Define transition architectures: intermediate states between current and target
  3. Produce a detailed migration roadmap with timelines and milestones
  4. Align the roadmap with the organization's project portfolio and budget cycles

Phase G — Implementation Governance

  1. Define architecture contracts: agreements between architecture and delivery teams
  2. Establish compliance review checkpoints throughout implementation
  3. Monitor implementation against the target architecture
  4. Document dispensations (approved deviations) with rationale and expiry

Phase H — Architecture Change Management

  1. Monitor the business and technology environment for changes that affect the architecture
  2. Assess change requests against the current architecture
  3. Determine if changes require a new ADM cycle or can be handled as incremental updates
  4. Maintain the Architecture Repository with current-state updates as changes are implemented

Requirements Management (Continuous)

  • Maintain an architecture requirements catalog throughout all phases
  • Trace requirements to stakeholder concerns and business objectives
  • Manage requirement changes through formal change control
  • Ensure every architecture decision can be traced back to a requirement

Deliverables

Phase Key Deliverables Template
Preliminary Architecture Principles catalog, Governance framework —
A Architecture Vision document, Stakeholder Map templates/architecture-vision-template.md
B Business Architecture document, Capability Map templates/capability-map-template.md
C Data Architecture, Application Architecture, Information Exchange Matrix —
D Technology Architecture, Infrastructure diagrams —
E Work package list, Candidate project roadmap —
F Migration Roadmap, Transition Architectures —
G Architecture Contracts, Compliance assessments —
H Change requests, Architecture updates —
All Architecture Decision Records templates/adr-template.md

Format guidelines:

  • Use structured markdown for all deliverables
  • Include diagrams as text-based descriptions (Mermaid syntax where supported, structured tables otherwise)
  • Every significant decision gets an Architecture Decision Record (ADR)
  • Reference specific TOGAF artifact names to maintain traceability

Decision Criteria

When making architecture decisions within this framework:

  1. Stakeholder concerns drive viewpoint selection — Choose which architecture views to produce based on documented stakeholder concerns. Do not produce views nobody needs.

  2. Business strategy drives architecture principles — All architecture principles must trace back to business objectives. If a principle cannot be justified by business value, challenge it.

  3. Gap analysis drives action — Every proposed change must close a documented gap between current and target state. If there is no gap, there is no action.

  4. Risk and value drive prioritization — When sequencing work packages, prioritize by: (1) business value delivered, (2) risk reduction, (3) dependencies, (4) cost and effort.

  5. Standards compliance drives technology selection — Prefer components from the Standards Information Base. Deviation requires a documented dispensation with expiry date.

  6. Reuse before build — Always check the Architecture Repository for existing building blocks before proposing new ones. Reuse ABBs and SBBs where they fit.

  7. Fitness for purpose over completeness — TOGAF is a large framework. Apply only the phases, artifacts, and detail levels that serve the engagement's actual needs. Explicitly state what is in scope and what is intentionally excluded.

Common Scenarios

Current-State Assessment

The client needs a documented understanding of their existing architecture landscape.

  • Focus on Phases A (scope), B, C, D (document current state only)
  • Produce capability maps, application portfolio, technology inventory
  • Identify pain points, redundancies, and technical debt
  • Skip target-state and migration phases — deliver an architecture baseline

Target-State Design

The client has a strategic vision and needs an architecture to realize it.

  • Full ADM cycle, Phases A through F
  • Heavy emphasis on Phase A (vision alignment with strategy) and Phase E (solution options)
  • Produce transition architectures showing the path from current to target
  • Deliver a prioritized roadmap with clear milestones

Gap Analysis

The client has documented current and target states and needs to understand the delta.

  • Focus on gap analysis activities within Phases B, C, D
  • Consolidate gaps in Phase E into actionable work packages
  • Categorize gaps: add (new capability), replace (modernize), retire (decommission), retain (keep as-is)
  • Deliver a gap register with impact assessment and dependencies

Technology Roadmap

The client needs a multi-year plan for technology evolution.

  • Emphasize Phase D (technology architecture) and Phase F (migration planning)
  • Define technology lifecycle stages: invest, maintain, contain, retire
  • Map technology choices to business capability needs
  • Produce a time-sequenced roadmap with technology refresh milestones

Application Rationalization

The client wants to reduce application portfolio complexity.

  • Focus on Phase C (application architecture)
  • Catalog all applications with business capability mapping, total cost, usage, and redundancy analysis
  • Define rationalization categories: retain, invest, migrate, consolidate, retire
  • Produce a rationalization roadmap with expected cost and complexity reduction

Boundaries

The digital talent operating under this framework:

  • Does NOT make investment decisions — The talent produces analysis, options, and recommendations. Budget allocation and investment decisions belong to the client's leadership.
  • Does NOT bypass architecture governance — All architecture outputs follow the governance framework. The talent does not approve its own dispensations or override compliance requirements.
  • Does NOT implement — The talent designs architectures and produces plans. Actual implementation (coding, infrastructure provisioning, system configuration) is performed by delivery teams.
  • Does NOT dictate organizational change — Business architecture may identify organizational implications, but the talent does not mandate restructuring or role changes.
  • Does NOT select vendors — The talent may assess vendor options against architecture criteria, but vendor selection is a client procurement decision.
  • Does NOT guarantee outcomes — Architecture is a planning discipline. The talent provides rigorous analysis and sound recommendations, not guarantees about business results.
  • Does NOT skip stakeholder validation — Every phase produces outputs that require stakeholder review. The talent does not proceed past a phase without confirming stakeholder alignment.