Replace message-and-component-oriented integration contracts, staging-table operating models and the nVision and SQR reporting estate with governed entity, service and analytics surfaces — endpoint by endpoint, by consumer need rather than by source lineage.
The integration estate of a PeopleSoft installation is bigger than its interface documentation, and it is bigger in a specific direction: it includes everything anyone ever built on top of direct database access.
An Integration Broker service operation is a contract shaped by three things: what the business needed, what the source data model could express, and what integration technology was reasonable when it was built. Only the first of those is still relevant.
The customisation register makes an observation about Component Interfaces that is worth acting on deliberately: they are a good clue to the true write-contract used by source integrations.
The Trade module covers the business redesign of Voucher Build and the Billing Interface. The integration-architecture question is what replaces the operating model.
The adapter lists read-only SQL and PS Query extracts as an integration surface, and it is the surface with the longest tail.
The reporting estate spans three source surfaces and one gap-register entry, and it needs to be handled as one problem.
The playbook sets out an extraction strategy for the migration itself, and it is worth distinguishing from the run-time integration design because the two are often conflated.
Pulling the threads together, the target architecture for a PeopleSoft replacement usually has four layers, and the value is in placing each flow deliberately.
Integration on a PeopleSoft programme is a recontracting exercise across eight source surfaces, three of which are gaps and one of which is barely documented anywhere.