Where Does the Business Logic Reside? SAP, MES, or Middleware?

When integrating a Manufacturing Execution System (MES) with SAP S/4HANA, one of the most critical — yet often underestimated — architectural decisions is:

Where should the business logic reside?

It may seem like a minor technical detail, but poor decisions here can lead to massive long-term pain: scattered responsibilities, duplicated rules, hard-to-maintain code, and fragile systems that break with every minor change.

Let’s break it down.

The Common Trap: Spreading the Logic

In many integration projects, business logic ends up distributed across three layers:

• SAP: holds the enterprise data, order management, and inventory logic, often with custom Z-functions and workflows.

  
  

• MES: handles the real-time operational logic, execution control, traceability, and production rules.

  
  

• Middleware: ends up acting as the "glue" that includes transformation rules, validations, fallback logic, and sometimes even routing decisions.

This setup might “work” for a single-site deployment, but becomes a nightmare when you want to scale, audit, or evolve the system.

Backend developer

Architecture Best Practice: One Brain per Layer

To build robust, maintainable, and scalable architectures, logic distribution must follow this principle:

1. SAP: The Corporate Brain

• Owns the master data, financials, materials, planning, and inventory.

• Sends manufacturing orders to the MES.

• Expects structured feedback (quantities, confirmations, time, material consumption) back from production.

  
  

2. MES: The Operational Brain

• Owns the execution: sequencing, traceability, machine events, operator actions, quality checks.

• Must be designed to run independently from ERP during production, syncing data back when network or systems recover.

  
  

3. Middleware: The Transport Layer

• Should be “smart plumbing”, not “half-a-brain”.

• It transports, transforms, orchestrates, and buffers, but should NOT hold business logic.

  
  

  Real-World Consequences

  
  

What happens when middleware gets “too smart”?

• You hide logic in places where nobody looks.

• Updates require coordination across multiple tools and teams.

• Audits and troubleshooting take forever.

• Scaling to other sites becomes copy-paste hell.

A Real Example

In a recent project, the MES handled all machine events and order execution, SAP managed all materials and batch info, and a middleware layer (SAP MII + APIs) was introduced to synchronize both worlds.

At first, it worked fine.

But over time, the middleware started “absorbing” logic: business rules for partial confirmations, error re-routing, even validation of order structures.

After 18 months, the client had no idea where the actual logic lived. Go-live issues were impossible to debug, and every change was a mini-project.

We had to refactor the entire stack to cleanly separate responsibilities again.

Lesson learned: define the boundaries early, and defend them throughout the project.

Integration Checklist

Before any line of code is written, answer these:

• What logic belongs strictly to SAP?

• What decisions must be made in the MES at execution time?

• What should be purely transport/orchestration?

• Is there any logic in the middleware that we can eliminate or push up/downstream?

Final Thoughts

A robust SAP–MES integration is not just about interfaces or data flow. It’s about clarity of ownership.

When every layer has a clear role, your system is faster to deploy, easier to support, and ready to scale.

So, next time someone says “we’ll just handle that logic in the middleware”, stop them.

Ask instead:“Why? Who will own it? And what happens when we scale?”

Have you faced similar challenges in integration projects? Where do you usually place the business logic?Let’s discuss it — I’m always keen to hear real-world strategies.