You can survive on it for a while. You definitely should not build a mission around it.
1. The analogy nobody asked for, but everyone deserves
Potatoes are incredible. They are calorie dense, resilient, cheap, and historically important. They are also completely useless for space travel. No propulsion, no navigation, no life support, no guidance system. You can eat a potato in space, but you cannot go to space with one.
TOGAF sits in the same category for enterprise architecture. It is nutritionally comforting to executives, historically significant, and endlessly referenced. But as an operating system for modern architecture, it provides no thrust, no trajectory, and no survivability once you leave the launch pad.
2. What TOGAF actually optimises for (and why that is the problem)
TOGAF does not optimise for outcomes. It optimises for process completion and artifact production.
It is exceptionally good at helping organisations answer questions like:
- Have we completed the phase?
- Is there a catalog for that?
- Has the architecture been reviewed?
- Is the target state documented?
It is almost completely silent on questions that actually matter when building modern systems:
- How fast can we deploy safely?
- What happens when this service fails at 02:00?
- What is the blast radius of a bad release?
- How do we rotate keys, certificates, and secrets without downtime?
- How do we prevent a single compromised workload from pivoting across the estate?
- How do we design for regulatory audits that happen after things go wrong, not before?
TOGAF assumes that architecture is something you design first and then implement. Modern systems prove, daily, that architecture emerges from feedback loops between design, deployment, runtime behaviour, and failure.
TOGAF has no opinion on runtime reality. No opinion on scale. No opinion on latency. No opinion on failure. That alone makes it largely pointless.
3. The ADM: an elegant spiral that never meets production
The Architecture Development Method is often defended as “iterative” and “flexible”. This is technically true in the same way that walking in circles counts as movement.
ADM cycles through vision, business architecture, information systems, technology, opportunities, migration, governance, and change. What it never forces you to do is bind architectural decisions to:
- Deployment pipelines
- Observability data
- Incident postmortems
- Cost curves
- Security events
- Regulatory findings
You can complete the ADM perfectly and still design a system that:
- Requires weekend release windows
- Cannot be partially rolled back
- Fails open instead of failing safe
- Has shared databases across critical domains
- Exposes internal services directly to the internet
- Has no credible disaster recovery story beyond “restore the backup”
That is not iteration. That is documentation orbiting reality.
4. Architecture by artifact is not architecture
TOGAF strongly implies that architecture quality increases as artifacts accumulate. Catalogs, matrices, diagrams, viewpoints, repositories. The organisation feels productive because things are being filled in.
Modern architecture quality increases when:
- Latency is reduced
- Failure domains are isolated
- Dependencies are directional and enforced
- Data ownership is explicit
- Security boundaries are non negotiable
- Change is cheap and reversible
None of these improve because a document exists. They improve because someone made a hard decision and encoded it into infrastructure, platforms, and guardrails.
Artifact driven architecture replaces decision making with description. Description does not prevent outages, fraud, or regulatory breaches. Decisions do.
5. TOGAF governance vs real architectural leverage
TOGAF governance is largely procedural. Reviews, compliance checks, architecture boards, and sign offs. This feels like control, but it is control over paperwork, not over system behaviour.
Real architectural leverage comes from a small number of enforced constraints:
- No shared databases between domains
- All services deploy independently
- All external access terminates through managed gateways
- Encryption everywhere, no exceptions
- Secrets never live in code or config files
- Production access is ephemeral and audited
- Every system has a defined failure mode
TOGAF does not give you these rules. It gives you a language to debate them endlessly without ever enforcing them.
6. TOGAF certification vs AWS certification in a cloud banking context
This is where TOGAF truly collapses under scrutiny.
Imagine you are designing a cloud based banking app. Payments, savings, lending, regulatory reporting, fraud detection, and customer identity. You have two architects.
Architect A:
- TOGAF certified
- Deep knowledge of ADM phases
- Can produce target state diagrams, capability maps, and principles
- Strong in stakeholder alignment workshops
Architect B:
- AWS Solutions Architect Professional
- AWS Security Specialty
- AWS Networking Specialty
- AWS DevOps Professional
Now ask a very simple question. Which one can credibly design and defend the following decisions?
- Multi account landing zone design with blast radius containment
- Zero trust network segmentation using cloud native primitives
- Identity design using federation, least privilege, and break glass access
- Encryption strategy using managed keys, HSMs, rotation, and separation of duties
- Secure API exposure using gateways, throttling, and mutual authentication
- Data residency and regulatory isolation across regions
- Resilience patterns using multi availability zone and multi region strategies
- Cost controls using budgets, guardrails, and automated enforcement
- Incident response integrated with logging, tracing, and alerting
- CI CD pipelines with automated security, compliance checks, and rollback
A TOGAF certificate prepares you to talk about these topics. Four cloud certifications prepare you to actually design them, build them, and explain their tradeoffs under audit.
In a regulated cloud banking environment, theoretical alignment is worthless. Auditors, regulators, and attackers do not care about your architecture repository. They care about what happens when something fails.
7. What modern architects actually need to know
This is the part TOGAF never touches.
A modern architect must have deep, practical understanding of the primitives the system is built from, not just the boxes on a diagram.
That means understanding cloud primitives at a mechanical level: compute scheduling, storage durability models, network isolation, managed identity, key management, quotas, and failure semantics. Not at a marketing level. At a “what breaks first and why” level.
It means being fluent in infrastructure as code, typically Terraform, and understanding state management, drift, blast radius, module design, promotion across environments, and how mistakes propagate at scale.
It means real security knowledge, not principles. How IAM policies are evaluated, how privilege escalation actually happens, how network paths are exploited, how secrets leak, how attackers move laterally, and how controls fail under pressure.
It means understanding autoscaling algorithms: what metrics drive them, how warm up works, how feedback loops oscillate, how scaling interacts with caches, databases, and downstream dependencies, and how to stop scale from amplifying failure.
It means observability as a first class architectural concern: logs, metrics, traces, sampling, cardinality, alert fatigue, error budgets, and how to debug distributed systems when nothing is obviously broken.
It means durability and resilience: replication models, quorum writes, consistency tradeoffs, recovery point objectives, recovery time objectives, and the uncomfortable reality that backups are often useless when you actually need them.
It means asynchronous offloads everywhere they matter: queues, streams, event driven patterns, back pressure, retry semantics, idempotency, and eventual consistency instead of synchronous coupling.
And yes, it means Kafka or equivalent streaming platforms: partitioning, ordering guarantees, consumer groups, replay, schema evolution, exactly once semantics, and how misuse turns it into a distributed outage generator.
None of this fits neatly into a TOGAF phase. All of it determines whether your bank survives load, failure, fraud, and regulatory scrutiny.
8. Why TOGAF survives despite all of this
TOGAF survives because it is politically safe.
It does not force engineering change. It does not threaten existing delivery models. It does not require platforms, automation, or hard constraints. It can be rolled out without upsetting anyone who benefits from ambiguity.
It allows organisations to claim architectural maturity without confronting architectural debt. It creates the appearance of control while avoiding the discomfort of real decisions.
Like potatoes, it is easy to distribute, easy to consume, and difficult to kill.
9. What architecture actually is in 2026
Modern architecture is not a framework. It is a set of enforced constraints encoded into platforms.
It is the intentional shaping of decision space so teams can move fast without creating systemic risk. It is about reducing coupling, shrinking blast radius, and making failure survivable. It is about designing systems that assume humans will make mistakes and attackers will get in.
If your architecture cannot be inferred from:
- How your systems deploy
- How they scale
- How they fail
- How they recover
- How access is controlled
- How data is isolated
- How incidents are handled
Then it is not architecture. It is comfort food.
And comfort food has never put a bank safely into the cloud.