⏱ 25 min read
I’ve seen this play out more than once.
A government architecture repository is packed with polished diagrams. Color-coded. Neatly layered. Every box lined up just so. The ArchiMate notation is technically sound, the tool metadata is pristine, and yet the moment a real integration decision needs to be made — whether to expose a shared eligibility service, where an API gateway should sit, how citizen identity should work across agencies, who actually owns the audit trail — nobody opens those diagrams.
They go back to whiteboards. Or spreadsheets. Or, worse, whatever people happen to remember.
That’s the failure.
And to be fair, it usually isn’t ArchiMate itself. ArchiMate is more than capable of expressing useful enterprise architecture views. The issue is almost always more human than technical: the wrong viewpoint for the wrong question, notation modeled far beyond what anyone needs, diagrams trying to satisfy every audience at once, and almost no honest link between policy intent and the messy operating reality of cross-agency integration.
Government tends to amplify the problem. Policy is often shaped in one place, budget sits somewhere else, platforms are owned elsewhere again, and operational accountability is spread across agencies that share data more readily than they share incentives. So teams compensate by producing “enterprise overviews” that try to show everything. Which, in practice, means they explain very little.
This article is not a notation tutorial. You do not need another walk-through of ArchiMate layers, symbols, and relationship types. ArchiMate training
What you probably need — especially if you’re leading integration architecture in or around government — is a set of views that actually help you steer delivery, governance, platform decisions, privacy review, and modernization tradeoffs. So I’m going to start where things usually go wrong, then use those failures to introduce 10 concrete diagram types that are genuinely useful in public-sector integration work.
These are not abstract classroom examples. They’re grounded in citizen identity, tax, benefits, grants, notifications, civil registration, and hybrid legacy coexistence. And for each view I’ll stay focused on the same practical questions: the mistake that usually comes first, what the view should show, where it helps, and how to model it without turning it into decorative wallpaper.
The first mistake: trying to answer every question with one diagram
The most common ArchiMate anti-pattern is the giant “enterprise overview.” ArchiMate modeling guide
You know the one. Business actors, capabilities, processes, application components, application services, interfaces, devices, nodes, projects, plateaus, and maybe a hopeful cloud icon or two, all squeezed onto a single page. From a distance it looks comprehensive. The second someone asks a real question, it becomes useless.
Government teams fall into this trap for understandable reasons. There are simply too many stakeholders. Executives want visibility of transformation. Security teams want trust and control boundaries. Delivery teams want cooperation scenarios. Data teams want ownership and movement. Operations wants deployment reality. Funding boards want transition states. And because architecture teams are under pressure to demonstrate joined-up thinking, they often try to serve all of those audiences with one artifact.
That never really works.
Policy and implementation are often separated by agency boundaries. Funding lines distort the conversation. Shared platforms create ownership ambiguity. Legacy systems force compromises nobody is especially eager to admit. One diagram cannot hold all of that well. TOGAF roadmap template
Good ArchiMate work is not about building the most complete model. It’s about selecting purpose-built views that help a specific decision get made.
That’s the frame for the 10 views below. Not a rigid framework. A practical working set.
Quick reference: the 10 views and when to use them
If I were setting up a government integration repository from scratch, I wouldn’t insist every initiative maintain all 10. Usually 3 to 5 is enough. But I would standardize the view types. In practice, that consistency matters more than many teams expect.
Diagram 1 — Service Context View
The first mistake is surprisingly basic: teams model the internal application estate before agreeing what the service actually is.
“Citizen portal” gets treated as the service, when it is really only a channel. Or a case system gets treated as the service, when the actual service is eligibility determination, identity verification, or payment status provision. I’ve watched programs spend months discussing internal components without first agreeing what they are exposing, who depends on it, and which external platforms can block delivery.
A good Service Context View is sparse on purpose. It should show the core business service or application service in scope, the external business actors and application services around it, the upstream and downstream dependencies, key channels, consuming agencies, and any critical shared or sovereign platforms.
For a Citizen Identity Verification Service, for example, I’d show licensing, social services, and tax as consuming agencies or consumer groups; a national identity registry upstream; a fraud screening service; an audit service; a notification platform; and maybe a boundary around the initiative if the service is being delivered as part of a broader identity modernization program.
That sounds obvious. But it changes the conversation immediately. Instead of “we’re building a portal feature,” the discussion becomes “we’re standing up a reusable verification service with dependencies on national identity, fraud, and audit; the portal is simply one consumer.” That shift is huge for ownership, funding, non-functional requirements, and integration prioritization.
For an integration lead, this view is one of the best early warning tools you have. It surfaces hidden dependencies before they turn into blockers. It clarifies whether you’re delivering a shared service or just a point integration. It also flushes out political realities early: who owns the upstream registry, who pays for fraud checks, whether audit is agency-specific or cross-government, whether notification is optional or mandated.
A common modeling error here is drifting into process flow. Don’t. This is not the place to show a citizen journey in detail. Use services, actors, interfaces, and dependency relationships deliberately. Annotate what is external, shared, agency-owned, sovereign-hosted, or policy-constrained. In government settings, that extra labeling often matters more than adding another dozen ArchiMate elements. ArchiMate tutorial
Diagram 2 — Application Cooperation View
A more technical mistake usually comes next.
Integration teams jump straight to middleware diagrams. They draw the ESB, the API gateway, Kafka topics, queues, brokers, connectors, managed cloud integration services, and maybe a few arrows with protocol labels. But they never clearly model which applications are actually cooperating and why.
That leaves delivery teams with infrastructure pictures, not architecture.
An Application Cooperation View should show the participating applications or major application components, the interaction paths between them, the key service interfaces, and the broad shape of coordination — direct exchange, brokered interaction, orchestration, or asynchronous eventing. It should also make major dependency relationships visible.
Take a government scenario involving a tax platform, identity provider, payment engine, compliance case system, and document management repository. A citizen submits a payment-related correction. Identity is checked through a shared IAM platform. A case is opened in compliance. Payment status is retrieved from a finance engine. Correspondence is archived in a repository. Maybe a notification service confirms receipt.
That is the cooperation scenario. Start there.
One useful discipline is deciding where to stop before the view collapses into sequence-level detail. In my experience, if you’re showing every request, callback, error path, and topic name, you’ve gone too far for an enterprise architecture view. Save that for solution design or interface specifications. The cooperation view should answer: which systems need to work together, through what kind of interaction, and where are the brittle dependencies?
This is also where shared platforms need careful treatment. If you place an API gateway in the center of the picture, people often infer ownership it doesn’t actually have. Same for IAM. Same for enterprise Kafka. Sometimes the platform is an enablement layer, not the owner of the service interaction. Be explicit about that.
A lot of teams ask whether to show the API gateway every time. My answer is simple: only if it matters to the decision. If the question is consumer onboarding, policy enforcement, throttling, or exposure pattern, yes. If it is just a transparent routing layer and not structurally relevant, leave it out.
Practical advice? One cooperation view per scenario is usually better than one giant estate-wide interaction map. Highlight unstable interfaces. I often mark synchronous dependencies with a note or a visual treatment because they become operational pain points later. And, in fairness, this is often the first ArchiMate diagram delivery teams actually trust, because it maps to work they recognize.
A blunt note on notation abuse
A short detour, because this needs saying.
Just because the tool supports every ArchiMate relationship does not mean your diagram should use them all. If a view needs a legend, a training session, and a patient architect standing beside it to explain what the colors mean, you have already lost half your audience.
I’ve seen application functions modeled where services were clearly intended. Capabilities confused with processes. Colors carrying undocumented semantics. Technology nodes mixed with conceptual platforms in ways that implied deployment certainty nobody actually had. It makes architecture look clever and unhelpful at the same time.
Enterprise teams lose credibility quickly when diagrams need an interpreter.
The better views are decision-support diagrams, not notation showcases.
Diagram 3 — Data Object Flow View
Government architecture has a bad habit of under-modeling data movement until privacy review begins. Then suddenly everyone is arguing about ownership, lawful basis, data minimization, retention, and cross-agency sharing — long after the integration design has started to harden.
That is avoidable.
A Data Object Flow View should show the key data objects, where they are created, updated, consumed, and stored, and where they cross agency or system boundaries. You can also add classification or trust markers if they matter to the audience.
For a benefits scenario involving personal profile, eligibility status, household composition, payment instruction, and audit record, I’d show social services, the employment agency, and a payments authority exchanging those objects across a determination process. I would make system of record versus system of use explicit. I would also show where data is replicated, transformed, or staged.
That last part matters because canonical data models are often fiction. Useful fiction sometimes, but fiction nonetheless. In government, each agency usually has just enough statutory, operational, or historical difference to break the fantasy of a perfectly shared semantic model. If your diagram suggests canonical harmony where there is really translation logic, you’re not helping.
This view is excellent for privacy impact assessments, data governance discussions, and integration challenge sessions. It exposes duplication. It makes batch extracts harder to justify. It helps data architects and integration leads have a serious conversation about whether a file feed exists because it is truly necessary or simply because ownership politics made direct service integration uncomfortable.
A practical modeling rule: do not model every field. Nobody benefits. Use business objects when the audience is policy-heavy and the language needs to stay close to operational meaning. Use data objects when system handling and interface treatment matter. And explicitly note trust level, sensitivity, and retention if those shape architecture decisions.
Here’s a simple sketch of how a data flow conversation might look:
Not sophisticated. But honestly, even a simple view like that, used consistently, is often more useful than a dense repository export.
Diagram 4 — Security and Trust View
Security is too often bolted onto integration diagrams as labels: “OAuth here,” “TLS there,” “encryption at rest,” “MFA for staff.” That is not architecture. That is annotation without structure.
A Security and Trust View should show trust zones, identity providers, access paths, security services, audit and logging dependencies, external federated parties, and the crossings that are genuinely sensitive.
For federated identity in online citizen services, I’d typically show a national digital identity provider, agency-specific authorization services, internal staff access paths, a third-party payment provider if one is in scope, and the audit retention service. I’d also separate citizen authentication from agency authorization, and machine-to-machine trust from workforce access, because they almost never have the same controls or lifecycle.
This view is where a lot of integration programs discover they’ve made dangerous assumptions. Shared identity does not mean shared authorization. A citizen authenticated through a national ID service may still need agency-specific entitlement checks. A service account used for Kafka event publication is not the same thing as a workforce identity accessing a case system. And when third-party providers enter the picture, trust boundaries get political very quickly.
From an integration lead’s point of view, this is often the difference between a service that clears security review in a reasonable timeframe and one that disappears into months of challenge and redesign. In government especially, agencies may consume the same IAM platform but maintain separate policy enforcement points, separate audit retention obligations, and separate incident accountability.
Use boundaries aggressively. Annotate trust assumptions directly. If you are relying on token propagation across a trust boundary, say so. If machine credentials terminate at the gateway and internal service identity is re-issued, show it. Don’t make reviewers guess.
Diagram 5 — Cross-Agency Value Stream View
Some integration leaders avoid value stream views because they sound too business-oriented, or because they’ve only seen them used as executive wallpaper.
That’s a mistake. In government, this is one of the most strategically useful views you can maintain.
A Cross-Agency Value Stream View shows the stages of value delivery across organizational boundaries, the participants involved, the supporting services and application enablement, and the handoffs where experience or data quality starts to break down.
The classic public-sector example is birth registration to benefits activation. A hospital event is captured. Civil registration is updated. An identity record is established. Eligibility checks are triggered. A citizen is notified. Depending on jurisdiction, health, registration, identity, and benefits may all sit in different agencies or at different levels of government.
If you only model system interactions, you will miss the real design problem. Many so-called integration failures are actually handoff design failures. No one agreed when the event becomes authoritative. No one agreed who owns data correction. No one aligned on whether notification should occur before downstream confirmation. No one addressed what happens when one agency updates overnight and another expects near real-time signals.
That is value stream territory.
This view is also useful when building funding cases, because it crosses departmental silos and reframes integration around citizen outcomes. It helps architecture teams identify where reusable services make sense and where event-driven patterns are worth introducing later.
Keep process detail light. Focus on value stages and enabling services. The point is not BPMN precision. The point is to reveal where the architecture is fighting the service outcome.
Diagram 6 — Interface and API Exposure View
An API inventory is not an architecture view.
I’ll die on that hill.
An inventory tells you what exists. It does not tell you what should be exposed, to whom, under which policies, through which control points, with what lifecycle implications, and whether the interface represents a genuinely reusable service or just a legacy wrapper with better branding.
An Interface and API Exposure View should show externally exposed services or interfaces, consumer groups, the role of the API gateway or management platform, policy constraints, lifecycle status, and often the split between internal and external exposure.
Take a National Notification API used across justice, transport, health, and local government. It may expose email, SMS, and letter dispatch capabilities, but with policy-based restrictions on message content, recipient data, retention, and auditability. Some agencies may only be allowed to send templated transactional messages. Others may require additional approval workflows. Some consumers may use modern REST interfaces, while a legacy batch facade still exists behind the scenes.
That belongs in the view.
This diagram matters because it lets integration teams discuss reusability without pretending every interface is reusable. It shows who is really coupled to what. It helps platform governance boards prioritize versioning, onboarding, deprecation, and mandatory standards. It also makes it much easier to talk about facades. If the API is fronting a 20-year-old messaging engine and everyone knows it, model that honestly. Don’t imply cloud-native purity where none exists.
Model consumers as meaningful groups, not every single application logo. Indicate mandatory standards: auth model, payload expectations, throttling, audit, onboarding controls. And if IAM or API management is relevant to the decision, include it. If not, don’t force it in.
Diagram 7 — Business Capability to Service View
A lot of architecture teams say they are capability-driven and then produce capability maps completely disconnected from integration design. That gap is one reason business leaders roll their eyes at enterprise architecture.
A proper Business Capability to Service View links business capabilities to the business or application services that enable them, and sometimes overlays ownership, maturity, or fragility.
For grants administration, you might model capabilities such as applicant intake, eligibility assessment, disbursement, compliance monitoring, and appeals handling. Then link those to the services and systems that actually support them: applicant identity verification, document intake, rules evaluation, payment execution, case management, notification, audit, and reporting.
Why should an integration lead care? Because capability weakness often hides service fragmentation. A capability may look healthy on a strategy heatmap while, in practice, it relies on brittle batch exchanges, manual reconciliation, duplicate data entry, and a chain of agency-specific interfaces that nobody wants to fund properly. This view gives you a business-grounded way to argue for shared services and modernization investment.
It is also useful when the budget committee does not care in the slightest about middleware modernization. They may, however, care very much that appeals handling is delayed because compliance evidence retrieval depends on three separate legacy integrations and a nightly extract.
Don’t overload this view with every application component in existence. Use heatmaps carefully; they are often overdone and underexplained. I prefer calling out capabilities that rely on batch exchange, manual handoff, or unstable service exposure. That makes the architecture argument more concrete.
Diagram 8 — Integration Pattern View
This is one of the most useful real-world views and one of the least consistently modeled.
Too many integration discussions happen in vendor language: ESB, iPaaS, Kafka, API management, service mesh, event broker. The pattern choices stay implicit, so different teams solve similar problems in incompatible ways.
An Integration Pattern View should show the integration style used in a scenario — event-driven, orchestration, request-response, file transfer, publish-subscribe — along with mediators, transformation points, routing logic, event brokers, and the location of coupling and failure modes.
For case management modernization, imagine that a citizen status change emits an event. Downstream benefits, notifications, and audit services react asynchronously. But a legacy platform still requires a nightly file extract because it cannot consume events directly. Maybe one policy service still sits behind a synchronous API because an immediate decision is legally required.
That coexistence is the architecture. Not the vendor product list.
This view bridges enterprise architecture and engineering design in a way few others do. It surfaces modernization tradeoffs. It helps review boards challenge assumptions like “everything should be event-driven” or “we’ll orchestrate centrally because it’s simpler.” Usually it isn’t simpler. It just hides coupling in a different place.
A few anti-patterns are worth calling out directly:
- central orchestration for everything
- hidden data transformation in middleware
- event publication without clear data ownership
- using Kafka as a substitute for service design
- pretending file transfer is temporary when everyone knows it will live for five years
Show the pattern, not every technical instance. You do not need every topic, queue, and connector. You do need to show where failure propagates, where transformations occur, and where ownership sits.
Simple again. But enough to have a serious conversation.
Diagram 9 — Technology Deployment View
Enterprise architects sometimes stay abstract for too long. Then reality arrives late in the form of network segmentation, sovereign hosting rules, cloud tenancy restrictions, latency issues, resilience gaps, or unpleasant truths about what cannot sit where.
A Technology Deployment View should show nodes, environments, deployment locations, platform services, runtime placement of applications and integration components, trust or network boundaries, and critical external dependencies.
For a hybrid cloud citizen services platform, that may mean a public web front end in cloud, integration services in a protected zone, a legacy records system on-premises, an audit archive in sovereign hosting, an external SMS gateway, and perhaps managed Kafka or API management in a government-approved landing zone. If IAM spans multiple zones, show that too.
This view matters more than some strategy teams admit. Many integration defects are really deployment-reality defects. Gateways placed in the wrong zone. Broker clusters inaccessible from protected workloads. IAM token introspection crossing an unnecessary boundary. Latency between cloud-hosted orchestration and on-prem systems that turns synchronous calls into operational pain.
As an integration lead, this is the view you need when platform teams say “that service can run anywhere” and security says “no, not there.” It is also where resilience planning gets concrete: active-active or active-passive, dependency on external DNS, queue durability, failover of API endpoints, and logging paths that still function during partial outages.
Don’t pretend all deployments are final. Mark transitional hosting explicitly. Include non-functional notes where they drive design. And for the love of clarity, distinguish conceptual technology services from actual deployment nodes.
Diagram 10 — Change Roadmap View
The last mistake is probably the costliest: teams produce current-state and target-state diagrams with nothing credible in between.
Government transformation rarely happens in one funding cycle. Procurement takes time. Policy changes shift scope. Legacy contracts linger. Shared platform onboarding takes longer than anyone promised. And still, architecture decks love to jump from “batch-heavy legacy estate” to “modular digital platform” as if transition architecture were somehow optional.
It isn’t.
A Change Roadmap View should show baseline, transition architectures, target state, work packages, migration dependencies, retirement of legacy interfaces, and temporary coexistence arrangements.
For a benefits modernization roadmap, a realistic progression might be:
- current state: batch-heavy legacy platform with file-based inter-agency exchange
- transition state: API facade over the legacy core, event publication for selected changes, parallel identity integration, and temporary duplicate audit handling
- target state: modular case services, shared eligibility engine, managed API exposure, event-driven updates to downstream consumers, retirement of core batch interfaces
That is governable architecture. It lets portfolio boards see what happens when. It makes integration debt visible. It acknowledges that temporary duplication may exist for years, not months. It gives security, operations, and data governance something concrete to review.
The key is honesty. Model interim architecture even when it is awkward. Show the temporary bridge, the coexistence connector, the old IAM integration that survives longer than planned, the nightly reconciliation process nobody likes but everyone depends on. If you hide those, the roadmap becomes fiction. ArchiMate in TOGAF
This is also where I like to connect roadmap steps to risk reduction and citizen impact, not just technical elegance. “Retire legacy file feed” is fine. “Reduce eligibility update lag from 24 hours to near real-time for high-priority cases” is better.
The views teams skip — and then regret skipping
In my experience, the most valuable views are often the ones teams avoid.
The Security and Trust View gets skipped because it feels specialist. The Data Object Flow View gets skipped because ownership politics are painful. The Change Roadmap View gets skipped because nobody wants to document ugly interim states. The Cross-Agency Value Stream View gets skipped because it challenges organizational boundaries and funding assumptions.
And those are exactly the reasons they matter.
The skipped views are usually the ones that surface uncomfortable truths early enough to do something about them.
Choosing the right view for the conversation you actually need
You don’t need a heavyweight method here. A practical question lens is enough.
If the real question is what are we actually in scope to deliver?, use a Service Context View.
If the question is which applications need to cooperate for this scenario?, use an Application Cooperation View.
If people are arguing about where sensitive data moves, who owns it, and where it is copied, use a Data Object Flow View.
If security review is circling around who trusts whom, where identity is asserted, and where authorization happens, use a Security and Trust View.
If executives keep calling the issue “integration” when the actual problem is poor inter-agency handoffs, bring out a Cross-Agency Value Stream View.
If platform governance wants to know what we expose and to whom, use an Interface and API Exposure View.
If investment conversations need grounding in what business weakness we are fixing, use a Business Capability to Service View.
If engineering choices are drifting into product slogans, and you need to clarify which integration style fits the scenario, use an Integration Pattern View.
If infrastructure and security are pushing back with deployment constraints, use a Technology Deployment View.
And if everyone is pretending the target state will somehow appear without chaos, use a Change Roadmap View.
Most initiatives need three to five of these, not all ten. That is normal. In fact, if you maintain all ten for every workstream, you will probably drown in low-value maintenance.
Practical modeling habits that make ArchiMate usable in government
A few habits make an outsized difference.
Start from the stakeholder decision, not the notation. If the board needs to decide whether to fund a shared notification capability, don’t hand them a generic application landscape. Build the view that supports that decision.
Model shared services explicitly. In government, shared platforms are where ownership confusion goes to breed. Be clear about who operates the platform, who owns the service, who consumes it, and who pays for change.
Distinguish agency ownership from platform operation. Those are not the same thing, and diagrams routinely blur them.
Annotate policy or legislative constraints where they shape architecture. Not everywhere. Just where they change the design. If data residency, retention, lawful basis, or mandated audit controls matter, put them on the diagram. Otherwise those constraints tend to get rediscovered in review forums at exactly the wrong time.
Show manual steps when they are architecturally significant. I know some architects hate that because it feels untidy. But if an eligibility override, compliance approval, or exception reconciliation is operationally essential, then it belongs in the architecture conversation.
Avoid fake precision in early-state models. If you do not yet know the exact deployment topology or the final event partitioning strategy, don’t imply certainty. Mark assumptions. Call out intent versus confirmed design.
Maintain one canonical view per decision, not ten almost-identical exports. Repositories are useful, but view sprawl is real.
Use names that both business and technical teams recognize. If the business says “benefit entitlement check” and the engineering team says “rules microservice,” your diagram may need both, or at least language that bridges them. Otherwise you’re modeling translation problems into the architecture itself.
And yes, repository discipline matters. Relationships should survive beyond PowerPoint. But exported views still need to stand alone in workshops and governance boards. If a view only works when opened inside the modeling tool with six layers toggled on, it isn’t doing its job.
A few short practical questions
How many ArchiMate views should one government program maintain?
Usually fewer than people think. Three to five strong views beat fifteen weak ones.
Should integration teams model APIs as application interfaces or services?
Depends on the decision. If you’re talking exposure and consumer contract, a service-oriented representation is often clearer. If you’re discussing implementation boundary or component responsibility, interfaces may be more appropriate. I’ve used both. The important thing is consistency and clarity.
How detailed should a value stream view be?
Less than a process model, more than an executive slogan. Enough to show stages, handoffs, and enabling services.
Is ArchiMate too heavy for agile delivery in government?
No. But bad ArchiMate absolutely is. Lightweight, purpose-built views work perfectly well in agile environments if they stay close to decisions and delivery reality.
Conclusion: good ArchiMate diagrams are really about honesty
Useful enterprise architecture is not produced by modeling the most things. It comes from selecting the right view for the right decision and being honest about the architecture you actually have, the dependencies you truly carry, and the constraints government delivery imposes.
That honesty matters in public-sector integration work because the environment is unforgiving: cross-agency reality, compliance pressure, legacy coexistence, shared digital platforms, procurement friction, and operational accountability that rarely sits in one neat place.
The best ArchiMate example diagrams are not the prettiest ones. They are the ones that reveal uncomfortable truths early: hidden dependencies, weak trust assumptions, duplicated data, brittle synchronous coupling, unrealistic roadmaps, and the quiet persistence of temporary architecture that is not temporary at all.
If you can standardize even four or five of these views in an integration architecture practice, architecture conversations get faster. Better too. More direct. Less theatrical.
And, in my experience, far more useful.
Frequently Asked Questions
How do you model SAP in ArchiMate?
SAP is modelled as Application Components per module (FI, MM, SD, HR). Each module exposes Application Services consumed by Business Processes. Technology Nodes represent the SAP HANA platform and hosting infrastructure.
Why model ERP landscapes in ArchiMate rather than vendor tools?
Vendor tools show the system from inside. ArchiMate shows the ERP in context — dependencies on infrastructure, integration with surrounding systems, support for business capabilities, and lifecycle within the application portfolio.
How does ArchiMate handle ERP customisation?
ERP customisations are modelled as additional Application Components or Functions within the ERP boundary. Serving relationships show which business processes depend on customised vs standard functionality — useful for upgrade impact analysis.