⏱ 21 min read
I remember that meeting clearly, mostly because everyone walked out of it convinced it had gone well.
That was the real problem.
It was a cross-institution architecture review tied to a major banking transformation programme. Four streams had been brought into one workshop because the executives wanted, as they put it, “a single view”: core banking modernization, payments compliance change, customer onboarding redesign, and a data platform uplift. Perfectly sensible on paper. In reality, we had half a dozen architects, several delivery leads, a couple of risk people, and a room full of diagrams that all looked polished, all looked professional, and all meant slightly different things.
One architect presented a “business capability” view that was, in truth, a process hierarchy. Another showed application cooperation as though systems were simply passing sequential process steps to one another. A third mixed technology nodes with vendor product names, and before long the discussion had drifted from architecture into procurement without anyone really noticing. Relationships were inconsistent. Sometimes missing altogether. Sometimes replaced with association because, if we are honest, association is often the lazy refuge of the tired modeler.
The executives concluded there was broad alignment.
There was not.
Delivery teams left with contradictory interpretations of the same target state. The repository looked impressive, but the content had become visually mature and analytically weak. You could admire it. You could not rely on it. TOGAF roadmap template
That, at least in my experience, is the point where standards stop being a theoretical nice-to-have. ArchiMate standards are not mainly about notation policing. They are about creating decision-grade architectural communication at scale. If models cannot support real decisions consistently, then the organization does not really have an architecture language. It has drawing habits. ArchiMate training
Why large teams make this worse
I have seen some version of this in banks, insurers, and EU institutional environments more times than I would like to admit. The pattern is remarkably consistent. Small architecture teams can survive a surprising amount of inconsistency because people compensate through conversation. They know each other. They know what someone “usually means.” They smooth over ambiguity socially. ArchiMate in TOGAF
Large teams cannot do that.
In big organizations, inconsistency compounds quietly. You have federated architecture functions. Internal staff mixed with external suppliers. Multilingual teams. Different modeling backgrounds. Tool migrations halfway through a programme. Parallel delivery streams moving too fast to stop and align properly. Somebody is still using Visio. Somebody else exports PNGs from a repository tool. A consulting partner arrives with one interpretation of ArchiMate, an internal architect brings another, and both assume they are being rigorous. ArchiMate modeling guide
Banking is close to the perfect stress test for this.
The domain has regulatory scrutiny, long-lived applications, ugly process overlap, and endless dependency chains. Product, process, channel, data, and control concerns intersect constantly. Shared platforms matter. Third parties matter. Identity and access management matters. Kafka event flows matter. Resilience and operational risk matter. You simply cannot afford diagrams that mean one thing in the payments programme and something subtly different in lending.
To be fair, not all variation is harmful. Stylistic variation is mostly harmless. One architect likes left-to-right layouts, another prefers top-down decomposition. Fine. One person uses more color than I personally would tolerate. Also fine.
Semantic inconsistency is different.
If two diagrams that claim to answer the same architectural question cannot do so consistently, then you do not have standards. That is the test I tend to use. Not whether everyone follows every line of the specification to the letter. Whether the models answer the same question, in the same way, across teams.
That is a harder standard.
It is also the only one I have found genuinely useful.
The wrong place most organizations start
Usually, someone says: we need standards.
And usually, what appears three weeks later is a 70-page modeling guideline.
I say that with affection, because I have helped write some of those documents myself in my less practical years.
They nearly always contain the same ingredients: ArchiMate layer definitions copied from training material, a color palette, naming conventions with no enforcement mechanism, generic examples involving “Order Handling” or “Customer Service,” and an appendix no one ever reads. It all looks responsible. It gives the architecture office a sense of progress. ArchiMate tutorial
Then almost nothing changes.
Why? Because the standards pack is too abstract, too complete too early, disconnected from governance, and ownerless the moment it is published. It lives in SharePoint or Confluence, which is often where standards go to be admired and ignored.
I worked with one architecture office that issued exactly this kind of package. The project architects nodded politely, then carried on using PowerPoint exports and local conventions because that was how design reviews actually worked. The standards had no teeth in reviews, no embodiment in the tool, and no coaching around the hard semantic judgments. So the PDF existed, and the real practice continued somewhere else.
That lesson is worth stating plainly: standards that are not embedded into review, tooling, and coaching are only documentation.
Documentation helps.
It is not enough.
Start with decisions, not notation
The real starting point is much less glamorous.
Before you define element usage, decide what decisions the models need to support.
That sounds obvious, but very few teams actually begin there. They start with language features instead of decision needs. ArchiMate gives them a rich set of concepts, so they try to tame the language before deciding what they need from it. In enterprise practice, that is backwards.
In a large bank, the recurring decisions are usually fairly clear:
- application rationalization
- outsourcing impact assessment
- regulatory traceability
- capability investment prioritization
- dependency and transition planning
- resilience and operational risk review
Each of those needs different model reliability.
For a payments architecture review, for example, one team I worked with needed to trace a process step through supporting application service, underlying application component, critical data object, and hosting or environment dependency. Not because anyone was trying to “complete the metamodel.” Because a compliance change touched PSD2 controls, message handling, IAM integration, and event propagation over Kafka, and the bank genuinely needed to know where the blast radius was.
That is a standards problem, but not in the narrow notation sense.
If one model treats “Payment Validation” as a business process and another as an application service, while a third just labels it as a box in an integration diagram, then impact analysis becomes interpretive theater. People fill the gaps with confidence and hindsight. That is dangerous.
Use-case-led standards work better because they answer the silent question every architect has: what is this model for?
If the answer is vague, the model will drift.
Mortgage origination: one domain, three meanings
Let me anchor this in a familiar banking example: mortgage origination.
It is a good test case because it cuts across channels, products, controls, integration, manual work, and downstream servicing. You have customer onboarding, credit scoring, document verification, underwriting exceptions, and servicing setup. You probably also have CRM involved, some workflow tooling, a document service, one or more decision engines, and a core banking platform that everyone describes differently depending on the day.
And that is exactly the issue.
I have seen “Mortgage Origination” represented as a capability in one diagram, a process in another, and a product in a third. Not because people were careless. Usually they were not. They were each modeling from their own immediate perspective, and no local semantic convention had settled the matter.
Likewise “CRM.” One team modeled it as an application component. Sensible. Another modeled it as a technology node because they were really thinking about the SaaS environment hosting it. A third drew the vendor logo and called it done.
“Customer Data” was even worse. Sometimes a data object, sometimes a business object, sometimes just a floating label attached to arrows that meant everything and nothing.
This is where standards become easier to sell. Not when you present them as purity, but when you show visible confusion in a domain the architects all know well.
People accept discipline much faster when they have already felt the cost of ambiguity.
Build the minimum viable modeling standard
My advice here is opinionated: start narrower than people expect.
Almost every organization wants to build the perfect standard. They want complete coverage. Every layer, every element, every nuance, every exception category. It feels thorough. It is also one of the fastest ways to produce something no one can operationalize.
Instead, build a minimum viable modeling standard.
That means defining the first scope deliberately:
- approved viewpoints
- approved element usage rules
- approved relationship usage rules
- naming patterns
- mandatory metadata
- review and exception process
That’s it.
In practice, I like to begin with maybe 8 to 12 recurring viewpoints, a controlled subset of element types, explicit do/don’t examples, and one-page cheat sheets per viewpoint. Not glamorous. Very effective.
Some architects will complain this is reductive. In a narrow sense, they are right. It is reductive. But usability matters more than theoretical completeness at the start. In enterprise settings, a standard that 70% of the team can actually apply well is far more valuable than an elegant standard only 10% can interpret consistently.
Here is the kind of structure teams actually need:
That table is boring in exactly the right way. Standards should reduce ambiguity, not impress people.
Standardize viewpoints first
If I had to choose one thing to standardize before all others, it would be viewpoints.
Not colors. Not line thickness. Viewpoints.
This gets underestimated constantly. In enterprise practice, people do not need infinite modeling freedom. They need a finite set of reliable views that answer specific questions for specific audiences. Once those become stable, the rest gets easier.
A practical viewpoint set for a large bank might include:
- capability-to-application mapping
- business process support view
- application cooperation or dependency view
- data object flow view
- transition architecture roadmap view
- technology deployment view
- regulatory traceability view
For each of these, define four things:
- Who the target audience is
- What mandatory element types are in scope
- What shortcuts are forbidden
- What question the view must answer
That fourth item matters most.
For example, an application cooperation view might answer: which application components or services depend on each other to execute mortgage origination, and where are the critical integration dependencies? In that view, using business process arrows to imply technical interaction should simply be disallowed. If event streaming matters, show Kafka as a technology service or platform dependency in the relevant view, not as decorative middleware wallpaper.
One architecture office I worked with allowed “hybrid views” with almost no constraints because they wanted to encourage flexibility. Within a year, the repository was full of one-off diagrams no one could compare. Every architect had their own house style. Every review began with twenty minutes of translation.
That is not freedom.
It is friction.
Here’s a simplified example of how viewpoint discipline starts to help.
Not perfect ArchiMate notation in mermaid terms, obviously. But it is enough to illustrate the point: the model is useful because each object has a defined role in the question being asked.
Local semantics: the uncomfortable but necessary part
ArchiMate gives formal structure. It does not remove the need for local interpretation.
This is where teams often get uneasy because local semantic conventions feel like “inventing our own ArchiMate.” They are not. They are clarifying how the enterprise will use the language consistently.
You need to settle things such as:
- what counts as an application component in your repository
- when to use business service versus business process
- how to distinguish business object, data object, and representation
- whether interfaces are modeled routinely or only when decision-relevant
- how SaaS platforms and shared services are represented
- how IAM capabilities and services are decomposed across business and technology layers
Take “SEPA Payment Processing.” Is it a business service, an application service, or just a capability label? The answer could vary by context, but your standard must tell people what the default interpretation is and when exceptions apply.
Take “Core Banking Platform.” Is that a product name? A grouping of application components? A technology concept? If one team uses it to mean Temenos as a vendor package, another to mean the bank’s logical ledger and product servicing estate, and a third to mean the runtime platform in the cloud, everyone can remain notation-compliant while still disagreeing profoundly.
That kind of disagreement is more dangerous because it hides behind apparent professionalism.
A mistake I see often: over-modeling into irrelevance
There is another failure mode worth talking about because it is common in large institutions: over-modeling.
An enterprise team decides to do standards properly and starts capturing everything. Every interface. Every process variation. Every environment. Every ownership field. Every lifecycle attribute. Separate objects for every API, every queue, every IAM role set, every deployment nuance across dev, test, pre-prod, and production.
For a while it looks impressive.
Then maintenance collapses.
Project architects stop trusting repository freshness because updating it becomes a second job. Diagrams become snapshots of past intentions. Review boards quietly revert to PowerPoint packs because at least those represent what the team thinks today, even if they are structurally weaker.
This is not a tooling problem first. It is a standards problem. The standard is demanding more detail than the operating model can sustain.
My correction is usually simple:
- separate core repository facts from contextual diagram detail
- make some metadata mandatory and other fields optional by use case
- archive stale content aggressively
- stop pretending every object needs the same depth of documentation
In large enterprises, model freshness beats theoretical completeness almost every time. I would rather have a lean repository that is trusted than a rich one everyone suspects.
How standards survive mixed teams
Now we move from method to operating model, which is where most standardization efforts either stick or die.
Large teams are messy. You have experienced domain architects, junior analysts, contractors trained in different toolsets, suppliers who will do exactly what the statement of work requires and not a gram more, and delivery pressure that rewards shortcuts. Telling this population to “follow the standard” is not a rollout plan.
A working adoption mechanism usually includes a few practical things:
- model clinics
- office hours
- lightweight peer review
- embedded exemplars in the tool
- starter templates for each approved viewpoint
- domain champions or model stewards
Training helps, but training alone is not enough. It never is.
If standards compliance depends on people remembering a PDF, the rollout is already failing.
I like model clinics because they turn standards from abstract rules into judgment in practice. Someone brings a mortgage origination support view, and the conversation becomes concrete: should “Document Verification” be shown as an application service here, or is the underlying component what matters for the review? Do we need the IAM dependency in this view because access control is part of the decision, or are we cluttering the picture? Does the Kafka dependency matter to operational resilience, or is it incidental in this case?
That kind of coaching builds consistency faster than any slide deck I have ever seen.
Governance, but not the theatrical kind
Architecture people hear “governance” and often imagine delay, bureaucracy, and committees pretending to be control mechanisms.
Useful governance is smaller than that.
You need a central standards owner. Domain-level model stewards. A repository librarian or tool administrator who actually understands the metamodel. And architecture review boards that use the standards in real checkpoints rather than praising them in principle.
Reviews should focus on:
- semantic correctness
- viewpoint appropriateness
- traceability completeness where required
- naming and metadata sufficiency
They should not escalate minor layout choices or temporary gaps during early exploration. That is where governance turns into theater.
One bank I advised required formal board approval for every notation deviation. Predictably, architects bypassed the repository entirely when delivery pressure increased. The standards became stricter on paper and weaker in reality.
The better pattern is lightweight control with visible exceptions.
Tooling matters more than people admit
Repository tooling quietly determines whether standards live or die.
If the tool makes it easy to do the wrong thing, people will do the wrong thing, especially under programme pressure. If viewpoint templates are awkward, if reusable objects are hard to find, if naming is unconstrained, if relationship misuse is frictionless, then your standards are operating against the grain.
Tool configuration should reinforce the essentials:
- viewpoint templates
- relationship constraints where feasible
- naming validation
- metadata picklists
- reusable object definitions
- duplicate detection
But there is a trap here too: over-customizing the tool until no one understands how it works.
I would not start there.
Enforce only the rules that matter most. Make the right way the easiest way. Leave some flexibility where the cost of enforcement exceeds the value of consistency.
I have seen M&A integration teams continue using Visio while the enterprise architecture team used a metamodel-based repository tool. The result was predictable: the same acquired applications appeared under multiple identities, with slightly different names, owners, and boundaries. By the time anyone noticed, rationalization discussions were polluted by duplicate objects masquerading as separate assets.
That is not just untidy modeling.
It affects investment decisions.
Exemplars beat theory
Written standards help. Canonical examples help more.
In large teams, people adopt patterns faster when they can copy a credible model and adapt it responsibly. That has been true in every serious architecture transformation I have worked on.
Good exemplar candidates in banking are easy to find:
- mortgage origination
- instant payments processing
- anti-money laundering case handling
- customer master data propagation
Each exemplar should show:
- the approved viewpoint
- why those element types were selected
- why those relationships were chosen
- how naming conventions were applied
- what was intentionally left out
That last point is underrated. Teams need permission not to model everything.
A decent exemplar says, in effect: this is enough for this decision.
Exceptions without collapse
Not every architecture question fits the default pattern, and pretending otherwise creates rebellion.
You need a fast, visible exception process.
Some exceptions are entirely legitimate: an integration-heavy transformation may need more interface detail than usual; an operational resilience assessment may need stronger infrastructure emphasis; a temporary programme may require a decomposition that the enterprise repository would not keep long term.
Other exceptions are not legitimate. “The project architect prefers BPMN-style arrows” is not a reason. Neither is “the sponsor likes one big picture.”
The key is to make exceptions easy to request, quick to assess, and visible enough that good exceptions can be harvested back into the standard later. If three programmes need the same additional pattern, maybe that pattern belongs in the next standard revision.
That is how standards evolve without dissolving.
Measure the right things
Most architecture metrics are vanity metrics in a suit.
Number of diagrams produced tells you almost nothing. So does number of repository objects, unless your ambition is to inventory confusion at scale.
Better indicators are more operational:
- percentage of models using approved viewpoints
- relationship misuse rate in reviews
- duplicate application objects in the repository
- architecture review cycle time
- reuse of existing model elements
- stakeholder comprehension feedback
In banking, you can tie this more directly to outcomes:
- faster impact assessment for regulatory change
- cleaner application ownership discussions
- reduced disagreement in target-state planning
- fewer duplicate integration designs across programmes
One subtle but important sign of progress is this: fewer arguments about basic meaning. Not fewer disagreements overall. Healthy architecture work still has disagreements. But they move up a level. People argue about strategy, trade-offs, sequencing, and risk. Not about whether a box means a capability, a process, or a system.
That is genuine maturity.
Back to mortgage origination, six months later
Let’s return to the earlier example.
Before standards, “Mortgage Origination” floated between capability, process, and product depending on the presenter. “CRM” meant an application, a vendor, or a platform. “Customer Data” was whatever the diagram needed it to be.
After a sensible standards rollout, the picture changed.
The capability map used stable capability definitions consistently. Mortgage Origination Capability sat where it should, distinct from the business processes that realized work within it. The process support view linked onboarding and underwriting steps to application services, not to a random assortment of products and technical boxes. The application cooperation view showed dependencies between CRM, credit engine, document verification service, and core banking components clearly enough to support modernization sequencing. The transition roadmap distinguished current-state packages from target-state building blocks, so the programme stopped pretending all replacement decisions were immediate.
Something like this:
Again, simplified. But the difference is not aesthetic.
It is operational.
The bank could see where digital onboarding overlapped with branch-led processing. It could rationalize duplicate services. It could sequence CRM changes separately from underwriting engine modernization. Executive reporting became more credible because the views were comparable across domains.
And that is the point worth remembering: the goal was never prettier diagrams. It was better decisions with less rework.
What people will resist
They will say it is too restrictive.
They will say their domain is different.
They will say ArchiMate is already complex enough, and now you are adding local rules on top.
They will say they do not have time.
They will say executives do not care about notation.
Some of those objections are reasonable. Some are territorial.
The response is not to lecture people on standards hygiene. It is to connect the standards to actual pain: review confusion, duplicate objects, contradictory target-state interpretations, wasted impact analysis, repository distrust. Show where consistency removes work rather than adding it.
Also, be honest. A standard should evolve. If a domain genuinely has needs the initial standard cannot handle well, make room for controlled adaptation. But make the burden of proof real. “Our domain is different” is often true in detail and false in principle.
And yes, executives usually do not care about notation. They care about whether the architecture team gives them dependable answers. Standards matter because dependable answers require shared meaning.
The meeting I would rather have now
I sometimes think back to that opening workshop and imagine the same session six months later, after a proper standards effort had taken root.
The diagrams would not all look identical. Nor should they.
But they would be comparable. A business capability view would actually mean a business capability view. An application cooperation model would show dependencies, not disguised process choreography. Vendor names would not be smuggled in as architecture structure. The repository would be a working asset, not compliance furniture.
Disagreements would still happen, but at the right level. People would argue about whether to retire the legacy onboarding workflow before or after the new IAM integration lands in the cloud. They would debate whether Kafka should remain the event backbone for underwriting decisions or whether some interactions need tighter synchronous control. They would question whether the servicing setup belongs in the same transition increment as customer master data remediation.
Those are good arguments.
That is architecture doing its job.
Establishing ArchiMate standards across a large team is less about enforcing purity than about creating a shared professional language. In banking, and frankly in most regulated or institutionally complex environments, that language matters because complexity compounds quietly until it blocks change. By the time the problem is visible to executives, the cost is already high.
So start smaller than you think. Tie the standard to decisions. Standardize viewpoints. Clarify local semantics. Use exemplars. Keep governance light but real. Configure the tool just enough to help. And do not mistake a published guideline for an adopted practice.
The team does not need perfect ArchiMate.
It needs models people can trust.
Frequently Asked Questions
What is enterprise architecture?
Enterprise architecture aligns strategy, business processes, applications, and technology. Using frameworks like TOGAF and languages like ArchiMate, it provides a structured view of how the enterprise operates and must change.
How does ArchiMate support enterprise architecture?
ArchiMate connects strategy, business operations, applications, and technology in one coherent model. It enables traceability from strategic goals through capabilities and application services to technology infrastructure.
What tools support enterprise architecture modeling?
The main tools are Sparx Enterprise Architect (ArchiMate, UML, BPMN, SysML), Archi (free, ArchiMate-only), and BiZZdesign. Sparx EA is the most feature-rich, supporting concurrent repositories, automation, and Jira integration.