As an online shop grows, so does the number of its systems: ERP, PIM, CRM, shipping, payment, marketplaces. Many businesses initially connect these systems directly to each other - point-to-point. What works with two or three systems becomes so-called spaghetti architecture with five or ten. The result: rising maintenance costs, fragile processes, and an integration backlog that stifles innovation. A well-designed middleware architecture solves this problem fundamentally.
What Is Point-to-Point Integration?
In a point-to-point integration (also called direct integration), each system is connected to every other system via an individual interface. The online shop communicates directly with the ERP system, the ERP directly with the shipping provider, the shop directly with the PIM system and so on.
This approach is understandable - it is the fastest way to connect two systems. But the math is clear: the number of connections grows according to the formula n x (n-1) / 2. With 5 systems, that is 10 connections; with 10 systems, it is already 45; and with 15 systems, there are 105 individual interfaces.
A typical mid-sized e-commerce operation works with 8-12 systems (shop, ERP, PIM, CRM, shipping, payment, marketplaces, accounting, newsletter, analytics). With 10 systems, point-to-point integration results in 45 individual connections - each with its own code, error handling, and maintenance overhead.
Why Point-to-Point Integrations Fail
The MuleSoft Connectivity Benchmark Report 2025 shows: on average, companies use 897 applications, yet only 2% have integrated more than half of them (MuleSoft/Vanson Bourne). This integration gap has concrete causes:
Exponential Complexity
Each new system multiplies the number of connections. What was manageable with 3 systems becomes uncontrollable with 10.
Fragile Dependencies
When one system changes its API, all connected interfaces break simultaneously. A single update can trigger a chain reaction.
No Central Monitoring
Without a central hub, there is no overview: Which data flows where? Where is the error? When did the last sync run?
Add to this the factor of integration debt - the technical debt that accumulates from quick, unstructured integrations. Gartner estimates the annual cost of poor data quality at an average of $12.9 million per organization (Gartner). A significant portion of this traces back to fragmented and faulty integrations.
Typical E-Commerce Integration Scenarios
A modern e-commerce operation must orchestrate a multitude of systems - from ERP to returns management to shipping and payment. Each system has its own data formats, APIs, and update cycles:
| System | Data Flow | Typical Frequency |
|---|---|---|
| ERP (SAP, Dynamics) | Orders, inventory, prices, customers | Real-time to hourly |
| PIM System | Product data, media, attributes | Daily to hourly |
| CRM | Customer data, interactions, segments | Real-time |
| Shipping (DHL, DPD) | Shipments, tracking, returns | Event-driven |
| Payment (Stripe, PayPal) | Transactions, refunds | Real-time |
| Marketplaces (Amazon, eBay) | Listings, orders, inventory | 15-60 minutes |
| Accounting (DATEV) | Invoices, receipts, postings | Daily |
With point-to-point integrations, each of these connections requires its own solution. Introducing a new ERP system then means not one change, but six or more - a separate adaptation for each connected system.
The Middleware Concept: Central Integration Layer
A middleware - also called an integration layer - is a central intermediary layer between all participating systems. Instead of each system communicating directly with every other, all systems communicate only with the middleware. It handles data transformation, routing logic, and error handling.
The decisive advantage: with n systems, n x (n-1) / 2 connections become just n connections. With 10 systems, the number drops from 45 to 10 - a reduction of over 75%. Each system only needs to provide one interface instead of nine different ones.
Middleware decouples systems from one another. A system does not need to know which other systems need its data - it delivers data to the middleware, which distributes it according to configured rules. This reduces dependencies and makes individual systems replaceable.
Building Blocks of an Integration Layer
A professional integration architecture consists of several components that work together:
API Gateway
Central access point for all incoming and outgoing API calls. Handles authentication, rate limiting, and versioning.
Message Queue
Asynchronous message queue for event-driven communication. Decouples senders and receivers temporally.
Data Transformation
Converts data between different formats and structures - for example from SAP IDocs to REST JSON or vice versa.
Error Handling
Central dead-letter queue, automatic retry mechanisms, and alerting for synchronization problems.
Monitoring and Logging
Central dashboard for all data flows, throughput metrics, and error logs in real-time.
Orchestration
Coordinates multi-step processes like order processing: check inventory, authorize payment, create shipping label.
Real-Time vs. Batch: The Right Synchronization Strategy
Not every data flow requires real-time synchronization. A well-designed integration architecture deliberately distinguishes between different synchronization patterns - because real-time is more complex and not always necessary.
| Pattern | Use Case | Examples |
|---|---|---|
| Real-Time (Event-Driven) | Business-critical data that must be available immediately | Orders, payments, inventory changes |
| Near-Realtime (5-15 min.) | Important data with moderate tolerance | Marketplace sync, price changes |
| Batch (hourly/daily) | Large data volumes without real-time requirements | Product data import, DATEV export, reporting |
Event-Driven Architecture (EDA) is the paradigm for real-time scenarios: when a customer places an order, the shop generates an event. Multiple services - inventory management, payment, shipping - react to this event independently. This architecture allows individual components to scale independently. During a flash sale, order processing can be scaled up without affecting the entire system.
Start with the question: which business processes truly require real-time? In practice, 15-minute intervals are sufficient for many scenarios. True real-time (sub-second) should only be deployed where the business genuinely cannot wait - such as inventory checks during checkout.
API Management as Foundation
APIs are the language in which modern systems communicate. The MuleSoft Connectivity Benchmark Report 2025 shows: APIs and API-based implementations now account for 40% of company revenue - up from 25% in 2018 (MuleSoft). Professional API management is therefore not an optional feature but business-critical infrastructure.
Central API management encompasses versioning (so that an API update does not break all consumers simultaneously), authentication and authorization (OAuth, API keys), rate limiting (protection against overload), documentation (self-describing APIs for faster development), and monitoring (detection of latencies and errors in real-time).
For e-commerce scenarios, API management is particularly relevant when connecting marketplaces like Amazon or eBay, integrating SAP Business One or Microsoft Dynamics, synchronizing with DATEV or JTL-Wawi, and connecting shipping providers and payment processors. The automated DATEV integration in particular benefits significantly from a central middleware layer.
Comparison: Point-to-Point vs. Middleware Architecture
| Criterion | Point-to-Point | Middleware |
|---|---|---|
| Connections with 10 systems | 45 individual | 10 central |
| Connect new system | Up to 9 new connections | 1 new connection |
| Replace a system | Modify all connections | Modify only 1 adapter |
| Error analysis | Check system by system | Central monitoring |
| Data transformation | In each connection individually | Central and reusable |
| Initial complexity | Low | Medium to high |
| Long-term maintenance | Exponentially increasing | Linearly increasing |
| Scalability | Limited | High |
When Is Middleware Architecture Worth It?
Not every company needs a full integration layer right away. For a simple 1:1 connection between online shop and ERP, a direct integration may be the more efficient solution. In our experience, a middleware architecture pays off once:
- More than 4-5 systems need to be integrated
- Multiple marketplaces and sales channels are connected
- System changes are foreseeable (e.g., ERP migration, headless commerce)
- Data quality is a problem and central validation is needed
- Different synchronization patterns (real-time, batch, event-driven) run in parallel
- Compliance requirements demand central logging and traceability
The trend is clear: 70% of mid-market companies have now adopted composable architecture over monolithic systems (Gartner). And over 80% of CIOs plan to increase their investments in integration technologies and APIs according to the Gartner CIO Survey 2025 (Gartner).
The Path to Professional Integration Architecture
Implementing a middleware architecture is not a big-bang project but an evolutionary process. From our consulting experience, we recommend a step-by-step approach:
- Inventory: Document all systems, data flows, and existing integrations
- Prioritization: Identify business-critical integrations to migrate first
- Architecture design: Design the integration layer with cloud infrastructure for scalability
- Gradual migration: Transition existing point-to-point connections to the middleware one by one
- Build monitoring: Set up a central dashboard for all data flows
- Continuous optimization: Monitor performance metrics and refine processes
A professionally implemented integration layer typically pays for itself within 12-18 months. Savings arise from reduced maintenance effort, faster onboarding of new systems, and fewer errors from data inconsistencies.
Common Mistakes in Integration Planning
From numerous integration projects, we know the typical pitfalls that companies should avoid when planning and implementing:
- Missing data strategy: Without a clear data model and defined responsibilities (which system is the authority for which data?), even well-planned integrations fail
- Over-engineering: Not every integration needs real-time. Synchronizing everything in real-time creates unnecessary load and complexity
- Missing error handling: What happens when a synchronization fails? Without dead-letter queues, retry mechanisms, and alerting, data is lost
- No versioning: APIs change. Without versioning, every update causes outages for all consumers
- Vendor lock-in: Implementing integration logic in a single proprietary system creates dependency
- Lack of documentation: When only a few individuals know how the integrations work, a critical knowledge risk emerges
The MuleSoft report confirms: 80% of organizations see data silos as the biggest barrier to automation and AI initiatives (MuleSoft/Vanson Bourne). A well-designed integration architecture is therefore not just a technical but a strategic decision.
This is what your integrated B2B shop could look like:
Industrieteile-Portal
Middleware is an overarching concept for software that serves as an intermediary layer between systems. iPaaS (Integration Platform as a Service) is a cloud-based variant of this concept. Both pursue the same goal - decoupling and orchestrating systems - but differ in deployment model and operational responsibility. Which variant fits depends on individual requirements.
In our experience, a middleware architecture becomes worthwhile from 4-5 integrated systems onward. With fewer systems, a direct integration may be more efficient. What matters is not just the number but also the complexity of data flows and whether system changes are foreseeable.
That depends on the number of existing integrations and the complexity of business processes. Typically, the initial architecture and migration of the first 2-3 critical integrations takes 2-4 months. Additional integrations can then be added incrementally in 2-4 weeks per system.
Yes, a gradual migration is the recommended approach. You start with the most business-critical or maintenance-intensive integrations and migrate them to the new architecture while the remaining integrations continue to run. This minimizes risk.
Not necessarily. An integration layer can be operated on-premise, in the cloud, or as a hybrid solution. Cloud-based approaches offer the advantage of automatic scaling and lower operational overhead. The choice depends on compliance requirements and existing infrastructure.
Costs vary significantly depending on scope and complexity. A realistic budget for mid-sized e-commerce companies is typically in the five-figure range. Contact us for an individual assessment based on your system landscape.
This article is based on data from: MuleSoft Connectivity Benchmark Report 2025 (MuleSoft/Vanson Bourne/Deloitte Digital, 1,050 IT decision-makers worldwide), Gartner (data quality costs, CIO Survey 2025), Gartner Market Research (composable architecture adoption). The cited figures may vary by industry and timing.
Plan Integration Architecture
We analyze your system landscape and develop a scalable integration strategy - from concept to implementation.
Request Consultation