Module 1: Introduction to Integration Architecture

Integration architecture is the discipline of designing how systems talk to each other. In a world where the average enterprise runs hundreds of applications — ERPs, CRMs, SaaS platforms, internal microservices, legacy mainframes — making them communicate reliably, securely, and efficiently is one of the hardest engineering problems organisations face. This module introduces the discipline, the role, and the vocabulary you will use throughout this training.

Overview of Integration Architecture

Integration architecture defines the structures, standards, and patterns that govern how applications, services, and data sources exchange information within and across organisational boundaries.

It sits at the intersection of:

• Business process design — understanding what data needs to flow and why
• System design — understanding the technical capabilities and constraints of each system
• Operational engineering — ensuring integrations are observable, maintainable, and recoverable

Integration is not just "connecting two systems." A single integration between an ERP and a warehouse management system can involve:

• Data transformation (different schemas, formats, and field mappings)
• Protocol translation (REST to SOAP, HTTP to AMQP)
• Routing logic (which warehouse receives which order)
• Error handling (what happens when the warehouse system is down)
• Security controls (authentication, encryption, audit logging)
• Monitoring (latency, throughput, error rates)

Integration architecture provides the frameworks and decisions that make all of this manageable at scale.

Role and Responsibilities of an Integration Architect

The Integration Architect sits between business stakeholders, system owners, and delivery teams. The role spans strategy, design, and technical oversight.

Core Responsibilities

Strategic

• Define the integration strategy and standards for the organisation
• Evaluate and select integration platforms and middleware
• Build and maintain the integration roadmap
• Champion reuse — prevent teams from solving the same integration problem independently

Design

• Lead integration requirements workshops with business and technical stakeholders
• Produce integration design documents, including sequence diagrams, data flow diagrams, and interface contracts
• Select appropriate integration patterns for each use case
• Identify and mitigate risks in integration designs before build begins

Technical Oversight

• Review integration implementations against design standards
• Define API and messaging contracts, versioning policies, and deprecation processes
• Establish monitoring, alerting, and SLA requirements for integration flows
• Provide hands-on guidance to developers on pattern implementation and tooling

Governance

• Maintain an integration registry (what integrates with what, and how)
• Enforce naming conventions, error handling standards, and security policies
• Manage change requests that affect integration interfaces

What Integration Architects Are Not

• They are not solely responsible for writing integration code (though they often can and do)
• They are not system architects for individual applications — they focus on boundaries and flows, not internal system design
• They are not project managers — though they must plan and estimate integration work accurately

Understanding the Importance of Integration in Modern Enterprises

The Integration Problem at Scale

Modern enterprises do not run on a single monolithic system. They run on dozens or hundreds of systems that evolved independently, were acquired, or were built by different teams at different times. Each system has its own:

• Data model and terminology
• Communication protocol and API style
• Availability characteristics and SLAs
• Ownership and change cadence

Without intentional integration architecture, organisations end up with:

• Brittle point-to-point connections — every system talks directly to every other system, creating a tangled web that nobody fully understands
• Data inconsistency — the same customer record exists in five systems with five different values for "email address"
• Duplication of effort — three teams build three slightly different adapters to the same third-party API
• Invisible failures — data silently stops flowing because a network timeout is not handled

Why Integration Is a Strategic Capability

Integration enables:

• Digital transformation — connecting legacy systems to modern cloud platforms without a full rewrite
• Mergers and acquisitions — integrating acquired company systems quickly
• Customer experience — surfacing data from back-office systems to customer-facing applications in real time
• Automation — eliminating manual re-keying of data between systems
• Agility — adding or replacing a system without rewriting every integration it participates in

Organisations with mature integration architecture move faster and with less risk. Those without it accumulate technical debt with every new system they add.

Integration Patterns and Styles

Before choosing any technology, an Integration Architect must understand the fundamental patterns and styles available. These are technology-agnostic — they describe the shape of a solution, not its implementation.

Integration Styles

