Vocabulary for Integration Engineers

Integration engineering — connecting disparate systems, applications, and services so they can exchange data — has its own specialised vocabulary. Whether you are working with an Enterprise Service Bus, an iPaaS platform, or hand-rolling integrations using REST APIs and message queues, this vocabulary will help you communicate precisely about integration architecture.

Core Integration Concepts

Integration

In software, integration refers to the process of enabling two or more systems to exchange data and coordinate behaviour. Integration can be point-to-point, hub-and-spoke, or event-driven.

“The integration between the CRM and the billing system is currently point-to-point — if we add more systems, this will become unmaintainable.” “We’re implementing a hub-and-spoke integration model, with the ESB as the central hub.”

Point-to-Point Integration

In point-to-point integration, each system connects directly to every other system it needs to communicate with. This is simple for two or three systems but becomes complex — sometimes called a “spaghetti architecture” — at scale.

“We have twelve systems with direct point-to-point connections. Adding a new system means updating eleven existing integrations. We need a better approach.”

Hub-and-Spoke

In the hub-and-spoke model, all systems connect to a central integration layer (the hub) rather than directly to each other. The hub routes and transforms messages between spokes.

“With a hub-and-spoke architecture, adding a new system only requires one integration with the hub — not one with every existing system.”

Middleware and ESB

Middleware

Middleware is software that sits between two applications and facilitates communication between them. It can handle protocol translation, message transformation, routing, and security.

“The middleware translates between the legacy SOAP-based ERP system and the modern REST-based inventory API.” “Without middleware, each system would need to understand the data format of every other system it communicates with.”

ESB (Enterprise Service Bus)

An Enterprise Service Bus is a middleware platform that provides centralised message routing, transformation, protocol mediation, and orchestration for enterprise integrations.

“We’re using MuleSoft as our ESB. It handles routing, format transformation, and error handling for all forty-seven integrations in our enterprise landscape.” “The ESB decouples our systems — the order management system doesn’t know or care how the fulfilment system is implemented.”

Message Broker

A message broker is a middleware component that accepts messages from producers and routes them to consumers. Unlike an ESB, a message broker focuses on reliable message delivery rather than transformation.

“We use RabbitMQ as a message broker between the order service and the notification service. The order service publishes an event; the broker delivers it to all subscribers.”

iPaaS

iPaaS (Integration Platform as a Service)

iPaaS is a cloud-based integration platform that provides tools for connecting applications, data, and processes — typically without requiring on-premises infrastructure. Common platforms include MuleSoft Anypoint, Dell Boomi, Workato, and Zapier (for simpler use cases).

“We moved from an on-premises ESB to an iPaaS solution. The managed infrastructure reduced our operational overhead significantly.” “iPaaS platforms typically offer pre-built connectors for common SaaS applications like Salesforce, Workday, and ServiceNow, which accelerates integration development.”

Connectors and Adapters

Connector

A connector is a pre-built integration component that handles the authentication, API calls, and data mapping required to connect to a specific system or service.

“The Salesforce connector handles OAuth authentication and provides typed methods for querying contacts, opportunities, and accounts — we don’t have to write the HTTP calls manually.” “We built a custom connector for the legacy inventory system because no pre-built connector existed for its proprietary SOAP API.”

Adapter

An adapter (similar to a connector) is a component that translates between two incompatible interfaces or data formats.

“The XML-to-JSON adapter converts the supplier’s SOAP response into the JSON format our internal systems expect.”

Message Transformation

Message Transformation

Message transformation is the process of converting a message from one format or structure to another as it passes through an integration layer.

“The integration flow transforms the customer record from Salesforce’s format into the format expected by the ERP system before passing it on.”

Schema Mapping

Schema mapping defines how fields in a source schema correspond to fields in a target schema.

“The schema mapping document shows that Salesforce’s FirstName and LastName fields map to the ERP’s combined FullName field with a space separator.”

Data Enrichment

Data enrichment adds information to a message from additional sources during the integration flow.

“When a new order event arrives, the integration enriches it with the customer’s credit score from the credit bureau API before routing it to the fulfilment service.”

Orchestration and Choreography

