In Part 1 of this series, we discussed the lessons learned from a large insurance company during their implementation of an API Management Program. In Part 2, we discussed what they got right and what worked well. In this post Simon discusses the opportunities that a successful API Management Strategy, as well as a Holistic Abstracted Catalog, unlocks for large enterprises.
REST APIs should be scoped to a specific resource – meaning they should return only that resource. This can be inefficient when the consumer wants several related resources or if they don’t want the entire resource. GraphQL is in effect an ‘information service’ providing an endpoint which takes a consumer defined query, and which returns matching data. Adoption of this model removes the need to create what are effectively hand crafted query implementations for the large number of APIs which are just returning data from a single data source.
2. Utilize the capability model
Currently there is no consumer of the information presented through the capability model and its mapped APIs. There is an opportunity, however, to tie that information into an API blueprinting process to identify opportunities for API reuse and API product definition.
3. Include the project perspective
The design platform should be the system of record for API metadata. In our case, however, projects began creating Confluence pages capturing project data, much of which should have been in the design platform:
- Defects and defect resolutions for a given API by consumer
- Promised delivery dates by activity (analysis, test, development)
- Assigned analysts, testers and developers
- Signoff by consumer channel
- Which environment has a deployed API version
4. Embrace APIs as products
Currently our APIs are entirely tactical, with the APIs invisible to the business except as one of many technology dependencies. If the business can begin to conceive of APIs as real business products instead of IT implementation artifacts then the business could begin to transform into something closer to the ‘everything as a service’ model in which the business leverages external capabilities and also sells its competencies to other organizations via APIs. In this model productized APIs have defined release schedules, roadmaps, support staff, SLAs and business ownership, all of which can be tracked as API metadata in the API platform.
5. Leverage analytics
The API platform can provide insight into business activity driven by APIs through analysis of API calls. These analytic results should be of interest to the business especially if they adopt API as a product vision.
6. Enable agility
Business agility is one the core drivers of SOA, and is a benefit derived from adhering to SOA design principles to create decoupled and reusable services. However creating well defined reusable services is insufficient – in large organizations those services and APIs also need to be discoverable and presented with sufficient information to make them appear as useful component of proposed business solutions. The API design platform’s catalog should be leveraged to expose available APIs broadly.
7. Enable innovation
The design platform exposes a catalog of existing APIs, and can also contain an API blueprint. Having access to current and proposed should enable the business to consider new products with a clearer understanding of potential costs and time to market.