⏱ 23 min read
The meeting had already started to drift off course before the integration architect put the spaghetti slide on the screen.
Finance wanted “harmonization,” which, in that room, meant at least three different things. The central shared service team meant a common finance backbone and fewer local exceptions. One semi-autonomous body meant, more bluntly, “please don’t break our reporting deadlines.” HR, sitting two seats to my left, insisted their Oracle setup was strategic, compliant, and absolutely not to be treated as just another legacy platform waiting politely for retirement. An agency running SAP for core finance argued that anything touching money should eventually land there. Another team, running grants and operational casework on Dynamics 365, was tired of being told their platform was merely “adjacent” when, in practice, it triggered commitments, payments, and audit questions.
Then the integration team showed the map.
Unlabeled arrows. Middleware icons. A few APIs. Some nightly jobs. One ancient file drop nobody wanted to acknowledge. Everyone stared at it. Nobody trusted it.
That scene, in one form or another, is exactly why ArchiMate becomes useful in mixed ERP estates. Not because it is elegant. Not because executives love notation. Usually they do not. It becomes useful because it forces you to say what is serving what, who uses what, what data actually flows, and where responsibilities really begin and end. ArchiMate training
I’ve seen more ERP diagrams fail because they hid exceptions than because they lacked detail. That is the uncomfortable truth. In institutional environments, especially around EU bodies, a clean diagram is often less a sign of maturity than a warning.
The institutional setting: why this is never a single ERP story
If you work in or around EU institutions and related bodies, you stop believing fairly quickly in the phrase “the ERP.” It reads well in board papers. It sounds tidy in procurement language. It is rarely true in any serious operational sense.
These environments are shaped by forces pulling in different directions at the same time: strong financial control obligations, multilingual operations, deep auditability requirements, segregation of duties, institutional autonomy, and procurement cycles that outlive some strategy documents. Add long-lived legacy platforms, framework contracts, shared services ambitions, local derogations, and political caution around centralization, and you get landscapes that are mixed by design, not by accident.
A realistic composite picture usually looks something like this:
- SAP runs corporate finance and controlling in a central shared service context.
- Oracle handles HR, payroll, or a budget administration domain in a semi-autonomous body that has statutory or historical reasons for keeping it.
- Dynamics 365 supports grants, case management, project administration, lighter operational processes, or all three at once.
- Around the edges sit IAM, document management, e-invoicing gateways, data warehouse and BI platforms, master data services, workflow tools, and a surprising amount of Excel.
So when people say “ERP landscape,” what they often really mean is:
- three ERP-ish suites,
- a dozen integration styles,
- five ownership models,
- and absolutely no shared vocabulary.
That last point matters more than most architecture teams like to admit. If one stakeholder uses “finance” to mean the operating process, another uses it to mean SAP, and a third uses it to mean the CFO organization, you are not having a technology discussion. You are dealing with a semantics problem that will eventually turn into a governance problem. EA governance checklist
Before the model: what people were really arguing about
In the review sessions I’ve been part of, the arguments almost never begin as notation arguments. They start as power, risk, and accountability arguments dressed up as architecture.
The CFO office wants a single source of truth. Fair enough. But usually what they really want is consistency in reporting, fewer reconciliation headaches, and cleaner control evidence for auditors.
Local business owners want flexibility. That sounds reasonable too. What they often mean is that their process reality does not fit the central template, and they know from experience that “standardization” can quietly shift operational burden onto their teams.
Security wants role traceability. Procurement wants vendor-neutral documentation. Operations wants something supportable at 2 a.m., which, in my experience, is one of the healthiest instincts in enterprise architecture and one that gets ignored far too often.
Then the hidden disagreements surface.
Is SAP “the finance process,” or is it an application supporting a finance process that still includes manual review, local approvals, exception handling, and reporting outside SAP?
Is Dynamics part of ERP in a grants-heavy institution, or is it some adjacent case platform that happens to produce financially relevant events?
Does Oracle own employee master data, or does it merely maintain a payroll-oriented representation while another service governs identifiers?
These are not trivial distinctions. In ArchiMate, choosing whether something is modeled as a Business Process, a Business Service, an Application Service, or an Application Component changes the conversation. If you model “Financial Accounting” as only an SAP box, you have already told the room something about ownership and centrality. If you model “Grant Administration Service” as a business service supported by Dynamics and linked to finance outcomes in SAP, you have made a different statement—one that is usually closer to reality. ArchiMate in TOGAF
This is why I never treat architecture modeling as neutral. It isn’t. The value of ArchiMate in these discussions is not notation purity. It is that disagreements become visible instead of being hidden under vendor logos. ArchiMate modeling guide
The first bad model we drew — and why it failed
We got it wrong before we got it useful.
Our first pass looked professional enough to survive a steering committee. Each suite was a single box: SAP, Oracle, Dynamics. Integrations were lines. Some were dashed to imply indirect exchange. We mixed business capabilities with organizational units. “Finance” appeared in one place as a function, in another as a process, and elsewhere as a system label. Batch interfaces disappeared because, frankly, they made the picture ugly. Excel workarounds were omitted because nobody wanted to immortalize them.
Stakeholders nodded politely.
Then they never used the model.
Support teams said it was useless for incident impact analysis because it did not show which process depended on which interface, nor who owned recovery when a load failed at month-end. The transformation team overestimated consolidation potential because the diagram made overlap look bigger than it was and hid the awkward reality that different suites were doing different kinds of work. Business teams barely recognized themselves in it because handoffs and manual controls were missing.
That failure was useful.
ERP landscapes become dangerous when diagrams hide responsibility boundaries. If a payroll posting originates in Oracle, lands in SAP, gets adjusted manually in a spreadsheet, and then appears in reporting two days later, the architecture is lying if it shows a neat Oracle-to-SAP interface and calls it done. If reconciliation steps are not modeled, neither control design nor staffing impact is visible.
The uglier the operational reality, the more carefully ArchiMate should be applied. ArchiMate tutorial
Not to make the ugliness look elegant. To stop pretending it is not there.
A more useful way to model: start from services exchanged, not vendor products
The shift that improved things for us was simple, though not especially easy.
We stopped starting with products.
Instead, we worked in this order:
- Identify the institutional business services that actually matter.
- Map the critical business processes end to end.
- Identify the application services consumed in those processes.
- Then map application components and integrations.
- Only after that discuss technology choices, platforms, and roadmap.
This sounds obvious when written down. In practice, most ERP programs reverse it. They begin with suite decomposition because vendors, system integrators, and internal product teams are already organized that way. The model inherits those boundaries, and before long the architecture repository becomes little more than a polished version of the software contract.
Starting from services exchanged works better in mixed ERP estates because it exposes overlaps and dependencies that product-centric views hide. It also supports real shared service conversations. A central finance service can be represented in the business layer without implying that every finance-relevant activity is executed inside SAP. A grants administration service can remain business-critical even if it sits on Dynamics and only some outcomes flow into SAP.
This is where ArchiMate earns its keep.
The Business layer is where I represent institutional obligations, business actors, roles, handoffs, and the operating model. The Application layer is where I model the ERP services, components, and interfaces actually consumed. The Technology layer I use sparingly—only where operational constraints matter: schedulers, IAM, middleware, audit log repositories, runtime dependencies, maybe Kafka if event distribution is genuinely material. And when governance questions are driving decisions, I pull in Motivation and Implementation & Migration elements so the model records why a decision exists and what transition it belongs to.
That balance matters. Too little structure and the model becomes an opinion board. Too much notation and people stop reading.
The case: a mixed SAP–Oracle–Dynamics landscape that looks like real life
Let me sketch a realistic example. Fictitious, but assembled from patterns I’ve seen repeatedly over the years.
We have an EU institutional cluster with three operating centers:
- a central finance shared service center,
- a separate HR administration body,
- and an operational programs office managing grants and projects.
The core end-to-end processes are familiar enough:
- procure-to-pay,
- budget planning and execution,
- hire-to-retire,
- grant and project lifecycle,
- financial reporting and audit support.
The mistake would be to assume these map neatly to one suite each. They do not.
Business layer: start where accountability lives
At the business layer, I’d model actors and roles such as Authorising Officer, Financial Verifier, HR Case Officer, Grant Manager, and Vendor Master Steward. Those are not decorative labels. They shape control points and explain why a process cannot simply be “simplified” because a platform supports some standard flow.
Then come business services: Financial Accounting Service, Payroll Administration Service, Grant Administration Service. In an institutional context, these services are often consumed by multiple bodies but delivered through different combinations of shared and local capabilities. That distinction matters. A shared service is not the same thing as a common process, and a common process is not the same thing as one system.
Business processes then show how work is actually performed: Invoice Processing, Commitment and Payment Execution, Position Management, Beneficiary Onboarding.
The handoffs are the point.
For example, Beneficiary Onboarding may begin in the grants operation, where a Grant Manager initiates a beneficiary record in Dynamics. But if payment is going to happen through SAP-controlled finance channels, there is usually a vendor master stewardship step outside Dynamics, often centrally managed, sometimes partially manual, and very often delayed by missing compliance documentation. If you do not model that handoff, every conversation about payment lead time becomes distorted.
Likewise, Position Management may be governed by the HR administration body using Oracle HCM, while finance only consumes payroll results and organizational structures for posting and reporting. That business separation should be visible before anyone starts arguing about target platforms.
A simple relationship pattern in prose is often enough to align people: the Invoice Processing business process is performed by a Financial Verifier role and is served by an Accounts Payable Processing application service exposed by SAP. That one sentence is more useful than a generic “SAP supports finance” claim.
Application layer: decompose just enough to be honest
Now the application layer.
For SAP, I usually avoid modeling the entire suite unless I’m working on a deep internal redesign. For an enterprise architecture article—and, frankly, for many governance discussions—you want only the decomposition that matters. So I would model application components such as General Ledger, Accounts Payable, and Funds Management or Controlling, depending on the institutional setup. The application services exposed by those components might include Posting Service, Payment Run Service, and Budget Availability Control.
That level is enough to show meaningful support relationships without pretending to capture every module nuance.
For Oracle, the same principle applies. In our case, Oracle might contain Personnel Administration, Payroll Calculation, and Position Data Management. If the landscape uses Oracle HCM Cloud for some domains and legacy Oracle EBS for others, I would model those as distinct application components only if the difference matters for operations, governance, or migration. Otherwise you create detail that no decision actually needs.
For Dynamics 365, I would resist the common tendency to dismiss it as merely “workflow.” In grants-heavy or project-heavy institutional settings, Dynamics often carries operational truth that becomes financially relevant later. So model Beneficiary Case Management, Agreement Tracking, and Project Cost Capture as real application components or services, not as side notes.
Then model the cross-suite cooperation explicitly:
- vendor master synchronization,
- employee and person synchronization,
- cost center and organizational hierarchy exchange,
- posting summaries from Dynamics into SAP,
- payroll results from Oracle into SAP finance.
This is where ArchiMate’s application services, data objects, and flow relationships help. A Payroll Result data object can flow from Payroll Calculation in Oracle to a Payroll Posting Export Service, which serves an SAP Posting Service. That structure is much more honest than drawing an Oracle box and an SAP box with an arrow labeled “integration.”
It also surfaces the obvious but often neglected question: where does reconciliation happen?
Because it always happens somewhere.
Technology and integration reality: don’t hide the scheduler
At the technology layer, I am selective, but not romantic about it.
Some interfaces are APIs. Good. Keep them if they matter.
Some data moves through ETL or batch loads, especially around finance, reporting, and historical transfer. Also fine. Model them. A nightly budget load that can miss a cutoff is operationally significant no matter how unfashionable batch has become in architecture presentations.
Some exchanges still happen through file transfer because modernization plans have not reached that corner of the estate, or because statutory controls, vendor constraints, or sheer budget reality kept the old method alive. That may offend target-state sensibilities. It does not make it any less real.
And yes, in some modernized estates Kafka appears. Usually not across the whole ERP landscape, but perhaps in a data distribution or integration modernization layer where master data events or case updates are published for downstream consumption. If Kafka is actually part of the operating dependency chain, include it. If it is only on a roadmap and nowhere in production, do not let it colonize the model.
Same with cloud. Oracle HCM Cloud, Dynamics 365, SAP-hosted services, Azure integration services, cloud document repositories—they matter when they change responsibility, latency, identity handling, support boundaries, or resilience assumptions. Not because “cloud” deserves a box by default.
A useful technology/integration view for this kind of landscape often includes:
- middleware or iPaaS services,
- scheduler/orchestration platform,
- identity provider,
- audit log repository,
- reporting platform or data warehouse,
- maybe a message broker where event distribution matters.
What I try hard not to do is dump every connector and port on the page. Too much detail kills readability and still fails to improve understanding. The goal is to show meaningful operational dependencies, not to recreate network engineering.
Here’s a compact sketch of the application cooperation pattern:
It’s simple on purpose. The full model would separate services from components and show data objects more cleanly, but even a rough view like this is more useful than a vendor landscape slide.
A viewpoint set that actually works
One master diagram is usually a trap.
I’ve inherited architecture repositories with heroic “everything views” that no executive understood, no support team trusted, and no program manager updated after the second migration wave. They looked comprehensive. They were not useful.
For ERP programs in mixed institutional environments, I’ve had much better results with a small set of views.
Executive landscape view.
This shows major systems, ownership, and major services. It is what you use when the question is, “What do we rely on, who runs it, and why can’t we just switch one of them off?”
Process support view.
This maps process steps to application services. It is the right view when business owners and architects are arguing about whether a process is genuinely standardized or merely routed through multiple systems with central reporting at the end.
Integration dependency view.
This one matters more than people expect. It shows interfaces, direction, cadence, and failure impact. If a nightly payroll posting fails, who notices, who reruns it, and which business deadline is threatened? The model should answer that.
Responsibility view.
This is underrated. I use it to show institution, unit, or vendor ownership across components and services. Shared service debates become much healthier when the model makes ownership asymmetry visible.
Transformation view.
Current, transition, target, coexistence. More on that in a moment.
A repository becomes useful when it serves different conversations without pretending they are the same conversation.
One table I wish more teams used
This is the sort of thing that saves weeks of semantic confusion.
I’m fairly opinionated about this: if your model cannot distinguish the business service from the application that supports it, your governance problems will be harder than they need to be.
The ugly parts worth modeling
This is where many architecture teams flinch.
Manual controls. Reconciliations. Exceptions. Temporary workarounds that have somehow survived six budget cycles. None of it is glamorous. All of it matters.
A few examples from institutional settings:
Payroll journals originate in Oracle, are transformed for SAP posting, but after cutoff a manual adjustment is made in a spreadsheet because one category of allowance was approved too late for the scheduled run. That spreadsheet is reviewed, attached to an email chain, and later stored as control evidence.
A beneficiary record is created in Dynamics before vendor master approval exists in SAP. The grants team proceeds because operational deadlines are real. Finance then blocks payment until the vendor master is completed, and someone manually bridges the identifiers.
An invoice exception is handled entirely outside workflow because the ERP path cannot accommodate a specific derogation. So the approval runs through email and Excel, after which the final posting is entered into SAP as if the process had been clean.
If a manual step changes financial or compliance outcome, it belongs in the architecture. Full stop.
That does not mean every spreadsheet deserves a glamorous icon on your executive view. It means the relevant process view and control-oriented view should show it. In ArchiMate, I’ll often represent the manual reconciliation as a business process step and, where necessary, the spreadsheet or control file as an artifact or representation linked to the process. Not because I enjoy dignifying spreadsheets, but because pretending they do not exist is worse.
And one more practical rule: if something happens every quarter, it is not an exception. It is part of the operating model wearing an embarrassing disguise.
Where architects get SAP, Oracle, and Dynamics wrong in the same diagram
A shorter list, but a sharp one.
They assume the biggest suite is system of record for everything. It rarely is.
They confuse product branding with architectural function. “Dynamics” tells me almost nothing by itself. Dynamics for what? Grant case management? Field operations? Customer engagement? Financials? The product family name is not the architecture.
They over-model modules and under-model services. I’ve seen diagrams with twenty SAP module boxes and no visible representation of the business service actually consumed.
They ignore time. Nightly batch, near-real-time API, weekly correction load, month-end freeze—temporal behavior is architecture in ERP landscapes.
They forget authorization boundaries. Central IAM may provision identities, but SAP roles, Oracle security models, and Dynamics security constructs do not interpret those identities the same way. That matters for segregation of duties and audit.
And they fail to distinguish between “data created in system” and “data governed by organization.” I’ve seen teams claim SAP owns vendor data because records are created there, when stewardship rules, validation sources, and update approvals actually sit elsewhere.
Those errors are common because they make diagrams cleaner. They also make decisions worse.
From current state to target state: coexistence is the real architecture
In EU institutional environments, replacement is almost never a cinematic cutover. It is phased, negotiated, constrained by reporting calendars, statutory obligations, procurement windows, and plain institutional risk tolerance.
So coexistence is not an unfortunate interim detail. It is the architecture.
This is one of the places where ArchiMate’s Implementation & Migration concepts are genuinely practical. Plateaus let you describe the current state, one or more transition states, and the target without pretending that the target already exists. Gaps can be tied to work packages. Deliverables can be related to the architecture changes they implement.
A realistic migration storyline might look like this:
- Oracle payroll remains in place for statutory and operational reasons.
- SAP finance becomes the common financial backbone across more institutions.
- Dynamics expands to support grants and operational case handling where it fits better than forcing process into core ERP.
- Shared master data services are introduced before any major ERP retirement.
- IAM is rationalized in parallel because role traceability is already broken across the estate.
- Temporary interfaces multiply before they reduce.
That last point is where glossy target-state slides tend to lie. During migration, you often need more integrations, not fewer. More controls too. More reconciliation. More risk hotspots.
Model those transition states explicitly.
Mark interfaces as temporary where they are temporary, but still show them. Identify control points likely to fail under coexistence: payroll posting, vendor synchronization, duplicate role provisioning, delayed cost center updates, reporting discrepancies between operational and financial systems.
A simple transformation sketch makes the point:
Not pretty. Useful.
Governance choices the model should force into the open
A good architecture model should make avoidance harder.
In this kind of ERP landscape, the model should force explicit answers to awkward questions:
Who owns the chart of accounts?
Who owns cost centers?
Who is steward of vendor data when creation is centralized but local overrides are tolerated?
Who governs employee identifiers across HR and finance boundaries?
Who approves interface contract changes?
Which institution accepts downtime risk when a shared service fails during month-end?
Where is segregation of duties really enforced—in SAP, in Oracle, in Dynamics, in IAM, or partly in process because the tooling model never aligned?
And my favorite unpleasant question: who pays for integration remediation when no single ERP owner gets the benefit?
That one surfaces quickly in mixed estates. The shared pain is obvious, the budget line less so.
This is where models stop being documentation and become instruments for decision-making. If the ArchiMate repository only describes systems and not ownership, stewardship, and service boundaries, it will not help much. If it does, governance discussions become more concrete, and that is usually when people start taking the model seriously.
What I would do differently on day one of a new ERP landscape assessment
I’ve become more impatient about the first few weeks.
If I were starting a fresh assessment tomorrow, I would interview operations before the transformation office. Every time. The transformation office will tell you the intended future. Operations will tell you what breaks, what gets rerun, and what the auditors actually ask for.
I would ask for month-end and year-end realities, not process manuals.
I would insist on seeing failed interface logs, not just interface catalogs.
I would ask which spreadsheets are used as control evidence. There are always more than people admit at first.
I would map legal and reporting obligations before decomposing applications. Otherwise you spend too long arguing about products and not enough time understanding why the current mess persists.
I would define “system of record” per data domain, not per suite. Vendor, employee, beneficiary, commitment, payment, chart of accounts, organizational hierarchy—each may have a different answer.
And I would keep one ugly but truthful integration view. Not for executives. For architects, support teams, and the poor souls on call.
If you gave me four to six weeks for an initial architecture baseline, I’d aim to deliver three diagrams and one table:
- a landscape view with ownership,
- a process support view for two or three critical end-to-end flows,
- an integration dependency view with cadence and failure impact,
- and a system-of-record/stewardship table by data domain.
That is enough to have adult conversations.
A few questions I hear a lot
Is Dynamics really part of an ERP landscape in institutional settings?
Often yes. Not because of vendor marketing, but because it supports operational processes that generate financially relevant events, commitments, controls, and audit exposure.
How deep should SAP or Oracle decomposition go in ArchiMate?
Only as far as decisions require. If no governance, support, or transformation decision depends on the distinction, do not decompose for the sake of completeness.
Should manual controls appear in enterprise architecture models?
If they affect compliance, financial outcome, operational resilience, or staffing, yes. Not always on every view, but yes.
Can one ArchiMate repository serve both strategy and support teams?
It can, if you design viewpoints deliberately. It cannot if you expect one all-purpose diagram to satisfy everyone.
Conclusion: ArchiMate is useful only when it captures the compromises
Back to that opening meeting.
What eventually improved the discussion was not a prettier picture. It was a more honest one. We separated business services from applications. We showed that Oracle payroll remained essential without pretending it owned all HR truth. We showed Dynamics as operationally critical instead of an awkward sidecar. We decomposed SAP where it mattered and nowhere else. We modeled vendor master stewardship, payroll posting, reconciliation, IAM dependencies, and the batch jobs everyone secretly relied on. The room became more argumentative for a while, which I took as progress.
Because finally people were arguing about the same reality.
That, to me, is the real value of ArchiMate in mixed ERP landscapes. Not elegance. Not repository purity. Not notation theatre. It makes service boundaries, ownership, data flows, and operational exceptions explicit enough that finance, HR, operations, security, procurement, and delivery teams can stop talking past each other.
In EU institutional environments, the best ArchiMate model is rarely the prettiest one.
It is the one that does not lie.
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.