Composable MES (cMES): Modular Manufacturing Architecture

What Composable MES actually is — and what it usually is not

Composable MES (cMES) is a Manufacturing Execution System built as an orchestrated collection of independently deployable, API-addressable services rather than as a single monolithic application, with a shared canonical data model binding the services into a coherent system and an event-streaming backbone carrying state changes between them. The specific architectural properties that make an MES genuinely composable — as opposed to modular, which is a weaker and older concept — are usually summarised under the MACH acronym coined by commercetools and institutionalised by the MACH Alliance in 2020: Microservices, API-first, Cloud-native, Headless. A system that lacks any one of these four is not composable in the strong sense, however much its vendor's marketing insists otherwise.

The underlying conceptual move — treating enterprise software as a portfolio of interoperable capabilities rather than as a single seated system — was formalised by Gartner analysts Yefim Natis and Gene Alvarez in their 2020 research note introducing the "Composable Enterprise," which reframed the ERP/CRM/MES triad as an artefact of 1990s packaged-software economics rather than a feature of the work being automated. The cMES concept is the manufacturing-domain application of that broader idea, and it has converged with several concurrent architectural trends — cloud-native infrastructure, container orchestration, event-driven integration, the no-code movement — into the specific pattern that the industry is currently rallying around, with varying degrees of honesty about whether individual vendors actually implement it.

I have spent the last decade building cloud-native MES infrastructure, and the single most consistent observation from that work is that the architecture is not the hard part. The MACH properties are engineering disciplines — important, well-understood, and by 2026 effectively commodity patterns with mature tooling (Kubernetes, Kafka, OpenTelemetry, gRPC, REST, GraphQL, OAuth 2.1). A competent engineering team can build an API-first microservice architecture in months. What takes years, and what separates working cMES implementations from the large population of systems that claim composability but produce chaos, is the governance of the shared data model and the discipline of operating a distributed system under the specific constraints of manufacturing — real-time state, ISA-95 Level 3 semantics, event ordering, regulatory auditability, and the fact that downtime on the MES is downtime on the factory. This piece describes both dimensions.

The MACH properties, precisely

The four MACH properties are each doing different architectural work. Understanding what each one contributes — and what architectural costs each one imposes — is the prerequisite for evaluating whether a specific system is actually composable or is a conventional monolith with better marketing.

The single most common failure mode in the current cMES market is systems that claim three out of four properties and quietly fail on the fourth. Cloud-hosted monoliths that call themselves "cloud-native". Modular monoliths that call themselves "microservices" because their code is organised in directories. APIs that exist as secondary export layers rather than as the primary contract of the system. These are not composable architectures; they are conventional architectures with composable vocabulary. The sector has a name for this practice, and it is worth adopting: composable-washing.

ISA-95 Level 3 and MESA-11 — what cMES decomposes

