As part of a system integration initiative, System A is required to integrate with System B through an exposed API interface. The integration objective from System A’s perspective is relatively straightforward — execute business processing only up to a specific stage within the overall workflow.
However, a key architectural challenge was identified during integration analysis.
System B’s API is designed as a tightly coupled orchestration layer, where a single API invocation automatically triggers an end-to-end chain of downstream processing activities. Internally, the API executes a sequence of approximately 5 interdependent process steps as part of a single transaction flow.
The issue arises because System A only requires processing up to Step 3 of the workflow. Beyond this point, the remaining steps are either:
- not relevant to System A’s business requirement,
- owned by another business domain,
- or may trigger unintended downstream actions such as notifications, settlements, fulfilment, or data propagation.
Despite this, the current API design does not provide:
- execution boundaries,
- partial workflow control,
- modular service invocation,
- or orchestration flexibility.
As a result, once the API is invoked, System B continues processing Steps 4–5 automatically without giving System A the ability to stop or control the execution flow.
This introduces several architectural and operational concerns:
- Unnecessary downstream processing
- Increased system coupling between applications
- Higher risk of unintended business side effects
- Reduced API reusability
- Complex rollback and compensation handling
- Limited flexibility for future integrations
- Greater dependency on System B’s internal implementation logic
The current design effectively exposes an entire business workflow as a single API operation rather than exposing reusable and composable business capabilities.
To address this limitation, a more scalable and maintainable integration approach is recommended. This includes decomposing the monolithic workflow into modular APIs and introducing an orchestration layer capable of controlling workflow progression dynamically. Such an approach would allow consuming systems like System A to execute only the required business steps while improving flexibility, maintainability, and overall integration governance.
