Integration architecture is the documented design of all system-to-system data flows within an enterprise technology programme — specifying which systems exchange data, what data is exchanged, in what format, at what frequency, through what transport mechanism, and with what error handling and retry logic. It is not a list of interfaces; it is the structural blueprint that governs how every interface is built, tested, and maintained. In ERP, EPM, and BI implementations, the integration architecture is the connective layer between the transactional core and the performance management surface — and its quality determines whether the programme delivers integrated data or a collection of independently functioning systems.
Structure and Content
A complete integration architecture document covers six design dimensions:
| Dimension | What It Defines |
|---|---|
| Interface inventory | Every system-to-system data flow in scope: source system, target system, data domain, direction, and trigger |
| Integration pattern | Real-time API, batch file, message queue, or direct database — selected based on volume, latency requirement, and system capability |
| Data format and transformation | Source schema, target schema, transformation rules, and the layer at which transformation occurs |
| Error handling | What happens when an interface fails — retry logic, alerting mechanism, manual intervention procedure, and dead-letter queue management |
| Middleware and tooling | Oracle Integration Cloud, MuleSoft, TIBCO, or custom middleware — with the configuration responsibilities defined |
| Monitoring and logging | What is logged at each integration point, who monitors the logs, and what constitutes an alert versus an informational record |
In Oracle EPM environments, the integration architecture governs the ERP-to-EPM data flow (typically through Oracle Data Management / FDMEE), the EPM-to-BI flow (from FCCS or PBCS to reporting platforms), and any ancillary system integrations — HR systems feeding workforce data to planning, treasury systems feeding cash position data, or subsidiary ERPs feeding consolidation inputs. Each of these has different latency requirements, transformation complexity, and error handling needs that must be designed independently.
Common Gaps and Failure Modes
The most consequential gap in integration architecture documentation is the absence of defined error handling for the ERP-to-EPM data load. When the interface specification defines the happy path — data extracted, transformed, loaded successfully — but does not define what happens when the load partially fails (some entities load, others reject), finance teams discover the gap during the first live close cycle. The EPM shows actuals for a subset of entities. The close cannot proceed. There is no documented procedure for identifying which entities failed, reloading only those, and validating the result without double-loading the entities that succeeded. This scenario adds hours to the first live close and is entirely avoidable with a defined error handling design.
A second common gap is integration architecture that documents what was built at go-live but is not maintained as the landscape evolves. When a new subsidiary is added to the consolidation perimeter, the integration architecture is not updated to reflect the new data flow — meaning the next project team has no accurate record of what currently runs in production.
How Loop Wise Solutions Produces This
Loop Wise Solutions produces the integration architecture document as a mandatory deliverable before interface build begins — not as a retrospective documentation of what was built. We conduct an interface inventory workshop with the client’s IT and finance teams, define the pattern and error handling design for each interface, and produce a versioned architecture document that becomes the governing specification for all interface build and test work. The document is maintained throughout the programme and handed over as a live operational asset at go-live, not archived as a project deliverable.
