Hybrid cloud patterns and governance
Most enterprises keep z/OS as the system of record while building new front ends and analytics in the cloud. This lesson covers the common patterns for doing that, the risks of each, and the governance that keeps a growing web of integrations under control.
System of record
The system of record is the authoritative source for a piece of data: if two copies disagree, it wins. For account balances, policies and ledgers, that is still often DB2, IMS or VSAM on z/OS. Hybrid architecture keeps that authority clear while letting other platforms use the data.
Common patterns
The incremental refactor pattern is often called the strangler pattern: an API layer sits in front of existing function, and individual operations are re-routed to new implementations one by one. It reduces big-bang risk, but only if data ownership is settled for each piece moved; two systems both updating the same customer record is the classic failure.
Analytics offload in practice
Copying data off the mainframe raises its own questions: how current must it be, which fields are sensitive, and where does it live. Personal and financial data copied to cloud storage must meet the same privacy and residency rules as the original. Data masking or tokenisation of sensitive fields before replication is common for non-production and many analytics uses.
Governance
Without governance, integrations multiply until nobody knows what depends on what. Integration governance keeps the estate understandable and safe:
| Area | What good looks like |
|---|---|
| API catalogue | Every API listed with owner, consumers, version and OpenAPI specification |
| Versioning | Breaking changes get a new version; old versions retired on an announced date |
| Data ownership | One system of record per data item, written down |
| Security | Standard patterns for TLS, tokens and identity mapping; exceptions approved |
| Cost visibility | Mainframe processor use reported per API or consumer |
| Change control | Integration changes go through the same change management as core code |
Governing copybook changes
Mainframe interfaces are often defined by copybooks. Adding or resizing a field changes the JSON mapping, the MQ message layout and every replicated table structure downstream. Treat copybooks that define interfaces as published contracts: version them, find every consumer before changing, and test the mappings in the build pipeline.
OWNERSORSTYLEIDENTITYCOSTFAILUREModern relevance and balance
Hybrid is the normal state for most mainframe users, not a stop on the way to leaving. Some workloads do move off z/OS when the case is strong; many stay because of throughput, data integrity and the cost and risk of rewriting decades of rules. The architect's role is to make each decision on evidence, keep the system of record clear, and make sure the integrations between platforms are as well engineered as the platforms themselves.
Common mistakes
If both the mainframe and a cloud service can update a record independently, they will diverge. Decide one owner per data item.
Replicas lag. Monitor lag and call the system of record for decisions that commit money or legal obligations.
Downstream JSON, MQ and replicated structures break. Treat interface copybooks as versioned contracts.
What you will see at work
- Architects keep a catalogue of APIs and flows with owners, consumers and the system of record for each data item.
- Modernisation programmes re-route one operation at a time behind an API layer rather than rewriting everything at once.
- Data and privacy teams approve which fields may be replicated to the cloud and whether they are masked.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.