A legitimate cMES is not a rejection of the functional frameworks that have defined MES for thirty years; it is a different way of packaging them. The classical references — ISA-95 (which defines the activity model for Level 3, sitting between control systems at Level 2 and enterprise systems at Level 4) and MESA-11 (MESA International's original eleven-function model, updated over the years to the current "Strategic Initiatives Model") — remain the correct conceptual vocabulary for what an MES does. cMES changes how the functions are deployed and integrated, not what they are. A useful mapping of the canonical MES functions to independently deployable microservices looks roughly as follows:

The mapping is not one-to-one, and the art of composable architecture is deciding where the service boundaries actually run — which functions share a data store, which share only events, which must be strongly isolated because their update cadences are incompatible. A useful heuristic I apply when reviewing cMES designs: draw the data-ownership boundary first, then put the service boundary on the same line. Services that share a database are not really separate services; they are co-deployed modules in a shared monolith. Services that cross functional boundaries because "it's convenient" are accumulating the coupling that composability was supposed to eliminate.

The shared canonical data model — the actually hard part

The most important architectural decision in any cMES implementation, and the one that almost all composable-washing systems silently fail on, is the shared canonical data model. The promise of composability — "add, replace, or remove modules without breaking the rest" — is structurally impossible without a commitment to a canonical model that defines what a work order, a material lot, a machine state event, a quality result, a personnel assignment, a tool, a shift, a plant, an operation, and a unit are in precise terms, with versioned schemas, with explicit semantic ownership, and with governance over changes. Without this canonical model, every new module added to the system produces its own local definitions of the same concepts, and the integration work between modules becomes point-to-point translation — exactly the N² integration problem that composability was supposed to solve.

The canonical data model has to live at a layer below the modules and above the individual service implementations. In the SYMESTIC architecture — which I can describe because I built it — the canonical model is expressed as a set of versioned JSON Schema definitions and AsyncAPI event contracts, with explicit schema-evolution rules (additive changes are non-breaking and forward-compatible; removals and semantic changes require major version bumps and coexistence periods), ownership assigned to specific engineering teams for specific entity types, and an automated compatibility check that runs on every pull request against every service. The model covers roughly 80 canonical entity types and 200 canonical event types, which sounds like a lot until you realise that MES is genuinely that complex. A plant's reality — orders branching into operations branching into lots branching into serials, with tools and operators and machines and quality and energy and maintenance weaving through — does not reduce to fewer concepts just because the implementation is composable.

The discipline required to maintain the canonical model over years, across teams, across acquisitions of vendor-built modules, across changes in regulatory requirements, is the single most expensive line item in running a cMES. It is also the line item most consistently underinvested in by vendors that claim composability and by customers that buy it. The symptom of underinvestment is always the same and always appears around the 18-month mark: adding a new module has become more expensive than it was at launch rather than cheaper, integration work now dominates feature work, and the "composable" system has acquired all the rigidity of a monolith plus all the operational complexity of a distributed system. I call this failure mode The Integration Tax — the marginal cost of each new module grows superlinearly once the canonical model has drifted, because every integration now has to reconcile not just with the new module but with the accumulated inconsistencies of all prior modules.

The event-streaming backbone

Composable systems are integrated through events, not through direct service-to-service calls. A new quality result arrives as a QualityResultRecorded event on the event bus; whichever services care about quality results — the genealogy service to link the result to the unit, the SPC service to check control limits, the OEE service to update the quality factor, the alarm service to evaluate escalation rules — subscribe to the event stream and react. This pattern (event-driven architecture, event sourcing, CQRS — command/query responsibility segregation) is the standard distributed-systems answer to the coupling problem that direct request/response integration creates, and it is essentially mandatory for a genuine cMES at scale.

The concrete technology choices in 2026 are mature but not trivial. The event-streaming layer is typically Apache Kafka, Apache Pulsar, or a cloud-managed equivalent (AWS Kinesis, Azure Event Hubs, Google Pub/Sub). The schema layer — where the AsyncAPI contracts live and where schema evolution is enforced — is typically Confluent Schema Registry, AWS Glue Schema Registry, or an equivalent. The service layer runs on Kubernetes (either managed — EKS, AKS, GKE — or self-hosted), with containers built from language-appropriate base images (the SYMESTIC stack is primarily .NET on Linux containers), deployed via GitOps pipelines (ArgoCD, Flux), and observed through the CNCF observability stack (OpenTelemetry for instrumentation, Prometheus for metrics, Jaeger or Tempo for distributed tracing, Grafana for visualisation). The API gateway layer — the single enforced ingress to all services, where authentication, rate limiting, and API versioning are enforced — is typically Kong, Ambassador, Istio, or a cloud-native equivalent.

None of this is exotic in 2026. The entire stack has been production-grade for five years. What is exotic is the specific application to manufacturing, because manufacturing imposes constraints that generic cloud-native patterns were not originally designed for — real-time ordering guarantees on events (a machine state change has to be sequenced correctly relative to the production-order events for the genealogy to be accurate), millisecond-scale latency requirements (an SPC service that takes 500ms to evaluate a control limit will miss the response window for halting the line), durable audit trails (regulated industries require proof that every event was processed and that the processing logic at the time of processing is reproducible), and failure semantics that have to map to physical plant behaviour (what happens to the production line if the OEE service is down for six hours is not the same question as what happens to a shopping-cart recommendation service being down). The architectural patterns are commodity; the application of them to the manufacturing problem is still craft.

cMES vs. traditional MES — the comparison that matters

The comparison table that circulates in cMES marketing materials — "monolith vs. app toolkit, big bang vs. incremental, months vs. weeks" — captures the vendor pitch but not the actual architectural distinction. The honest comparison is along three axes that matter to the people who have to operate the system for ten years:

The pattern that emerges from this comparison — and that matches what I have seen in practice at hundreds of plants — is that cMES is a high-variance architectural choice. When it works, it works dramatically better than traditional MES: additions are cheap, evolution is continuous, individual plant customisations do not compromise the shared platform. When it fails, it fails worse than traditional MES: operational complexity explodes, integration tax compounds, and the organisation ends up paying for the complexity of a distributed system without getting the benefits of composability. The difference between the two outcomes is governance discipline, not technology choice, and the vendors that publish the most aggressive cMES marketing are frequently the ones least equipped to deliver the governance.

Low-code / no-code — what it is actually doing

Every modern cMES product ships with a low-code or no-code configuration layer that promises non-developer users (process engineers, quality managers, plant controllers) the ability to build and modify applications without writing code. The promise is real and valuable; the practice is more nuanced. What low-code is actually doing is moving the complexity of certain kinds of change from engineering teams to business users — which is beneficial for change velocity but dangerous without governance.

The failure mode I watch develop in low-code-heavy cMES adoptions is consistent: low-code builds accumulate in the system as a parallel track to engineered features, nobody owns them at a platform level, they grow technical debt exactly like code does but without the same review and testing discipline, and after 18–24 months the "low-code environment" becomes a tangle of interdependent configurations that nobody fully understands. The low-code built by the quality team depends on a data structure defined by the operations team which depends on a workflow configured by a consultant who has since left. When something breaks — and something always eventually breaks — the diagnosis is harder than it would have been with engineered code because the tooling for low-code debugging is immature.

The healthy pattern, which is harder to sell but what actually works: treat low-code as a product engineering discipline with its own lifecycle — version control for configurations, staging environments, code-review equivalents for significant changes, testing, documentation, ownership. Call it "citizen development" if that helps. But the marketing promise of "no code means no governance" is false, and plants that believe it accumulate what I call the Low-Code Governance Debt — configuration complexity that grew without discipline and that eventually has to be paid down under worse conditions than it was accumulated.

From building a cloud-native MES from scratch over the past decade: the single most consequential decision in the SYMESTIC platform architecture — the one that determined almost everything about how the system operates today at 15,000+ connected machines across 18 countries, and the one that I would take the same way if I had to do it again — was the decision in the mid-2010s to not migrate the existing on-premise product to the cloud and instead to rebuild from scratch as cloud-native. This was controversial internally, it consumed about three years of engineering effort that could have gone into features, and for the first 18 months it produced no visible customer value. The temptation to do lift-and-shift — take the existing monolith, put it in a container, run it in Azure, call it cloud-MES — was constant, because it was the faster path to being able to say "we're in the cloud" in sales conversations. We resisted it for a specific reason that I have since seen play out across dozens of customer architectures: a lift-and-shifted monolith is not just "worse than cloud-native"; it is operationally worse than the original on-premise product, because it inherits all the monolithic constraints (coordinated releases, shared database bottlenecks, no horizontal scaling, brittle upgrade paths) while also paying the cloud tax (network latency, multi-tenancy isolation concerns, cost variability, dependency on cloud-vendor reliability). The only way to get the benefits of cloud — elastic scaling, per-service release cadences, resilience, geographic distribution, managed-service leverage — is to actually be cloud-native, which means rebuilding around microservices, event-driven integration, stateless service design, infrastructure-as-code, observability-first engineering, and a shared canonical data model governed at platform level. When I watch competitor architectures described as "cloud-native" that turn out to be IaaS-hosted monoliths, the failure signature is always the same: customer onboarding takes months rather than days because every customer gets their own instance; the vendor cannot roll out features selectively because every release is coordinated across all customers; customer data is either shared across tenants (security problem) or duplicated (cost and complexity problem); and the vendor's own engineering velocity grinds to a halt around the third year because the monolith has accumulated a decade of customer-specific customisations that no individual engineer fully understands. A real cMES, built with actual microservice boundaries and an actual event-streaming backbone and an actual governed canonical data model, onboards a new customer in hours, releases new features to selected customers without touching the rest, scales to workload spikes automatically, and costs less to operate per customer at 1,000 customers than at 10 because the fixed engineering costs are spread across all tenants on shared infrastructure. The gap between composable-washing and genuine cMES is not a marketing distinction; it is the entire business model. And the tell — the way to diagnose which category a vendor is actually in before committing — is to ask three specific questions: how many microservices does your platform run in production (single digits is monolith, dozens-to-hundreds is real microservices), what is your event bus (if the answer is "we have an API" you are talking to a monolith, if the answer is "Kafka / Event Hubs / Pulsar with a schema registry" you are talking to the real thing), and how do you handle cross-service consistency (if the answer is "distributed transactions" you are talking to a monolith in disguise, if the answer involves sagas and eventual consistency you are talking to engineers who have actually built one of these). The answers are rarely in the marketing deck; they are in the 45-minute technical deep-dive that a serious evaluation requires.

The Composable-Washing problem — how to evaluate vendor claims

Given the value the market is assigning to the word "composable" in 2026, the supply of composable-badged products has massively exceeded the supply of actually composable architectures. Evaluating vendor claims requires looking past the marketing vocabulary to the architectural facts. The three diagnostic questions from the amber above generalise into a broader evaluation framework:

None of the "genuine" signals above require taking the vendor's word. They are all verifiable through a technical diligence conversation with the vendor's engineering team, which serious evaluation processes should include and which consistently separates architectures that will work in production from those that will not. A vendor that refuses or cannot accommodate a 45-minute technical architecture review with customer-side engineering is almost always a vendor whose architecture would not survive the review.

Adoption paths — greenfield vs. brownfield

Composable MES is adopted through two very different pathways, and choosing the wrong one for the situation is a frequent cause of failed programmes.

Greenfield adoption is available to organisations that are either building a new plant from scratch or that have no meaningful existing MES footprint and are starting fresh. This is the easier pathway: a cMES platform is selected, configured, populated with the canonical model for the first production areas, connected to the ERP and to machines, and rolled out to additional areas incrementally. The first capability typically goes live in days to weeks (performance metrics, OEE dashboard); the second and third in further weeks; full coverage in months. Greenfield cMES adoptions have the highest success rate because they avoid the hardest problem of all, which is legacy integration.

Brownfield adoption is what most plants actually face: a pre-existing MES (typically monolithic, often built in the 2000s or 2010s, often deeply customised, often running on hardware that should have been retired years ago), integrations to ERPs and other enterprise systems that are working but fragile, operator workflows that have been built around the current system's specific behaviour, and regulatory or customer-compliance dependencies on the current system's output formats. Moving from this state to cMES is not a deployment project; it is a multi-year architectural migration, and the strategy matters enormously. The two viable patterns are:

1. Strangler-fig migration. New capabilities are built on the cMES platform, with bidirectional integration back to the legacy MES for the functions that have not yet migrated. Over 18–36 months, functions are moved from legacy to cMES one at a time, with the legacy MES shrinking at each step until it can be retired. This is the lower-risk path but requires strong integration engineering.
2. Parallel-run cutover. The cMES is implemented in parallel to the legacy MES for a single plant or production area, both systems run simultaneously for a validation period (typically 2–6 months), results are reconciled, and the legacy MES is retired when the cMES is proven. This is the higher-risk path but can be faster for well-defined scopes.

The pattern that consistently fails is the "forklift upgrade" — turning off the legacy MES on a scheduled weekend and turning on the cMES — which has the same failure dynamics as any big-bang system replacement and is the reason so many MES modernisations end badly.

How this fits into the SYMESTIC platform

SYMESTIC is a genuinely cloud-native, microservice-architected, API-first, event-driven MES platform, built from the ground up around the patterns described in this piece — not retrofit from a monolith, not module-organised, not cloud-hosted in the degraded sense. The platform runs on Microsoft Azure using AKS for container orchestration, Azure Event Hubs for event streaming, Azure SQL and Cosmos DB for service-specific persistence, and a governed canonical data model covering approximately 80 core entity types and 200 event types, with schema evolution rules and CI-enforced compatibility. Customer onboarding typically completes in days because new tenants are provisioned into the existing multi-tenant infrastructure rather than instantiated as new systems; new capabilities arrive continuously rather than on quarterly release trains; and per-customer customisations are handled through a governed low-code layer that shares the canonical data model rather than forking it. The service catalogue maps directly onto the MESA-11 and ISA-95 functional models described above — production metrics, production control, production planning, alarms, and process data are each bundle presentations of clusters of underlying services, not distinct modules. For customers starting greenfield, the platform is typically productive on the first capability in under two weeks. For customers with existing MES footprints, SYMESTIC supports both strangler-fig and parallel-run migration patterns through its API and event-streaming integration surfaces. See also process documentation for the ISA-95 modelling baseline, industrial data historian for the time-series backbone that complements the event-streaming layer, E2E traceability and change control for two of the capability domains that most benefit from a composable architecture, alarm management for the event-subscription patterns applied to plant-floor signals, and A3 problem solving for the discipline that makes use of all the data the platform surfaces.

FAQ

What is Composable MES?
A Manufacturing Execution System built as an orchestrated collection of independently deployable, API-addressable services rather than as a monolithic application, with a shared canonical data model binding the services together and an event-streaming backbone carrying state changes between them. The architectural properties are usually summarised under the MACH acronym: Microservices, API-first, Cloud-native, Headless.

What is MACH architecture?
MACH stands for Microservices, API-first, Cloud-native, Headless — four architectural properties that together define composable systems. The term was coined by commercetools in 2020 and institutionalised by the MACH Alliance. A system that lacks any one of the four properties is not composable in the strong sense, regardless of marketing claims. MACH is the manufacturing-domain application of Gartner's 2020 "Composable Enterprise" concept.

How does Composable MES differ from modular MES?
Modular MES refers to a monolithic system organised into logically separated modules that share a database and a deployment lifecycle; composable MES refers to genuinely independent services with separate data stores, separate deployment lifecycles, and integration through APIs and events rather than through shared state. The difference is architectural, not cosmetic. Most systems marketed as "composable" in 2026 are actually modular — a failure mode called composable-washing.

What is the shared canonical data model and why does it matter?
The canonical data model is the versioned set of entity and event definitions that all services in a composable MES agree on — what a work order is, what a unit is, what a quality result is, in precise terms with explicit ownership and evolution rules. It is the single most consequential architectural element in cMES because without it, each new service develops its own local definitions of shared concepts and the system degenerates into the same point-to-point integration nightmare that composability was supposed to eliminate. The canonical model is also the most expensive and most consistently underinvested part of cMES operation.

What is The Integration Tax?
The pattern in which the marginal cost of adding each new module to a composable system grows superlinearly over time because the canonical data model has drifted and every new integration has to reconcile not just with the new module but with the accumulated inconsistencies of all prior modules. Plants that do not invest in canonical-model governance typically hit this failure around the 18-month mark after initial rollout, at which point adding capabilities becomes more expensive than it was at launch rather than cheaper.

What is Composable-Washing?
The practice of marketing modular-monolithic or cloud-hosted systems as "composable MES" without delivering the underlying architectural properties (genuine microservices, API-first contracts, cloud-native deployment, event-driven integration, governed canonical data model). Common in the 2025–2026 MES market as the term "composable" acquires premium pricing power. Diagnosable through specific technical-diligence questions — how many services are in production, what is the event bus, how is cross-service consistency handled.

What technology stack does a real cMES use?
In 2026, the mainstream stack is: Kubernetes (managed via AKS, EKS, or GKE) for container orchestration; Apache Kafka, Apache Pulsar, or a cloud-managed equivalent (Azure Event Hubs, AWS Kinesis) for event streaming; a schema registry (Confluent, AWS Glue, or equivalent) for canonical-model governance; OpenTelemetry + Prometheus + Grafana + Jaeger for observability; OpenAPI and AsyncAPI for contract definition; an API gateway (Kong, Ambassador, Istio) for ingress control; and GitOps pipelines (ArgoCD, Flux) for deployment. None of this is exotic in 2026; the complexity is not in the technology choices but in applying them correctly to the manufacturing problem.

How is cMES adopted in brownfield plants?
Two viable patterns: strangler-fig migration (new capabilities are built on the cMES platform with bidirectional integration to the legacy MES, and functions are moved one at a time over 18–36 months until the legacy can be retired) and parallel-run cutover (cMES is implemented in parallel for a single plant or area, both systems run simultaneously for a validation period, and the legacy is retired once cMES is proven). Forklift replacement — turning off legacy and turning on cMES on a scheduled weekend — fails with the same dynamics as any big-bang system replacement and should be avoided.

What role does low-code play in cMES?
Low-code/no-code configuration layers let non-developer users build and modify applications without writing code, which is valuable for change velocity but dangerous without governance. The healthy pattern treats low-code as a product engineering discipline — with version control, staging, code-review equivalents, testing, and ownership — rather than as an unmanaged "citizen development" playground. Plants that treat low-code as ungoverned accumulate Low-Code Governance Debt that eventually has to be paid down under worse conditions.

Does cMES replace ISA-95 or MESA-11?
No. cMES changes how the MES functions are packaged, deployed, and integrated, not what they are. The classical ISA-95 Level 3 activity model and the MESA-11 (now MESA Strategic Initiatives) functional model remain the correct conceptual vocabulary for MES capabilities. cMES is the architectural answer to the question "how should these functions be implemented in 2026?" rather than a rejection of the question itself.

Related: MES: definition, functions & benefits · OEE: definition, calculation & practice · MES software compared · OEE software · Process documentation (ISA-95 baseline) · Alarm management · Shop floor control (SFC) · Predictive quality · Schedule adherence · On-Time Delivery · Rolled Throughput Yield · Scrap rate vs. rework rate · Industrial data historian · Recipe management · Change control · A3 problem solving · E2E traceability · MDE (machine data acquisition) · BDE (production data acquisition) · Production metrics module · Production control module · Production planning module · Alarms module · Process data module · Automotive · Metal processing · Food & beverage · For COOs & plant managers · For operational excellence. External references: MACH Alliance (industry body for MACH architecture, founded 2020) · Gartner Composable Business research (origin of the Composable Enterprise concept) · ISA-95 standard committee (Level 3 activity model for MES functions) · MESA International (MESA-11 / Strategic Initiatives functional framework) · Cloud Native Computing Foundation (stewards of Kubernetes, Prometheus, OpenTelemetry, Jaeger and most of the cloud-native stack referenced in this piece).

About the author

Mark Kobbert

CTO of SYMESTIC GmbH, responsible for the cloud-MES architecture since 2014. B.Sc. Business Informatics (SRH Hochschule Heidelberg). Led the mid-2010s rebuild of the SYMESTIC platform from an on-premise monolith to a cloud-native, microservice-architected, event-driven system running on Microsoft Azure with Kubernetes orchestration, Azure Event Hubs for event streaming, and a governed canonical data model covering 80+ core entity types across 18 countries and 15,000+ connected machines. Expertise: cloud-native MES architecture, Microsoft Azure, microservice architecture, OPC UA, MQTT, IoT-gateway development, Edge Computing, ISA-95 integration architecture, industrial connectivity, brownfield machine connectivity, REST APIs, C#/.NET, SQL, Docker/Kubernetes, real-time data processing, IT/OT convergence. · LinkedIn