File Transfer
System A writes a file; System B reads it. Simple, widely supported, but inherently asynchronous with no real-time capability.

When to use: Batch processing, bulk data loads, legacy system integration where no API exists.

Shared Database
Two systems read and write to the same database. Tight coupling — changing the schema breaks both systems.

When to use: Avoid if possible. Acceptable only for tightly owned systems within a single team boundary.

Remote Procedure Call (RPC) / Request-Reply
System A calls System B synchronously and waits for a response. HTTP REST and gRPC are the dominant modern forms.

When to use: Real-time queries, command execution where the caller needs an immediate result.

Messaging
System A sends a message to a channel; System B consumes it. Decoupled, asynchronous, resilient.

When to use: Event notifications, workflow automation, high-throughput pipelines, decoupling systems with different availability characteristics.

The Four Classic Integration Patterns (Hohpe & Woolf)

The Enterprise Integration Patterns book by Gregor Hohpe and Bobby Woolf (2003) remains the canonical reference. Its core patterns:

Message Channel — the pipe through which messages flow (queue, topic, event stream)

Message — the unit of data in transit: a header (routing metadata) plus a body (payload)

Message Router — decides which channel a message should go to based on its content or headers

Message Translator — converts a message from one format to another

Message Endpoint — the connection point between a system and a messaging channel

These five building blocks compose into every integration solution you will ever build.

Integration Topology Patterns

Point-to-Point
Each sender connects directly to each receiver. Simple for two systems; becomes exponentially complex as the number of systems grows.

System A ──► System B
System A ──► System C
System B ──► System C

n systems = n(n-1)/2 potential connections. At 10 systems: 45 connections. At 20 systems: 190.

Hub-and-Spoke
All systems connect to a central hub (an integration broker or ESB). The hub routes, transforms, and mediates all messages.

System A ──►
System B ──► HUB ──► System C
System D ──►         System E

Reduces connection count but creates a single point of failure and a bottleneck.

Bus / Publish-Subscribe
Systems publish events to a shared channel; interested systems subscribe. No central router — routing is defined by subscriptions.

System A ──► Event Bus ──► System C (subscribed)
                       ──► System D (subscribed)

Highly decoupled. The publisher does not know or care who consumes its events.

Synchronous vs Asynchronous Integration

| Characteristic | Synchronous | Asynchronous | |---|---|---| | Coupling | Temporal (both must be up) | Decoupled | | Latency | Low (immediate response) | Higher (eventually processed) | | Resilience | Fails if either party is down | Survives transient failures | | Complexity | Simple request/response | Requires message broker, idempotency | | Use cases | Queries, real-time commands | Events, notifications, workflows |

Most enterprise integrations benefit from asynchronous messaging. Synchronous calls are appropriate when the caller genuinely cannot proceed without an immediate answer.

Key Vocabulary

| Term | Meaning | |------|---------| | Integration point | A boundary where data or control passes between two systems | | Canonical data model | A shared data format that all systems translate to/from | | Adapter / connector | Code that translates a system's native protocol into the integration layer | | Orchestration | A central coordinator drives the integration workflow | | Choreography | Systems react to events independently — no central coordinator | | Idempotency | Processing a message more than once produces the same result as processing it once | | At-least-once delivery | The broker guarantees delivery but may deliver duplicates | | Exactly-once semantics | The hardest guarantee — message processed exactly once, no duplicates |

Module Summary

• Integration architecture designs how systems exchange information — it is a distinct discipline from individual system design.
• The Integration Architect owns strategy, design, technical oversight, and governance across system boundaries.
• Integration is a strategic capability: organisations with mature integration practices move faster, take on less risk, and recover from change more quickly.
• Core integration styles are: file transfer, shared database, RPC/request-reply, and messaging.
• The fundamental topology choices are: point-to-point, hub-and-spoke, and publish-subscribe.
• Synchronous integration is simple but fragile; asynchronous messaging is more complex but more resilient.

Next: Module 2 — Enterprise Integration Technologies