⏱ 24 min read
Most TOGAF and ArchiMate adoption is cosmetic. ArchiMate training
That reads a bit severe, but in practice it is hard to dispute. If you have spent any real time around public-sector transformation programs, you have probably seen the pattern yourself: repositories full of diagrams no one opens, governance packs with ADM phase names carefully inserted into PowerPoint headers, capability maps and reference architectures produced mainly because someone in audit, PMO, or procurement expects them to exist.
And then the real decisions show up — funding cuts, a new legal interpretation, an integration vendor missing a milestone, a ministry suddenly insisting on stronger identity assurance — and architecture is nowhere near the room where the tradeoffs are actually being made.
I have seen three failure modes come up again and again.
First, method without models. The organization has architecture boards, checkpoints, waivers, standards, and a very serious TOGAF vocabulary. But there is no shared way to describe what is changing. So every project speaks its own dialect. “Service” means one thing to policy, another to operations, and something else again to IT. Everyone nods. Almost nobody agrees.
Second, models without method. Beautiful ArchiMate views. Clean layering. Impressive repository. But no decision rights. No migration logic. No credible sequencing. The diagrams look like architecture, yet function more like decoration.
Third — and this is more common than many teams like to admit — tool-driven architecture. The repository structure starts dictating the practice. Teams model what the tool makes easy, not what the program genuinely needs. If the metamodel has twelve relationship types and a migration object, suddenly everything gets treated as a relationship problem and a migration object, even when the real issue is unresolved ownership between agencies.
Government environments amplify all of this. Cross-agency services. Legacy registries that cannot be touched because the only two people who really understand them are close to retirement. Compliance obligations that are entirely real. Political deadlines that are completely indifferent to architecture maturity. Procurement boundaries that split solution design from implementation in about the least helpful way possible.
So this is not another “how TOGAF maps to ArchiMate” explainer. Honestly, that framing is part of the problem. ArchiMate modeling guide
My view is simpler, and in my experience far more useful: TOGAF and ArchiMate work together only when you stop trying to make them the same kind of thing.
TOGAF is about organizing architectural work — decisions, sequencing, governance, transition logic, stakeholder movement. ArchiMate is about making architecture content inspectable — what depends on what, what is changing, what a service actually means, where impact lands when something upstream shifts. ArchiMate tutorial
That is the integration.
Not a matrix. Not a certification answer. More a disciplined operating habit than anything else.
Stop trying to map them one-to-one
A lot of teams begin with the wrong question: “What ArchiMate deliverable belongs in each ADM phase?”
I understand the instinct. It feels orderly. It gives training material something clean and tidy to say. It creates the impression that architecture can be industrialized.
But it breaks down very quickly in real transformation work.
ADM phases are not notation buckets. They are decision and governance containers. They tell you, in broad terms, what kind of architectural work needs to happen: establish context, understand baseline, shape target, consider options, plan transition, govern delivery, deal with change. Useful. Very useful, actually. But they do not imply that each phase should produce a fresh family of diagrams, or that architecture advances in neat sequential blocks.
ArchiMate, meanwhile, is expressive in a different way. It helps you model structure, behavior, motivation, strategy, implementation, and the relationships across them. That matters a great deal. But it is not a management process. It does not tell you who has authority to approve an interoperability exception. It does not resolve whether a procurement lot should be split around IAM capabilities or event streaming. It does not decide whether your “target architecture” should tolerate coexistence with a ten-year-old case management platform for another three budget cycles.
Public-sector transformation is iterative, interrupted, and political. Sometimes the legal basis is less stable than the application landscape. Sometimes the business architecture exists only as policy intent plus a patchwork of local workarounds. Sometimes the technical answer is obvious and institutionally impossible.
So the practical reframing is this:
- TOGAF = how the architecture work is organized
- ArchiMate = how the architecture content is made inspectable
It sounds almost too obvious, but it changes behavior.
Instead of asking, “What framework artifact do we owe this phase?” you ask:
- What is changing?
- What depends on what?
- Who owns the decision?
- What can be sequenced safely?
- What breaks if the policy text changes?
- What must be explicit before procurement starts?
- Where is ambiguity actually dangerous?
That is where the integration really lives.
Take a ministry launching a digital permitting platform. TOGAF is useful for structuring the work: stakeholder alignment, scope, principles, baseline/target discipline, transition planning, governance. ArchiMate is useful selectively: showing citizen-facing business services, permit workflows, shared evidence services, application dependencies, registry integrations, IAM touchpoints, and implementation plateaus.
Not every phase needs a diagram. Not every diagram needs to be ArchiMate. And not every ArchiMate view deserves to survive beyond the decision it supported.
That is healthy.
Government distorts both frameworks — in predictable ways
Public-sector architecture has recurring structural conditions that many people underestimate, especially if most of their framework experience comes from commercial environments.
Ownership is fragmented. Requirements often arrive policy-led and half-formed. Procurement can separate architecture from implementation so aggressively that design intent leaks out before delivery even begins. Interoperability obligations cross agencies, sectors, and sometimes national boundaries. Data outlives political sponsorship by decades.
In that kind of environment, TOGAF tends to get over-governed. ArchiMate tends to get over-modeled.
I have seen architecture capabilities in government that were strong on review boards and very weak on intervention. They could stop a project for missing a template, yet could not force a decision on shared identity, canonical events, or service ownership. That is governance theatre, and most experienced practitioners recognize it immediately.
On the modeling side, teams often react to ambiguity by producing more models. Understandable, but usually the wrong move. When ownership is unclear, they model everything. When legal interpretation is pending, they model all variants. When procurement lots are under discussion, they create a repository structure that mirrors the lot structure before the sourcing strategy has even settled.
That is how you end up with complete-looking architecture that still cannot answer the one question the program director actually has: “Can we roll out municipality group A before registry integration B is ready, and if so, what manual fallback do we need?”
Three examples.
In a cross-border social security exchange, the business agreement may exist before application ownership is clear. Everyone agrees benefits data needs to move. No one agrees which agency owns the validation service. If you over-model too early, you create false certainty. Better to use ArchiMate to expose collaboration, service dependencies, and information exchange points while TOGAF-style governance resolves who is genuinely accountable.
In a national identity federation, motivation and policy concerns dominate technical design early on. Identity proofing level, consent basis, cross-border trust, audit requirements — these shape the architecture before anyone should be drawing polished platform diagrams. Yet teams often jump straight into application landscapes and cloud deployment views because those feel more concrete. In my experience, that is the wrong order.
In a municipal grants system consolidation, process standardization often lags platform procurement. That means your architecture has to represent intentional non-uniformity for a while. You may have a shared grants portal, a common document service, and Kafka-based event notifications, while assessment workflows remain locally distinct because the municipalities are not ready to harmonize criteria. If your target architecture pretends standardization has already happened, delivery drifts into fiction.
One opinion, stated plainly: in EU institutional work, architecture often succeeds not by producing completeness, but by exposing where completeness is impossible for now.
That is not failure. It is useful honesty.
What TOGAF is actually good for
Strip away the certification language and TOGAF is still worth having. In practice, I would say more worth having. TOGAF training
I find TOGAF useful for six things.
Stakeholder framing. Not glamorous, but indispensable. Who matters, who decides, who blocks, who pays, who carries operational risk, who can grant an exception. In government this is often half the battle. You can be technically right and still lose because the data protection office, municipal CIO forum, and procurement director were engaged in the wrong order.
Architecture partitioning. Where do we cut the problem? By domain, capability, agency, platform, journey, procurement lot? Good architecture work is often about choosing the least harmful partitioning logic. TOGAF helps create a disciplined way to do that.
Baseline/target discipline. Not because baseline and target are magical concepts, but because teams routinely mix current pain, future aspiration, and political slogans into one blurry picture. Separating them forces a cleaner conversation.
Migration planning. This is where TOGAF really earns its keep. Real transformation is not target-state art; it is movement across constraints. Coexistence states, temporary interfaces, decommissioning windows, funding gates, legal milestones — this is the hard part.
Governance checkpoints tied to risk. Not generic approval rituals. Actual moments where architecture should influence go/no-go, scope control, exception handling, and design assurance.
Requirements management as a loop. This is one thing people say and often fail to operationalize. Requirements in public-sector programs do not sit still. Legal interpretation changes. Security baselines change. The minister wants a pilot in three months. A dependency on national IAM becomes mandatory halfway through discovery. If requirements management is treated as an artifact rather than a continuous loop, architecture lags reality.
What is less useful? Sequential purity of ADM. Exhaustive deliverable catalogs. Content metamodels treated as mandatory law. I have never seen a public program improve because someone insisted on phase-perfect compliance with a textbook ADM interpretation.
Use ADM as a conversation architecture.
Compress phases for smaller initiatives. Reopen phases when legal or policy shifts occur. Do not apologize for it.
I worked on a customs declaration modernization effort where target architecture assumptions had to be rewritten after a legal interpretation changed the required retention and audit treatment for declaration events. Suddenly event immutability, audit trace design, and storage tiering were architecture questions again. We effectively looped back from implementation assurance into architecture definition. That was not methodological failure. It was responsible practice.
A common mistake, though, is treating Phase B, C, and D as separate reporting silos. Business architecture gets written by one set of people, application architecture by another, technology architecture by a third, each producing respectable but disconnected narratives. Then someone tries to stitch them together in a steering pack and discovers the “business service” in one deck has no relationship to the “application service” in another.
That is exactly where ArchiMate can help — if used with discipline.
ArchiMate’s real value is controlled ambiguity reduction
Not visualization.
Visualization is a byproduct.
ArchiMate earns its keep when it reduces ambiguity in a controlled way. It lets you say, with precision, whether you mean a business service, a process, an application service, an interface, a role, a collaboration, a data object, or a work package. In messy programs, those distinctions are not academic. They prevent expensive misunderstandings.
Consider a citizen address change service. It sounds simple. It rarely is. Is the “service” the citizen-facing interaction? The internal change-of-record process? The API exposed to downstream agencies? The batch synchronization with legacy registries? Without some disciplined language, those all get collapsed into one thing called “address update,” and every conversation becomes slippery.
ArchiMate helps separate them:
- the business service offered to the citizen
- the business process that validates and routes the change
- the application service performing address verification
- the data object representing address evidence
- the interface through which municipalities or agencies consume updates
That matters when funding, ownership, and SLAs differ across those layers.
In inter-agency case management, collaboration and actor/role modeling are often where the breakthrough happens. Agencies say “we own the case,” but what they really own may be a decision step, an intake function, a legal accountability role, or a system boundary. Modeling actor versus role versus collaboration sounds trivial right up until it resolves six months of circular governance argument.
In an eProcurement platform, implementation and migration concepts become especially useful. If vendor lot A delivers supplier onboarding, vendor lot B delivers workflow, vendor lot C delivers analytics, and IAM is delivered as a shared platform capability, then plateaus and work packages are not decorative. They are how you expose whether the rollout path is coherent.
Selective usage is the key.
Not every stakeholder needs full notation. In fact, many should never see it in raw form. Most government teams benefit from a constrained subset of the language and a very small set of recurring viewpoints. Tailor views ruthlessly. If a deputy director needs to understand why identity proofing delays municipal onboarding, do not show a full-layer metamodel rendering. Show the handful of services, constraints, dependencies, and transition states that make the issue visible.
And here is a practical warning I feel strongly about: if modelers cannot explain why a relationship exists, the repository becomes a confidence trick.
I have inherited repositories where relationships were auto-generated, bulk-imported, or inferred from spreadsheet joins. The diagrams looked comprehensive. The meaning was rotten. Once stakeholders realize the model cannot be trusted, recovery is hard.
Use TOGAF to run the journey, ArchiMate to stabilize the meaning
This is the integration model I have seen work.
Start with TOGAF questions. Model only what must survive debate. Use ArchiMate views to support decisions, not to archive everything. Then feed those decisions back into transition planning and governance.
It sounds simple because, in a way, it is. The hard part is consistency.
The recurring work products are usually the same, even if you call them something else:
- stakeholder concerns
- baseline snapshots
- target operating model views
- transition architectures
- architecture decisions and principles
- implementation roadmap
- exceptions and change triggers
The mistake is recreating ArchiMate artifacts phase by phase as if they were disposable deliverables. Better to let a small number of models evolve across the ADM cycle. A baseline application cooperation view becomes annotated for target state. A motivation view gets updated when policy changes. A migration view gains additional plateaus when procurement sequencing shifts.
That evolution matters because architecture memory matters.
Repository discipline matters too. One concept, one owner, many views. If “Shared Evidence Collection Service” exists, it should not be semantically reinvented in a PowerPoint, a wiki page, and a modeling tool with slightly different meanings in each place.
I’ll put this sharply because it is true: if your ArchiMate repository and your architecture board deck tell different stories, the deck will win and the repository is already dead.
People trust what governs decisions.
Where ArchiMate adds value inside TOGAF work
Here is the mapping that is actually useful — not a one-to-one phase output mapping, but where ArchiMate adds leverage inside TOGAF-style work. ArchiMate in TOGAF
I would not hand this table to a team and say, “go produce all of these.” That would miss the point entirely.
Use it as a filter.
A worked example: digital permitting across a ministry and municipalities
Let’s make this concrete.
Imagine a ministry trying to digitize permitting across regional offices and municipalities. Citizens repeatedly submit the same evidence — identity documents, land records, compliance certificates, payment confirmations. Legal rules vary a little by sector. Existing systems include document management, case handling, payment, GIS or registry integrations, and a patchwork of local portals. Some municipalities are reasonably modern. Others are hanging onto aging platforms with brittle vendor contracts.
This is exactly the kind of environment where people get TOGAF and ArchiMate wrong.
Vision and scoping
The first useful move is not to model the entire landscape. It is to frame the transformation.
Using TOGAF thinking, you establish stakeholders, scope boundaries, constraints, principles, and likely transition assumptions. You identify that this is not just a portal project; it is a service, workflow, evidence, IAM, and interoperability problem with local autonomy constraints.
Then ArchiMate helps, but sparingly. A high-level motivation view can connect drivers like citizen service quality, administrative burden reduction, legal compliance, and municipal autonomy. A business service view can show the intended “Permit Submission Service,” “Evidence Validation Service,” and “Decision Notification Service” without pretending all local workflows are already harmonized.
At this stage, if somebody is asking for cloud deployment diagrams, they are probably asking the wrong question too early.
Baseline understanding
Now you need enough baseline to reason about change.
Not a museum catalog. Enough baseline.
Typically that means modeling major process fragmentation, duplicate data capture, inconsistent service channels, and the key application/data dependencies. Maybe the ministry runs a central document management platform; municipalities run local case systems; payment is handled through two providers; identity is federated through a national IAM service for citizens but not for delegated professional users; event notifications are nonexistent or point-to-point.
This is where I often use an application cooperation view plus one business-process-to-application support view. If Kafka is under consideration as the event backbone, model the interaction patterns that matter: permit submitted, evidence requested, evidence received, payment confirmed, decision issued. Do not draw a generic “event-driven architecture” poster and call it useful. Show which applications publish, which consume, and where manual fallback still exists.
Target architecture
The target might include:
- a unified permit submission service
- a shared evidence collection service
- common IAM integration for citizen and officer access
- standardized status notifications
- municipal-specific decision workflows retained where legally necessary
- canonical event topics for major lifecycle steps
- API-mediated access to registries rather than bespoke file exchanges
This is where ArchiMate starts paying for itself. Business service views reveal what can be standardized. Application cooperation views show where shared services reduce duplication. Data object views help expose whether “permit application,” “evidence package,” and “decision record” are truly common or only superficially similar.
And, very importantly, the models show what cannot be standardized yet. In government programs, that is gold. You avoid false target states.
Transition planning
Now TOGAF becomes the stronger instrument again.
You define plateaus. Pilot municipalities first. Then rollout of the central evidence service. Then expansion of IAM capabilities. Then selective decommissioning of old portals. Maybe legacy case systems remain in coexistence for years. Fine. Model that honestly.
ArchiMate implementation and migration elements can make this visible, but the point is not notation purity. The point is to support decisions like:
- Can onboarding proceed before all municipalities adopt the same workflow?
- Is the shared IAM dependency on the critical path?
- Do we need interim adapters for document management?
- Can Kafka-based event propagation start before all consumers are event-ready?
- Which legacy interfaces must remain until payment reconciliation is centralized?
A migration view that shows plateaus and coexistence states is more valuable here than ten polished target-state diagrams.
Governance and reality
Then the real world arrives.
Legal harmonization does not happen on schedule. Identity assurance requirements change mid-program because the national cybersecurity authority updates guidance. One municipality refuses platform onboarding because of procurement lock-in concerns with its current case management vendor.
Now architecture has to support negotiation, not just design.
The architecture board should not be reviewing abstract compliance. It should be using a small set of recurring views:
- motivation and constraints
- business service and ownership
- application cooperation and dependencies
- transition plateau and exceptions
That small discipline keeps the architecture alive.
And the lesson, in my experience, is always the same: ArchiMate views become useful when tied to specific decisions and exceptions. Otherwise they drift into repository wallpaper.
That diagram is intentionally simple. In practice, that level of clarity gets used. A giant full-notation rendering often does not.
The mistakes people keep repeating
Some of these are so common they may as well be printed on the wall.
Trying to model the whole enterprise before deciding anything.
I understand the impulse. It feels responsible. Usually it delays the only thing that matters: making a few high-value decisions with enough shared understanding to move.
Letting tool metamodels dictate architecture scope.
If the repository wants every application linked to every data object and every data object linked to every process, resist. Scope should come from the transformation problem, not the import wizard.
Confusing repository completeness with architectural maturity.
A full repository can coexist with terrible architecture. I have seen benefits modernization programs with four elegant target diagrams and no migration logic at all. Beautiful dead ends.
Using ArchiMate as a stakeholder presentation language without simplification.
Most sponsors do not need notation education. They need clarity. Translate.
Treating TOGAF deliverables as mandatory outputs rather than optional controls.
If a deliverable is not helping a decision, a risk review, a procurement gate, or implementation assurance, question it.
Separating business architecture and solution architecture too rigidly.
In public-sector programs, this split often creates false handoffs. The “business” architecture says standardize case intake. The “solution” team discovers legal distinctions that require local variation. Meanwhile no one owns the reconciliation.
Ignoring transition states because the target looks cleaner.
This one is fatal. Most public transformations live in transition states for years. Model them.
Failing to model ownership ambiguity.
In a justice-sector integration effort I once saw, every agency used the word “case” differently and no model made the ownership distinctions explicit. Months of debate could have been shortened with one decent collaboration and information view.
Not connecting legal drivers to architecture elements.
If a legal obligation changes and you cannot trace impact to service, process, application, or data handling, your architecture is too detached from reality.
A pan-agency API strategy I reviewed looked polished but omitted procurement transition realities entirely. It assumed agencies could just expose standard APIs in sequence. In reality, half the systems were under outsourced contracts with change windows and charging models that made that sequencing impossible. Architecture without commercial reality is fiction with better formatting.
How to decide what to model and when
Here is the heuristic set I wish more teams used.
Model where there is disagreement.
Model where funding depends on dependency clarity.
Model where transition risk is high.
Do not model stable commodity areas in unnecessary detail.
Stop modeling when a decision is made and traceable.
That last one matters. Architecture teams often keep polishing models after the useful moment has passed. There is a kind of emotional comfort in elaboration. Resist it.
For a typical government transformation, a minimum viable model set is often enough:
- a motivation/context view
- a business service and process view
- an application cooperation/integration view
- a data dependency or information structure view where needed
- a migration or plateau roadmap view
That is not trivial. If those five are coherent and maintained, they outperform a “prestigious” repository nobody trusts.
Tailor by audience.
Policy sponsors need outcomes, constraints, and impact.
The CIO office needs dependencies, platform implications, IAM, integration, cloud posture, decommissioning logic.
Delivery teams need enough precision to make design choices without re-litigating architecture intent.
Procurement and legal stakeholders need service boundaries, ownership, constraints, and the right degree of design freedom preserved.
One practical point on cloud, Kafka, and IAM, because these come up constantly.
Cloud architecture should usually be modeled at the level of platform capabilities and constraints, not product catalogs. Show managed integration, event streaming, identity services, network trust zones, resilience expectations, data residency constraints. If you fill your architecture with vendor-specific labels too early, it ages badly and contaminates procurement neutrality.
Kafka, or any event backbone, should be modeled only where event semantics and sequencing matter. “We use Kafka” is not architecture. “Permit submitted event is published by submission service, consumed by evidence, case initiation, and notification components, with replay and audit implications” — that is architecture.
IAM should almost always appear earlier than teams expect. In government programs, identity is not plumbing. It shapes service access, delegated authority, auditability, onboarding, and in many cases legal admissibility. If identity assurance or role delegation is still fuzzy, your target architecture is less stable than it looks.
Governance, repositories, and delivery reality
This is where many architecture practices quietly come apart.
If architecture governance sits outside budget or procurement control, TOGAF will sound serious but remain optional.
Architecture review boards, design authorities, exception handling, architecture contracts — all useful concepts. But in public settings with multiple vendors, framework contracts, outsourced build, and retained architecture accountability, the mechanics matter more than the labels.
A workable pattern looks something like this:
Define canonical views for governance checkpoints.
Version transition architectures.
Maintain traceability only where it affects funding, compliance, interoperability, or decommissioning.
Assign clear ownership for model updates.
Tie architecture artifacts to epics, procurement lots, and implementation milestones.
That last one gets neglected all the time. If the architecture says “shared case service first, local workflow adaptation second,” but the procurement lots incentivize vendors to optimize their own component delivery rather than the sequence, the architecture will lose.
I worked on a shared case management procurement where architecture principles and target service views were inserted directly into tender documentation. Not over-specified, but enough to constrain bidders around service boundaries, IAM integration, interoperability expectations, and transition coexistence. That made the architecture real because it entered the commercial mechanism.
If you cannot connect architecture to money, approvals, and delivery gates, you do not have an operating practice. You have commentary.
Think in loops, not linear phases
Many practitioners already work this way but pretend otherwise.
The honest pattern is a loop:
vision, targeted baseline discovery, option shaping, transition decision, implementation assurance, change trigger, repeat.
Legislation changes. Funding shifts. A vendor exits. A security control becomes mandatory. An inter-agency agreement stalls. Back you go.
TOGAF can handle this perfectly well if you stop treating ADM as a railway timetable and start treating it as a reusable structure for clarification. ArchiMate supports those loops by preserving meaning across iterations. The same service, process, application, and motivation elements can survive through multiple rounds of refinement, rather than being redrawn from scratch each time someone wants a fresh deck.
The mistake is pretending the work was linear and then producing phase-perfect documentation after the fact. Everyone sees through it anyway.
What maturity actually looks like
Not maturity-model jargon. Observable behavior.
Architecture discussions use a shared vocabulary.
People can trace why a service change affects a system, a team, or a procurement lot.
Transition states are explicit.
Exceptions are recorded and reviewed.
Repository content stays alive because it is reused in governance and delivery.
Model detail varies by risk and importance.
In a mature government setting, agencies can negotiate shared services using common views. Policy change can be mapped to operational impact quickly. Procurement documents reflect target architecture constraints without freezing design prematurely.
The anti-signs are equally obvious: annual architecture refreshes disconnected from programs, diagrams rebuilt for every steering committee, no one able to explain what is baseline versus target versus aspiration.
That is not immaturity in some abstract sense. It is an architecture practice that has lost operational legitimacy.
Final thought
TOGAF and ArchiMate are not a package deal. They are a disciplined partnership.
TOGAF should shape the architectural work, not suffocate it. ArchiMate should clarify meaning, not drown stakeholders in notation. The integration point is decision-making under change.
That is especially true in EU and government environments, where architecture earns legitimacy only when it reduces coordination failure across institutions. If the combination helps you sequence change, expose dependencies, survive political turbulence, and keep delivery aligned without pretending to a certainty you do not have, then it is working.
If not, it is ceremony.
And ceremony is already abundant.
Perfection is not the objective. Usefulness under institutional pressure is.
Frequently Asked Questions
What is TOGAF used for?
TOGAF provides a structured approach to developing, governing, and managing enterprise architecture. Its ADM guides architects through phases from vision through business, information systems, and technology architecture to migration planning and governance.
What is the difference between TOGAF and ArchiMate?
TOGAF is a process framework defining how to develop and govern architecture. ArchiMate is a modelling language defining how to represent architecture. They work together: TOGAF provides the method, ArchiMate provides the notation.
Is TOGAF certification worth it?
Yes — TOGAF Foundation and Practitioner are widely recognised, especially in consulting, financial services, and government. Combined with ArchiMate and Sparx EA skills, it significantly strengthens an enterprise architect's profile.