API Orchestration

Orchestration involves a central component (the orchestrator) that calls multiple services in a defined sequence and assembles the results.

“The order creation flow is orchestrated: the API gateway calls the inventory service, then the pricing service, then the payment service, and assembles the final order response.”

Choreography

In choreography, there is no central coordinator. Each service publishes events that other services react to independently.

“We use choreography for the post-order flow: the order service publishes an OrderPlaced event; the warehouse service, the notification service, and the analytics service all subscribe and react independently.”

Integration Patterns

Request-Reply

The caller sends a request and waits for a response — synchronous communication.

“The checkout flow uses request-reply: the frontend calls the pricing API and waits for the price response before displaying the total.”

Fire-and-Forget

The caller sends a message and does not wait for a response — asynchronous, one-way communication.

“After an order is placed, the confirmation email is sent fire-and-forget via an async message queue. The user gets an immediate response without waiting for the email to send.”

Dead Letter Queue (DLQ)

A dead letter queue holds messages that could not be processed successfully — for inspection and retry.

“Failed messages are routed to the dead letter queue after three retry attempts. The on-call engineer reviews DLQ contents daily and decides whether to retry or discard.”

Practical Phrases for Integration Engineers

• “This is a synchronous request-reply integration — if the downstream system is slow, the caller blocks.”
• “The ESB handles the protocol mediation between the SOAP supplier and our REST-based systems.”
• “We need a schema mapping document before we can build the connector.”
• “Point-to-point is fine for two systems, but we have twelve — we need a hub.”
• “Dead letter queue monitoring is part of our daily ops checklist.”

Integration engineering vocabulary reflects the complexity of connecting real-world enterprise systems. Mastering these terms will help you design integration architectures, evaluate iPaaS platforms, and communicate clearly with both technical teams and business stakeholders about how data flows through your organisation.

Navigating Nuance: Considerations for Non-Native Speakers

As an integration engineer, you’re constantly communicating technical concepts – often complex ones – to a diverse team. The precision of your language is critical, not just for clarity but also for demonstrating professionalism and building trust. It’s easy to fall into patterns that don’t quite land with native English speakers, or even with those who are still developing their fluency. Let’s address some common pitfalls and offer strategies specifically geared towards developers learning professional English.

One area where misunderstandings frequently arise is around the level of detail provided in communications. A concise statement like “The integration needs to be improved” can feel vague and frustrating, especially when someone’s spent hours troubleshooting. Native speakers often appreciate explicit feedback – “I noticed that the latency between Service A and Service B is consistently exceeding 50ms. Could you investigate potential bottlenecks in the transformation logic?” This isn’t just about accuracy; it demonstrates respect for the developer’s time and effort. Similarly, when describing a problem to a colleague via Slack, avoid simply stating “It’s not working.” Instead, try something like: “I’m seeing intermittent failures with the data sync between the staging environment and production. The logs suggest a potential issue with the schema mapping.”

Another challenge often stems from differing expectations around terminology. What might seem like a perfectly reasonable explanation to you – for instance, describing an ESB as “a hub for all our integrations” – could be misinterpreted by someone unfamiliar with common industry jargon. It’s vital to understand that technical language evolves and has specific connotations. Don’t assume your understanding is universally shared. Actively seeking clarification – “Could you elaborate on what you mean by ‘orchestration’ in this context?” – is a powerful tool for both learning and ensuring accurate communication. Furthermore, remember that phrasing matters; “We need to optimize the integration” carries a different weight than “We need to make it faster.”

Finally, pay attention to the tone you convey. Even if your technical description is perfectly clear, a dismissive or overly assertive tone can damage relationships and hinder collaboration. Focus on constructive language – “Let’s explore potential solutions together” instead of “You need to fix this.” A good rule of thumb: when in doubt, err on the side of clarity and politeness.

# Example using kubectl (Kubernetes) - a common tool for integration orchestration
kubectl get pods -n my-integration-namespace

This command demonstrates a simple way to monitor the health of your services within a Kubernetes cluster – a scenario frequently encountered in modern integration architectures. The output provides immediate feedback on the status of the pods, allowing you to quickly identify and address any issues.