TOGAF with Product, Agile, DevOps, Cloud, and Security

TOGAF and modern delivery work at different but overlapping levels. TOGAF structures enterprise-level intent, coherence, and governance; product and engineering practices optimize learning and delivery. Configure them as one system.

TOGAF and Agile

The ADM is iterative and can be used incrementally. A practical pattern:

flowchart LR
    Intent[Strategic intent and guardrails] --> Discovery[Product discovery]
    Discovery --> Arch[Architecture runway and decisions]
    Arch --> Delivery[Incremental delivery]
    Delivery --> Evidence[User and operational evidence]
    Evidence --> Discovery
    Evidence --> Landscape[Update architecture landscape]
    Landscape --> Intent

Working agreements

• architects participate in discovery, not only approval;
• teams receive outcomes, constraints, and guardrails—not detailed designs for every component;
• high-impact decisions are made at the last responsible moment;
• uncertainty is resolved with spikes, prototypes, and experiments;
• decisions and exceptions are recorded as work progresses;
• models and roadmaps are updated from delivery evidence.

Architecture runway

An architecture runway is the near-term enabling capability needed for upcoming delivery. It may include platform features, data foundations, interfaces, security controls, or technical debt reduction. Tie runway work to forecast outcomes and avoid building speculative infrastructure.

Product operating model

Persistent products change architecture governance:

• fund and govern outcomes and capabilities, not only temporary projects;
• maintain product-level target architecture and roadmap;
• give teams decision autonomy within enterprise guardrails;
• manage cross-product dependencies through domain and platform architecture;
• include architecture health and debt in product planning;
• use operational and customer measures in Phase H.

Enterprise architecture supplies common direction; product architecture maintains local evolution; solution architecture supports specific increments.

DevOps and continuous delivery

Shift conformance from document-only review toward executable evidence:

• policy as code;
• infrastructure and configuration as code;
• automated security and dependency checks;
• API/schema compatibility tests;
• service-level and resilience tests;
• cost and sustainability telemetry;
• deployment metadata linked to architecture assets;
• automated detection of prohibited or obsolete technology.

Humans still decide trade-offs, new patterns, and exceptions. Automation handles repeatable controls.

Cloud

TOGAF remains vendor-neutral. For cloud architecture, address:

• business and financial model;
• shared responsibility;
• workload placement criteria;
• identity and trust;
• data residency and sovereignty;
• networking and connectivity;
• landing zones and account/subscription structure;
• resilience and recovery;
• observability and operations;
• cost allocation and optimization;
• portability and exit strategy;
• skills and operating-model change.

Describe platform capabilities and policies before defaulting to a particular provider service.

Security and risk

Integrate security and risk across every ADM phase:

Use threat modeling and privacy analysis at the appropriate level. A security architecture that appears only in Phase D is too late and too narrow.

Data products and analytics

For data-product approaches, connect:

• domain accountability;
• business meaning and quality expectations;
• discoverability and metadata;
• access and permitted use;
• product service levels;
• interoperability standards;
• platform capabilities;
• lifecycle and cost.

Decentralized data ownership still needs enterprise semantic and governance mechanisms.

APIs, events, and integration

Architecture should establish:

• domain and ownership boundaries;
• interaction principles;
• contract and versioning standards;
• semantic governance;
• security and identity;
• reliability and failure behavior;
• discovery and lifecycle;
• observability and consumer impact management.

Avoid choosing synchronous APIs, events, files, or shared databases as a universal answer. Match the interaction to business semantics and quality needs.

Microservices

Microservices are a solution style, not a TOGAF requirement. Before adopting them, assess:

• domain boundaries and team ownership;
• independent change needs;
• operational maturity;
• data consistency and transaction semantics;
• latency and failure complexity;
• platform and observability capability;
• total cost compared with a modular monolith or managed product.

Document the decision and conditions under which it remains valid.

AI systems

Apply the same architecture disciplines while adding:

• model and data provenance;
• intended use and prohibited use;
• human oversight;
• quality, bias, and safety evaluation;
• privacy and intellectual-property controls;
• model, prompt, and knowledge lifecycle;
• monitoring and incident response;
• vendor and concentration risk;
• cost and sustainability.

Treat AI capability, data, application integration, platform, and governance as one cross-domain architecture problem.

Keeping architecture lightweight

Prefer:

• one linked source of truth;
• small views answering explicit questions;
• decision records;
• version-controlled diagrams-as-code where useful;
• generated inventories;
• automated conformance;
• living roadmaps;
• direct collaboration.

Lightweight means low waste, not low rigor.

Next: Real-life application scenario