Core Concepts (Part 2)
1. Beyond SAP
In the previous article we examined the integration mechanisms that exist within the SAP ecosystem — CSV uploads, FTP transfers, IDocs, RFCs, APIs, and SAP’s own integration platforms. Those tools describe how SAP exchanges data.
But they do not explain the deeper question that determines whether integrations succeed or fail: how systems communicate with each other conceptually.
Outside SAP, entire disciplines exist around integration architecture. These disciplines deal with questions such as whether communication should happen instantly or later, whether systems should wait for responses or proceed independently, whether messages should be queued, streamed, or stored temporarily, and how systems remain resilient when something inevitably fails.
Functional consultants do not need to become architects in these domains. But they should understand the core concepts well enough to recognise why a particular design may succeed or fail.
2. Synchronous Communication
The first concept is synchronous communication.
Analogy: A synchronous interaction is like a telephone call. One party calls the other and waits for an immediate answer.
In system terms, a synchronous integration means that System A sends a request and waits until System B responds before continuing the process.
This approach is common in situations where the response is required immediately. For example, an e-commerce website might call a payment gateway to authorise a credit card transaction. The order cannot proceed until the payment is approved or rejected.
Advantages
- Immediate confirmation
- Clear transactional consistency
- Simpler process logic
Disadvantages
- Both systems must be available simultaneously
- Performance delays propagate across systems
- Failures can interrupt entire business processes
Synchronous integrations are therefore powerful but fragile. They work well when responses must be instant, but they create tight coupling between systems.
3. Asynchronous Communication
The alternative approach is asynchronous communication.
Analogy: Instead of a phone call, imagine sending a letter. The sender posts the message and continues with other work. The receiver processes it when it arrives.
In asynchronous integrations, System A sends a message to System B but does not wait for an immediate reply.
Many traditional SAP integrations, particularly IDocs, work this way.
Advantages
- Systems remain independent
- Failures can be retried later
- High scalability
Disadvantages
- Responses may be delayed
- Process monitoring becomes more complex
- Error handling requires careful design
Asynchronous integrations introduce resilience. If one system becomes temporarily unavailable, messages can simply wait until processing resumes.
4. Real Time
Another frequently misunderstood term is real-time integration.
Real-time does not necessarily mean instantaneous. It usually means that the delay between systems is small enough to support operational decision-making.
For example, when a warehouse management system updates inventory levels immediately after a shipment is processed, that information may flow into SAP within seconds. For operational purposes, that is considered real time.
Real-time integrations are useful when business decisions depend on current information — inventory availability, pricing updates, or fraud detection.
However, real time also increases architectural pressure. Systems must handle higher transaction volumes and respond quickly under load.
5. Batch Processing
The opposite approach is batch processing.
Instead of exchanging data continuously, systems accumulate transactions and process them periodically.
Payroll calculations, financial postings, and large data migrations often rely on batch integrations.
Batch processing has several advantages.
- It reduces system load during peak business hours
- It simplifies data reconciliation
- It allows large volumes of data to be processed efficiently
The drawback is latency. Information may be several hours old before it appears in the target system.
Choosing between real-time and batch integration is therefore not a technical decision alone. It is fundamentally a business timing decision.
6. Message Queues
As integration landscapes grow more complex, organisations introduce message queues.
A queue works like a waiting line. Systems place messages in the queue, and other systems process them when ready.
Technologies such as RabbitMQ, Apache Kafka, and IBM MQ are widely used for this purpose.
Advantages
- Prevents system overload
- Enables reliable message delivery
- Supports asynchronous communication
Disadvantages
- Adds architectural complexity
- Requires monitoring and governance
Queues are particularly useful when transaction volumes fluctuate. They allow systems to absorb sudden spikes without failing.
7. Data Streaming
A newer concept gaining importance is data streaming.
Traditional integrations move data in batches or discrete messages. Streaming systems treat data as a continuous flow.
Platforms such as Apache Kafka allow organisations to process streams of events in near real time.
For example, a logistics company might stream GPS events from thousands of delivery vehicles, updating dashboards and analytics systems continuously.
Streaming architectures are increasingly common in industries such as finance, telecommunications, and large-scale e-commerce.
8. Loose Coupling
Perhaps the most important architectural idea is loose coupling.
A loosely coupled system allows components to operate independently. If one system becomes unavailable, the others continue functioning until the connection is restored.
Tightly coupled systems behave very differently. When one component fails, the entire chain stops.
Modern integration architecture increasingly favours loose coupling because it improves resilience and scalability.
Functional consultants may not design these architectures, but they influence them indirectly when they describe business processes. A process that requires immediate confirmation for every step will naturally lead to tightly coupled integrations.
A process that tolerates delayed updates allows for more resilient architectures.
9. Why It Matters
Integration is often treated as plumbing — something hidden beneath the surface that technical teams manage quietly. In reality, integration architecture determines how business processes behave under stress.
Does the process stop when one system is unavailable?
Do messages retry automatically?
Does information arrive immediately or in scheduled intervals?
Does the architecture handle growth gracefully?
These are business questions disguised as technical questions.
Functional consultants who understand these concepts become far more effective participants in architecture discussions. They ask better questions, challenge poor assumptions, and help design processes that survive real-world complexity.
10. The Real Objective
Integration literacy does not turn a functional consultant into a developer. That was never the goal.
The goal is far simpler.
A functional consultant who understands the language of integration becomes a far more valuable participant in system design. They can describe business behaviour precisely, anticipate failure scenarios, and collaborate intelligently with technical architects.
In short, they stop fearing integration and start shaping it.
And that is where the real value lies.
