At the commencement of many API integration projects, from a systems analyst point of view, part of the work is to ensure that associated systems that are expected to provide the data, particularly downstream dependencies, know the scope and scale of the new demand they will need to support.
In early discovery we tend to think about how we are defining the interface. However, it is also sensible to gain confirmation that the teams supplying the data understand the integration and the resource requirements to support it. Without confirmed understanding to deliver appropriately scaled data delivery, the best built API contract cannot perform in deployment.
When that alignment exists early in the project, interface design tends to be straightforward. When it does not, the dependency may surface later during analysis, and becomes a risk.
Understanding the integration
On one API project I worked on, our integration required response data from another programme within a large government department. The data existed and both teams agreed it was necessary for the interface, so at first glance the work appeared to be a relatively straightforward API implementation.
As the systems analyst working on the integration, discovery began with tracing the information flow across the integration boundary. I confirmed which identifiers would arrive in the request and validated how the responding programme would retrieve the required data. In other words, the normal work of requirements elicitation and interface analysis.
When scale became visible
During that process a different issue emerged. Supporting the API would introduce a new operational demand on the responding programme, and the scale implications of that demand had not yet been considered with the team responsible for the platform.
The integration was new and the additional demand had not been part of their system’s original operating assumptions, so there was insufficient capacity for the additional needs of this project. Most concerning was that the work required to support the integration had not yet been recognised or planned.
Part of the reason for this was structural. The project had been scoped as a relatively simple API implementation and no systems architect role had been established. In many programmes an architect would normally identify cross-system dependencies and surface non-functional requirements such as performance, scaling, and operational capacity early in the delivery cycle. Without that architectural layer, those considerations emerged later during analysis.
Once the constraint became visible the teams worked together to address it. Both sides agreed on the information required for the interface and the integration design itself remained sound. Supporting the required scale demanded a rapid mobilisation of effort from the responding programme. Teams coordinated closely, worked extended hours, and introduced the changes needed to reliably support the API.
Because of the massive team effort, project delivery itself was thankfully not delayed. While it was a significant effort to achieve that outcome, this could likely have been avoided with earlier preparation and downstream awareness.
The role of early coordination
Ideally, downstream teams should understand the demand as early as possible, so they can plan the necessary personnel time, development effort, and infrastructure changes alongside the integration work. Typically this is established during architectural analysis. Regardless, early systems analysis must involve confirmation that stakeholders across the integration are prepared to support the capability the interface introduces.
In this case the teams ultimately delivered through rapid coordination and a significant mobilisation of effort. The outcome was successful, but the experience reinforced how much smoother integration delivery can be when those dependencies are surfaced earlier in the programme.
The most significant issue was not defining the API, but ensuring the systems and programmes behind it were operationally ready to support the demand that integration would create.