Integration styles and how to choose

There are five main ways to connect mainframe systems with the rest of the enterprise: synchronous APIs, MQ messaging, event streaming, file transfer and data replication. Each suits a different need, and good architecture picks per use case instead of forcing one style everywhere.

Why integration is an architecture decision

Most large enterprises run their core records on z/OS and their channels, analytics and newer services elsewhere. Every connection between them sets how tightly the systems depend on each other, how failures spread, what it costs and how hard it is to change later. Choosing an integration style is therefore one of the most lasting decisions in a hybrid estate.

The five styles

Style	Typical mainframe technology	Interaction	Best for
Synchronous API	z/OS Connect, CICS web services, DB2 REST services	Request and immediate reply	A user waiting for an answer: balance, quote, authorisation
Messaging	IBM MQ	Asynchronous, assured, once-only with syncpoint	Commands that must not be lost: payments, orders
Event streaming	Apache Kafka (or similar) fed from MQ, CDC or applications	Publish once, many consumers, replayable log	Notifying many systems that something happened
File transfer	Managed file transfer products, FTP/SFTP, Connect:Direct	Bulk, scheduled	Large volumes: statements, settlement files, partner exchange
Data replication	Change data capture (CDC) from DB2, IMS or VSAM logs	Continuous copy of data changes	Read-heavy copies for analytics or cloud apps

These are complementary. A single business process often uses several: a mobile app calls an API to make a payment, the payment is sent to the clearing system over MQ, an event announces it to fraud and notification services, and the day's totals go to the data warehouse by replication or file.

Coupling

From tight to loose coupling

Synchronous APIBoth sides up together

MQ messagingTime-decoupled, one consumer

Event streamingProducer unaware of consumers

Replication / filesData-level, no shared calls

Synchronous APIs are simple to understand but make the caller's availability depend on the mainframe's, and vice versa when traffic surges. Messaging separates them in time. Event streaming goes further: the producer does not know who consumes, and new consumers can be added without touching it. Replication separates them almost completely, at the price of data that is slightly behind.

Choosing: questions to ask

Is someone waiting for the answer right now? If yes, a synchronous API is likely, possibly backed by messaging behind it.
Must the request survive outages and be processed exactly once? Use MQ with persistent messages under syncpoint.
Do several systems need to know something happened? Publish an event rather than calling each one.
Is it large volume on a schedule? File transfer is often still the cheapest and simplest.
Does another platform need to query the data heavily? Replicate it, rather than calling the mainframe for every read.

Events and the mainframe

Kafka is not a z/OS-native product in most estates, but mainframe data reaches it in several ways: an MQ-to-Kafka connector, a change data capture tool reading DB2 or IMS logs and publishing changes, or an application that emits events directly. Unlike MQ queues, a Kafka topic keeps events for a retention period so consumers can replay them. That makes it a good backbone for distributing facts, but not a replacement for MQ when a command must be processed exactly once by one system under a shared transaction.

Common problems

Chatty APIs: a web page making ten mainframe calls to build one screen. Design coarser APIs or cache stable data.
Replication used for writes: changing a replicated copy and expecting it to flow back creates conflicts. Keep one system of record per data item.
Batch files becoming real time by accident: running a file transfer every minute. If the need is near real time, move to messaging or events.