The department Business Process & Systems (BP&S) of a large retailer manages enterprise-wide IT-services for the other departments within the group. The department houses a Service-Oriented Architecture (SOA), which is supported by tooling from the Integration team (ESB, PEP/Gateway). Within this context a project was started to introduce an enterprise wide API Management platform (APIM) to support the group’s “mobile” capabilities.
The tools of the already present SOA software vendor were evaluated for the foreseen needs of such a platform during a pre-project phase. The tooling was found to meet the high-level requirements that were laid out. So, when the project started, this tooling was chosen, and some high-level requirements were set.
The first step in the project was to capture more detailed requirements from the different stakeholders. This turned out to be difficult task because the decision for the APIM was taken at enterprise level and then proposed to the end-users. They had already been working on separate API initiatives with different capabilities and different setups, which now had to be centralized onto one unified platform. We choose to set out a quite bare APIM platform and open it up to the stakeholders as quickly as possible. This gave them the opportunity to think about their requirements and how they could leverage the platform.
In the meantime, we set out to tackle one of the main features of our gateway; standardized security. A pragmatic approach was chosen where we provided the recommended approach together with the currently most used methods.
Because we operated in a SOA environment, we had to position the APIs in it. This was especially difficult since not all the stakeholders were already applying the enterprise SOA principles. Eventually we integrated a light approach for APIs into the SOA principles which allowed us to incorporate former non-SOA practitioners into the SOA environment without imposing too much governance on them. Within the SOA governance, guidelines were created for REST design, complementing the existing SOAP guidelines.
Throughout the project we tried to maintain the API-spirit of consumer-focus. This resulted in setting up an easy-to-use CI/CD pipeline for API’s and Application registrations. It also meant a lot of effort was invested into giving trainings and demo’s and supporting the early adopters.