⏱ 22 min read
The argument started in a steering committee, which is usually a pretty reliable sign that the modeling choice had already gone sideways.
We were in the middle of a manufacturing modernization program for a global industrial company. Four major plants. An aging ERP landscape that everyone complained about but nobody wanted to touch too quickly. Three MES variants that had somehow all become “strategic” in their respective regions. Quality tracking that still leaned heavily on spreadsheets. Maintenance requests routed through email in one plant, a homegrown workflow in another, and plain tribal knowledge in a third. On top of that, we were introducing a cloud integration layer, event streaming, a new data platform, and a more serious identity model because shared accounts on the shop floor had somehow survived much longer than they ever should have.
The team presenting that day had done what capable teams often do when the pressure rises: they reached for the notation they knew best and stretched it far beyond its natural limits.
So the slide on the wall was a very detailed process diagram. Swimlanes everywhere. Approval steps. Exception paths. Handoffs between operators, supervisors, quality engineers, and systems. It was BPMN-ish, though like a lot of real project artifacts, it had been bent to fit both PowerPoint and politics. To be fair, it answered one class of question very well: how work moved when a production issue occurred.
But within about two minutes, operations leaders started asking questions the diagram simply could not answer.
Where does the plant historian sit in this?
Which system owns lot genealogy?
Are we replacing the local quality database or integrating it?
What depends on the cloud platform?
If Plant 2 keeps its MES for another two years, what breaks?
Then one of the enterprise architects stepped in with what he assumed would rescue the meeting: a high-level architecture view. Boxes. Relationships. Business capabilities. Applications. Integration services. Target-state cloud services. Much closer to ArchiMate in spirit, though simplified for the audience. ArchiMate training
That lasted maybe three minutes before the plant manager from the Czech site asked the obvious question:
“Fine. But if an operator flags a defect during second shift and quality is offsite, who does what next?”
That was the moment the room told us, very clearly, what I’ve seen on a lot of transformation programs: BPMN answered how work flows. ArchiMate answered what exists, why it matters, and how the parts relate. We were trying to use each to answer the other’s question, and both were failing in predictable ways.
That is the real comparison, at least on programs that actually matter. It is almost never a clean “ArchiMate or BPMN” decision. The real issue is more practical and a lot less glamorous: what problem are you trying to solve right now, for which audience, and what decision needs to move?
Manufacturing exposes this faster than most industries because operational process and enterprise architecture collide every single day. On the shop floor, a bad workflow design creates real delays, scrap, rework, and safety risk. In the architecture space, a bad dependency decision quietly buys you two more years of integration debt and makes every future rollout more expensive.
You feel both. Usually sooner than you’d like.
Manufacturing makes the comparison harder than people admit
The program itself was not especially unusual, which is exactly why it makes a useful case.
This was a global manufacturer trying to modernize without shutting plants down or pretending all sites were identical. Legacy ERP handled planning, finance, and core material movements. MES varied by plant because historical acquisitions had largely been left intact. Quality management lived partly in ERP, partly in local databases, partly in spreadsheets, and partly in people’s heads. Maintenance workflows were fragmented. OT and IT had separate governance habits, different vocabulary, and very different tolerance for change windows.
The strategy was sensible enough. Move toward cloud-based integration, better end-to-end visibility, more standardized operating models, and a target architecture that could eventually support consistent quality traceability and plant performance analytics. Kafka came in as the event backbone candidate because we needed decoupled event distribution between plant systems, enterprise applications, and the cloud data platform. IAM became more important than anyone really wanted to discuss, because once you start exposing APIs and centralizing services, “operator1/operator1” stops being a survivable identity pattern.
Manufacturing is where notation debates stop being theoretical because so many abstraction levels coexist at once. In the same week, you can be talking about business capability gaps with the CIO, exception handling on a nonconforming batch with a quality lead, MQTT or OPC UA ingestion patterns with OT engineers, Kafka topic ownership with integration teams, and rollout sequencing for site-specific MES retirement.
That is a lot of altitude change for one program.
And teams usually arrive with bias. Process excellence people reach for BPMN almost by reflex. Enterprise architecture teams reach for ArchiMate the same way. Neither instinct is wrong. Both become a problem when the notation turns into a comfort blanket. ArchiMate modeling guide
I’ve watched process teams try to use BPMN to explain application rationalization. It gets ugly fast. I’ve also watched architects use ArchiMate when the room is still trying to settle a basic operational question like who approves a production deviation after hours. That is not architecture leadership. It is abstraction at the wrong time. ArchiMate tutorial
The first real question was not “which notation do we prefer?”
It was messier than that.
The actual problem in front of us was this:
How do we explain the future-state order-to-production-to-quality traceability model to both corporate IT and plant operations?
That one question contained four very different needs.
Leadership wanted investment visibility. If we spend on cloud integration, quality platform changes, data services, and IAM uplift, what are we actually standardizing and what are we merely connecting?
Integration teams wanted system responsibilities. Who publishes events? Who owns the canonical lot and batch traceability model? Where does transformation happen? Which APIs become strategic versus temporary?
Process owners wanted workflow detail. What exactly happens when a batch is held? Who reviews it? How do escalations work? Where are manual overrides allowed?
Compliance teams wanted auditable handoffs. They did not care in the slightest about notation purity. They cared that the process and system controls could stand up to inspection.
That is exactly where misuse begins.
If you try to use BPMN to communicate portfolio impact, target-state platform dependencies, or capability gaps, you end up drawing a sequence that is technically accurate but strategically hollow. If you try to use ArchiMate to model operator decisions, branching logic, timing sensitivities, and task sequencing, you create a tidy enterprise view that leaves the people doing the work unconvinced and unsupported.
So let me be direct: this article is not a standards tutorial. It is a field note from a program where both notations were useful, both were misused, and the breakthrough only came when we stopped asking which one was “better.”
What BPMN was actually good for in the plant
Plant stakeholders trusted BPMN first, and honestly, I think that trust was earned.
Not because anyone cared much about the standard itself. Most supervisors and quality leads do not wake up wanting notation discipline. They trusted it because BPMN, when used well and not overcooked, mirrors how operational people think about work: something happens, someone makes a decision, a handoff occurs, a system updates, an exception branches, and the process either recovers or escalates.
That was invaluable in several areas.
Production scheduling approvals.
Nonconformance handling.
Maintenance request routing.
Supplier quality escalation.
Engineering change approvals.
The strongest example for us was nonconforming batch handling.
An operator detects an issue at the line. A quality hold is triggered. A supervisor is notified. Depending on severity, the batch is blocked in MES, ERP inventory status is updated, and a lab test request may be created. An inspector reviews. Results come back. A disposition decision is made: use as is, rework, scrap, or escalate for deviation approval. In some plants, there was a parallel review with process engineering. In another, night shift had a temporary containment process because no local quality approver was present after certain hours.
That is BPMN territory.
The notation let us show explicit roles. It made gateways visible, which sounds mundane until you realize gateways are often where policy ambiguity hides. One site believed supervisor approval was enough for certain deviations; another required quality signoff; a third had an informal workaround that had never made it into SOPs. The process model exposed that the “standard process” was often more fiction than fact.
That alone justified the effort.
BPMN also became unexpectedly useful in surfacing hidden manual work. More than once we heard, “that step is automated,” and then during walkthrough discovered the automation was actually a clerk copying data from MES into a spreadsheet and attaching it to an email for quality review. A good process workshop with BPMN is merciless in that way. It does not let handoffs remain magical.
For workflow automation discussions, it was the obvious language. When we started evaluating where a process engine or low-code workflow layer might help, BPMN gave product owners and automation teams a concrete basis for talking about triggers, tasks, approvals, exception loops, and SLAs.
But there is a trap here. A beautifully drawn BPMN model creates false confidence. Teams start acting as though a discovery-level process diagram is already an executable design. Usually, it is not. The details that matter in implementation — data contracts, timeout handling, identity propagation, task reassignment rules, integration error states — are often still unresolved.
I’ve seen teams celebrate the diagram before they’d actually solved the process.
The first mistake: using BPMN to explain architecture rationalization
We made this mistake early, and in hindsight I’m glad we did because it killed the debate quickly.
At one point the team tried to compare three MES variants, an event broker, data lake ingestion, and ERP integration paths using BPMN swimlanes. The intent was understandable: show current interactions, then show the cleaner future state. In practice, it was a mess.
Sequence dominated everything. Structure disappeared.
You could follow the order of messages and tasks, but you could not clearly see which applications were strategic, which were temporary, which services were shared, what the ownership boundaries were, or how the target architecture simplified the landscape. Application lifecycle was invisible. Cloud platform dependencies got buried inside task boxes. We had no clean way to show transition states for plants moving in different waves.
The diagram was technically busy and strategically empty.
That was the lesson. BPMN is weak when the audience needs to understand application cooperation, capability support, transition states, technology dependencies, and cross-domain impact. It can include systems, of course. People do that all the time. But that does not make it good at architecture thinking.
If the discussion includes words like rationalize, roadmap, plateau, capability gap, target operating model, or retirement candidate, BPMN alone is almost always the wrong instrument.
Not bad. Just wrong for that purpose.
Where ArchiMate became useful — and frankly necessary
ArchiMate helped us once the question shifted from flow to structure and change.
I do not mean we walked into plants saying, “Let me explain a modeling standard.” That would have been a very efficient way to lose the room. We used ArchiMate more pragmatically: as a disciplined way to connect business capabilities, processes, applications, data, and technology views without inventing a new notation every week.
That mattered a lot in this program.
We needed to show capabilities like production planning, quality management, maintenance coordination, genealogy traceability, and integration management. We needed to map business processes to the applications supporting them. We needed to show how applications depended on integration services, cloud APIs, Kafka topics, IAM services, and storage patterns. We needed to distinguish plant-local systems from enterprise platforms. And we needed current-state and target-state views that could survive steering committee scrutiny.
A quality traceability view became one of the most useful artifacts in the whole program.
At the business layer, we showed a quality engineer and the defect investigation process. That connected to application services like lot genealogy lookup and test results retrieval. Those services were realized by components in MES, QMS, ERP, and the cloud data platform. Under that sat the technology layer: API gateway, Kafka-based event streaming, cloud object storage, managed databases, IAM, and observability services.
That one view answered questions BPMN never could.
What changes if we retire a local quality database?
Can the cloud platform support enterprise genealogy lookup, or is MES still the source of truth?
What systems depend on the event stream?
If IAM policy changes, which services and users are affected?
Can Plant 1 move forward before Plant 3 without breaking traceability reporting?
Executives liked it because it connected investments to a real operating model. Platform teams liked it because it made dependency chains visible. Integration leads liked it because interfaces and ownership became discussable instead of implied. Even the skeptical application managers could at least see where their system sat in the future state and what the transition path looked like.
That is where ArchiMate earns its keep: not in abstract elegance, but in transformation planning.
Here’s the simple comparison we ended up using with teams:
What ArchiMate did poorly for us
This part matters because architecture articles too often drift into advocacy.
ArchiMate was not good at detailed operator actions. It was not good enough for the branching logic needed in workflow implementation. It was clumsy for inspection paths with lots of exceptions, loops, timing rules, and human judgment. And in workshops with supervisors unfamiliar with architecture abstractions, it often landed flat unless we simplified it heavily.
I remember one session where we showed a layered architecture view with business processes, application services, components, and technology nodes. Perfectly reasonable from an architecture perspective. The supervisors looked at it for maybe twenty seconds and one of them said, “This is fine, but if the line stops because quality blocked the batch and the lab result hasn’t come back, who can release the next order?”
That was not resistance. It was clarity.
The room was trying to resolve operational ambiguity. We had brought an architecture lens too early.
ArchiMate can become too abstract too soon, especially when architects are trying a bit too hard to prove rigor. In practice, if the room needs to answer “who does what next” or “what happens in this exception,” use BPMN or even a rough process sketch first. Earn the right to zoom out.
The turning point: stop asking which notation is better
Once we got past the false competition, the program moved faster.
The mature framing was simple:
- Use BPMN when the risk is in execution ambiguity
- Use ArchiMate when the risk is in architectural ambiguity
That sounds tidy written down, but it came from pain, not theory.
Execution ambiguity looked like this in our world:
Who approves a production deviation?
What happens when lab results are late?
Where does manual override occur?
When is a batch blocked in MES versus only flagged in QMS?
How do after-hours approvals work across sites?
Architectural ambiguity looked different:
Which platform owns event distribution?
What systems support genealogy lookup?
What can be retired after standardizing quality workflows?
Where should API security and identity policy be enforced?
Is the master defect taxonomy in ERP, QMS, or a shared cloud service?
That distinction became our hinge point. Not perfect, but practical.
Here’s a small decision lens we used:
It was not academically pure. It worked, which in my experience matters more.
A layered case: digitizing nonconformance management across plants
This was the scenario where combining both notations finally made sense to everyone.
Each plant handled nonconformance differently. One had a strict hold-and-review process but poor traceability. Another moved faster operationally but relied on local spreadsheets and undocumented supervisor discretion. A third had good system discipline in MES but weak integration to ERP and almost no enterprise-level reporting.
The operational problem was obvious: inconsistent escalation, poor visibility, and too much dependence on local knowledge.
Part A: BPMN showed us the truth
We modeled local workflows and then a target process. Not every branch. Only the branches that mattered for decision-making.
That BPMN work surfaced manual steps, delays, duplicate approvals, and loops nobody had admitted were there. It made visible where automation was realistic and where human judgment was still necessary. In one plant, a rework path existed because the equipment constraint was real. In another, the variation was accidental — a workaround caused by legacy system limitations and poor interface design.
That distinction matters. People often label all variation as “site-specific reality.” Some of it is. Some of it is just technical debt wearing a hard hat.
Part B: ArchiMate showed us why standardization alone would fail
Once the target process was clearer, we mapped it to capabilities, applications, interfaces, and cloud services.
The view distinguished plant applications from enterprise platforms. MES remained the source of execution events. ERP maintained material and inventory status. QMS owned certain quality records. Kafka carried event notifications and state changes into the integration layer and data platform. API gateway and IAM handled service exposure and access control. A cloud-based traceability service was introduced as a shared lookup layer rather than pretending any one legacy application could suddenly serve the whole enterprise.
That architecture view made two uncomfortable truths visible.
First, workflow standardization by itself would not solve fragmented master data. If defect codes, material attributes, and genealogy references were inconsistent, the process could be beautifully harmonized and still produce unreliable reporting.
Second, some systems we had hoped to retire could not go immediately because they still held operationally critical logic. The architecture simplification story looked clean in strategy slides. The dependency map said otherwise.
That is exactly why ArchiMate mattered. It stopped us from telling ourselves a modernization fairy tale.
Part C: Combined, the models told a fuller story
The BPMN model said where ambiguity lived in work execution.
The ArchiMate view said where complexity lived in the enterprise.
Put together, they showed that some process variation was necessary because of plant equipment constraints, some variation was accidental and should be removed, and some problems blamed on process were actually data and platform issues.
That combination gave us a rollout strategy we could defend.
Not elegant. Useful. In a program like this, useful wins.
The second mistake: modeling too much, too early
This one is common enough that I’ve stopped treating it as some special failure. It is just what architecture teams do under stress.
We tried at one stage to produce complete BPMN and ArchiMate coverage before making several key decisions. The intent sounded responsible. In reality, artifacts multiplied, governance slowed down, and business stakeholders stopped reading the models.
Completeness is seductive. It feels like control.
But in transformation work, especially in manufacturing, completeness often becomes procrastination with better tooling. Plants have release windows. Shutdown calendars. Validation constraints. Vendor dependencies. Operational tolerance for change is limited. The program will not pause while the architecture team perfects repository hygiene.
The trap is confusing comprehensive modeling with useful modeling.
My advice, earned the hard way, is decision-driven modeling. Create the views needed to answer a live question. Go deeper only where risk is high or delivery is imminent. Let the model repository follow the program, not the other way around.
Some of the best artifacts in this program were one-page views made under pressure. Some of the worst were elaborate diagrams no one ever used after a governance meeting.
That happens more often than architects like to admit. TOGAF roadmap template
How I’d sequence the work on a real cloud transformation program
This is opinionated. Good.
If I were doing a similar manufacturing modernization again, I would sequence it roughly like this.
First, identify the business outcome and the actual decision owners. Not the nominal governance chart — the real people who can say yes, no, or not yet.
Then use lightweight process framing to locate operational pain. Not full BPMN on day one. Just enough to find the ambiguity.
Next, model the high-risk workflows in BPMN. Usually the exception-heavy ones: nonconformance, deviation approval, maintenance escalation, engineering change with plant impact.
After that, build ArchiMate views for capability, application, integration, and target-state impact. Keep them narrow. If your architecture view needs a ten-minute legend, it is probably too broad for the audience.
Then connect process changes to platform and data implications. This is where Kafka topic ownership, API exposure, IAM design, audit logging, and cloud service choices become concrete. A process change that introduces cross-plant visibility, for example, may quietly require a much stronger identity and authorization model than the old local workflow ever needed.
Only refine the areas entering delivery or governance review. Everything else can stay lighter.
That sequence worked in manufacturing because it avoided two opposite failures: architecture becoming abstract before operations had clarity, and process design proceeding as though systems and platforms were irrelevant. It tied workflow design to actual modernization choices.
The deliverables that worked best for us were almost boring in their simplicity:
- a one-page ArchiMate capability/application map
- a focused BPMN flow for critical exceptions
- a transition-state architecture view for rollout waves
Those three together moved more decisions than dozens of detailed diagrams.
A few heuristics I actually use
Reach for BPMN when the team is redesigning a workflow, when exception logic matters, when automation or orchestration is in scope, when role clarity is missing, or when auditability depends on sequence and handoff definition.
Reach for ArchiMate when you are shaping target architecture, when stakeholders need impact analysis, when application and platform rationalization are in play, when capability-to-system traceability matters, or when roadmaps and transition states need to be communicated.
Use both when process standardization depends on application modernization, when workflow changes span ERP, MES, integration, analytics, and cloud platforms, or when the same decision affects operations and enterprise architecture at once.
And one warning that experience has made me less polite about: if you need one notation to “win” politically, your real problem is governance, not modeling.
Who understands what
Different stakeholders absorb different views. This seems obvious, yet teams still present the same artifact to everyone and act surprised when it falls flat.
A plant manager will usually engage better with BPMN and a very simplified capability view. A quality lead often needs both: BPMN for operational controls and ArchiMate for system support visibility. Enterprise architects naturally prefer ArchiMate, but many of them show too much metamodel complexity and lose credibility. Integration leads often want ArchiMate for interfaces and dependencies, then BPMN to understand triggering events and process initiation points. Product owners and workflow automation teams need BPMN almost by default, with ArchiMate helping around dependency management and delivery sequencing. CIOs and steering groups usually benefit from target-state and transition views in ArchiMate, with selective BPMN examples only when the process change is what drives the spend.
This is not about dumbing things down. It is about respecting the decision each audience is actually trying to make.
What usually goes wrong on real projects
A few patterns show up again and again.
Using BPMN as an enterprise architecture notation.
Using ArchiMate to force detail no operator cares about.
Creating isolated process models with no system ownership.
Creating target-state architecture views with no operational truth.
Modeling current state in exhaustive detail after the decision window has already passed.
Failing to account for plant-level variation.
Letting tooling dictate notation choice.
Manufacturing adds its own flavor to these failures. OT/IT boundaries look blurry in diagrams and then become painfully real during implementation. A site exception that seems minor on paper can derail a “standard” design because the equipment constraint is real, the shift pattern is different, or the local MES customization is more deeply embedded than anyone admitted. I’ve seen rollout plans built on architectural optimism collapse because the process model never reflected how the plant actually worked. I’ve also seen process standardization efforts stall because nobody made system dependencies visible early enough. ArchiMate in TOGAF
Both failures are expensive.
Use the right lens for the risk
So, ArchiMate versus BPMN?
In real projects, that is usually the wrong question.
They are not substitutes. They solve different kinds of design and communication problems. BPMN helps you design and discuss how work moves. ArchiMate helps you design and discuss how the enterprise is put together and how it changes.
Manufacturing transformation makes the distinction impossible to ignore because the cost of getting it wrong shows up on both sides. Workflow decisions made without architecture context create brittle, local optimizations. Architecture decisions made without operational reality create elegant diagrams that fail on the shop floor.
If I have one strong opinion after doing this a few times, it is this: the best teams do not model more. They model with sharper intent.
That is the difference.
Frequently Asked Questions
What is BPMN used for?
BPMN (Business Process Model and Notation) is used to document and communicate business processes. It provides a standardised visual notation for process flows, decisions, events, and roles — used by both business analysts and systems architects.
What are the most important BPMN elements to learn first?
Start with: Tasks (what happens), Gateways (decisions and parallelism), Events (start, intermediate, end), Sequence Flows (order), and Pools/Lanes (responsibility boundaries). These cover 90% of real-world process models.
How does BPMN relate to ArchiMate?
BPMN models the detail of individual business processes; ArchiMate models the broader enterprise context — capabilities, applications supporting processes, and technology infrastructure. In Sparx EA, BPMN processes can be linked to ArchiMate elements for full traceability.