⏱ 5 min read
Key Takeaways
- →Executive summary
- →The regulation-to-architecture traceability matrix
- →Applying these patterns in practice
Recommended Reading
Executive summary
Risk and compliance visualization works when it answers real governance questions: where regulated data flows, what controls apply, what changes were approved, and what evidence exists. W3C PROV defines provenance as information about entities, activities, and people involved in producing data—useful as conceptual grounding for “evidence lineage.” ArchiMate for architecture governance
ArchiMate provides the cross-layer modeling language to connect drivers/requirements to capabilities and systems; regulatory frameworks like GDPR (record of processing activities requirements) and operational resilience rules like DORA (financial sector ICT resilience) provide concrete compliance drivers that can be represented as modeled requirements and constraints.
Security frameworks such as NIST SP 800-53 offer control catalogues that can be mapped to architecture elements to visualize coverage and gaps.
- Modeling approach: requirements/controls linked to architecture layers
- Viewpoints: executive, risk officer, audit, engineering
- Pitfalls and anti-patterns
- GDPR Article 30.
- ArchiMate standard framing.
The regulation-to-architecture traceability matrix
Regulatory compliance is not a checkbox exercise — it is a continuous traceability challenge. Regulators (GDPR, ISO 27001, PCI-DSS, NIS2, DORA) define requirements. Architecture must demonstrate how those requirements are met through specific controls implemented in specific technology components. ArchiMate modeling standards
ArchiMate models this traceability chain explicitly. External regulations are modeled as Constraints or Requirements. Each regulation maps to one or more security Controls (modeled as Application Functions or Course of Action elements). Each control is realized by a specific Architecture Element — the TLS Gateway that implements encryption, the IAM Platform that implements access management, the SAST Pipeline that implements secure coding verification. ArchiMate tutorial for enterprise architects
The compliance status is tracked as a tagged value on each control-to-element link: Compliant, Partial, Non-Compliant, In Progress. A dashboard view aggregates these statuses to show the overall compliance posture per regulation — the CISO can see at a glance that GDPR is 92% compliant but NIS2 is only 67% compliant, with specific gaps identified.
Automated compliance gap detection
The most powerful use of this model is automated gap detection. A validation script traverses the regulation → control → element chain and flags any broken link: a regulation without a mapped control (gap in policy), a control without a implementing element (gap in implementation), or an element with a non-compliant status tag (gap in execution).
// jArchi: Compliance gap detection
var gaps = [];
$("constraint").forEach(function(reg) {
var controls = reg.outRels("association-relationship");
if (controls.size() === 0) {
gaps.push("NO CONTROL: " + reg.name);
}
});
$("application-function").filter(function(ctrl) {
return ctrl.prop("Control_Type") !== undefined;
}).forEach(function(ctrl) {
var status = ctrl.prop("Compliance_Status") || "Unknown";
if (status !== "Compliant") {
gaps.push("NON-COMPLIANT: " + ctrl.name + " (" + status + ")");
}
});
gaps.forEach(function(g) { console.log(g); });
console.log("Total gaps: " + gaps.length);
Modelling the Risk Itself, Not Just the Control
Most compliance models stop at controls, and controls are only half the story a risk committee needs. ArchiMate's motivation elements carry the other half if you use them deliberately: the regulation enters as a driver, the risk as an assessment attached to the element it threatens, the appetite decision as a goal, and the obligation as a requirement that controls then realize. The chain reads as a sentence — DORA drives the assessment that the payment gateway's single-region deployment threatens resilience, which motivates the requirement for regional failover, which the standby platform realizes — and that sentence is the unit a governance conversation actually works in.
Two practical rules keep this from becoming motivation-layer soup. First, risks attach to concrete elements, never float free: an assessment with no association to an application, node or process is a worry, not a model, and it will never appear on any useful view. Second, likelihood and impact live as properties on the assessment with controlled values, because the moment they are data, the risk heatmap becomes a generated overlay rather than a quarterly PowerPoint reconstruction — and a risk register that regenerates from the model is one the second line can actually trust against the architecture it describes.
Three Viewpoints for Three Committees
The same underlying model serves three audiences that must never be shown each other's view. The board risk committee gets the capability map with a single overlay — residual risk by capability, four colours, no element names — because their question is "where are we exposed" and every box beyond that answer subtracts attention. The risk function gets the coverage view: controls by platform, the matrix whose empty cells are the finding, with the assessment properties visible because likelihood arguments are their daily work. And audit gets the evidence chain per control — regulation to requirement to control to implementing component to verification record — as a navigable trail rather than a binder.
The discipline is that these are viewpoints over one model, not three models. The moment the board view is maintained as its own diagram, it drifts from the coverage view within a quarter, and the first meeting where the two disagree costs the practice more credibility than the viewpoints ever earned. ArchiMate's viewpoint mechanism exists precisely for this — same elements, filtered presentation — and the test of a compliance modelling effort is whether all three committees, asked the same question in the same week, receive answers that trace to the same underlying facts.
A DORA Worked Example
To make it concrete with the regulation currently reshaping European financial-sector architecture: DORA's core demand is demonstrable ICT resilience around critical business functions, and the demonstration is naturally a model query. Critical functions are business processes flagged with a criticality property; the supporting asset chain — applications, platforms, third-party services — is the realization path beneath them, which ArchiMate already expresses; and the register of critical ICT third-party providers that the regulation requires is, in a well-tagged model, a filtered catalogue of technology services with an external-provider property, generated rather than compiled.
The resilience testing obligations map the same way: each critical function's chain carries associations to its test evidence — the failover exercise, the recovery-time results — as assessment elements with dates. When the supervisor asks which critical functions depend on a given cloud provider and when that dependency was last tested, the answer is a two-hop traversal with a generation timestamp, not a working group. Institutions that modelled this once report the same experience as with every framework before it: the regulation's vocabulary changes, the underlying questions — what matters, what supports it, what protects it, how do we know — do not, and a model built on those questions absorbs each new acronym as a mapping exercise rather than a programme.
Keeping the Views Current Without a Compliance Team
Every pattern above dies the same death if the views are maintained by hand: they are accurate for the audit, stale by the next quarter, and quietly abandoned by the one after. The survivable design generates them. Risk overlays read assessment properties; coverage matrices read realization links; registers read tagged values — all of it derived at publication time, on the publication cadence, so the compliance picture is exactly as current as the architecture model itself, no more and deliberately no less.
This also assigns the maintenance burden where it can actually be carried. Architects maintain the model they were maintaining anyway; the compliance mapping rides along as properties and links, checked by the same quality gate that checks everything else — "critical element without a control link" is just one more rule with an owner. The alternative, a compliance function hand-tending its own diagrams of an architecture it does not control, produces the familiar two-truths problem in its most expensive form: the version the regulator saw, and the version that was actually running.
Starting From Zero in One Quarter
For a practice with no compliance modelling at all, the full apparatus above reads as a programme; the viable first quarter is much smaller and still changes the conversation. Weeks one to four: pick one framework — whichever audit arrives next — and import its control catalogue with version tags. Weeks five to ten: map only the critical perimeter, the twenty or thirty platforms that any assessor will actually sample, with rationale notes on every link. Weeks eleven to twelve: generate the first coverage matrix, take it to the risk function, and let the empty cells set the agenda.
Deliberately absent from the first quarter: evidence linkage, second frameworks, motivation-layer risk modelling, and any attempt at completeness. Those arrive in quarters two through four, pulled by demand rather than pushed by ambition — because the coverage matrix, once seen, generates its own requests, and features built against a request have owners while features built against a vision have maintenance debt. The one non-negotiable from day one is the discipline that makes everything else possible later: controls are elements with stable identifiers, mappings are links with rationales, and nothing lives only in a diagram. Get that grammar right with one framework and thirty platforms, and scaling it is repetition; get it wrong, and scaling it is archaeology.
The Anti-Patterns That Discredit These Models
Compliance models lose their audience in specific, recognisable ways, and naming them is cheaper than recovering from them. The wallpaper model: every control mapped to every vaguely related element, coverage gloriously green, and the first assessor's spot-check reveals that half the links mean nothing — one discovered fiction discredits a thousand honest links, which is why a sparse, rationale-noted mapping beats a dense confident one every time. The parallel truth: the compliance view maintained by the security team in their own package, drifting from the architecture the architects maintain, until the model contains two versions of the estate and the auditor finds the seam. One implementation layer, always, with compliance as overlays. And the certification sprint: the model built heroically in the six weeks before the audit, praised in the audit, and untouched until six weeks before the next one — detectable by any assessor who sorts the evidence dates, and fatal to the "continuous compliance" narrative the model exists to support.
Each anti-pattern shares a root: treating the compliance model as a deliverable for the auditor rather than as an operating view of a living architecture. The gate rules, the publication cadence and the weekly staleness reports described above are the structural antidote — they make the model's maintenance continuous because its consumers are continuous, and an assessor who sees twelve months of weekly publication timestamps has received the strongest compliance evidence this whole discipline can produce: proof that the practice looks at its own posture when nobody official is watching.
Applying these patterns in practice
The value of ArchiMate modeling is realized not through comprehensive coverage of every element type, but through disciplined application of a few core patterns that answer recurring stakeholder questions. Three patterns account for the majority of architecture communication needs. ArchiMate layers explained
The Layered View pattern shows how business processes depend on applications, and how applications depend on infrastructure. Build this view by placing Business Processes at the top, Application Components in the middle, and Technology Nodes at the bottom. Connect them with Serving and Realization relationships. This single view demonstrates cross-layer traceability — when a server is decommissioned, trace upward to see which applications and business processes are affected.
The Cooperation View pattern shows how application components interact through interfaces and data flows. Place the core application in the center and its integration partners around it, connected by Flow relationships labeled with the data exchanged. This view reveals integration dependencies that are otherwise buried in technical documentation.
The Motivation View pattern connects strategic goals to architecture decisions. Stakeholder concerns drive Goals, Goals are realized by Outcomes, Outcomes are enabled by Capabilities, and Capabilities are realized by Application Components. This chain answers the question executives always ask: "Why are we building this?"
If you’d like hands-on training tailored to your team — Sparx Enterprise Architect, BPMN, SysML, Apache Kafka or the Archi tool — or modelling coaching in ArchiMate and TOGAF-aligned governance, you can reach us via our contact page.
Frequently Asked Questions
What is enterprise architecture?
Enterprise architecture is a discipline that aligns an organisation's strategy, business operations, information systems, and technology infrastructure. It provides a structured framework for understanding how an enterprise works today, where it needs to go, and how to manage the transition.
How is ArchiMate used in enterprise architecture practice?
ArchiMate is used as the standard modeling language in enterprise architecture practice. It enables architects to create consistent, layered models covering business capabilities, application services, data flows, and technology infrastructure — all traceable from strategic goals to implementation.
What tools are used for enterprise architecture modeling?
Common enterprise architecture modeling tools include Sparx Enterprise Architect (Sparx EA), Archi, BiZZdesign Enterprise Studio, LeanIX, and Orbus iServer. Sparx EA is widely used for its ArchiMate, UML, BPMN and SysML support combined with powerful automation and scripting capabilities.
The discipline, compressed: risks attach to elements, scores live as data, views generate from links, and every colour can answer "says who". Everything else in this article is elaboration of those four clauses.