APIs are the foundation of every digital transformation initiative. They represent internal processes that support the workforce, partner APIs that extend the reach of your organisation, and third party app developers that extend the reach of the organisation to new places. At the same time, legacy systems are being adapted or replaced to meet the needs of today’s marketplace.
In short, APIs are becoming the ultimate do-over for enterprise IT. But how to we ensure that our do-over results in agility, rather than slowing us down? Let’s examine some common ways that organisations are using this to their advantage.
The composable enterprise is one that strives to capture business and technical capabilities as APIs, seen as modular components across lines of business. APIs are designed first, becoming the outward-facing contract that hides all of the internal details. Apps and integrations are built upon these APIs by the enterprise for internal, partner, or public use. A composable enterprise combines commercial off the shelf (COTS) packages, SaaS platforms, and custom development to address market needs quickly. They also view their APIs as products that combine the business and technology aspects of their business.
The technique of hiding internal implementation details and exposing an external API has been rooted in software design for decades. Terms such as modularisation, loose coupling, and high cohesion are associated with great software design. The Facade software design pattern is often used to isolate the desired API (the facade) from the underlying history of technical decisions and debt (the implementation). Using the facade pattern as an abstraction layer helps organisations to design the API that represents how their organisation needs to work, while hiding the legacy systems and databases that capture how the organisation used to work. This approach is critical to taking advantage of this do-over moment.
Throughout the recent period of growth around web-based APIs, most have been limited to request-response over HTTP. While this provides a great foundation to your API platform, it limits extensibility and evolvability of your platform as integrations are limited to providing commands and queries only.
We are now seeing a resurgence in eventing with the popularity of webhooks to connect SaaS solutions, the introduction of technologies such as Kafka to drive internal messaging, and the need for integrating IoT devices. Rather than sending command and queries when we need to perform a task, events allow us to react to the changing state of data or a workflow. Events become the glue that connect systems together, often without human interaction.
To ensure your do-over with APIs will have a meaningful impact, I recommend the following 12 principles to formalise your API programme:
- Establish why the API strategy exists. Ensure it is easy to understand and apply to all job roles.
- Communicate your API strategy often across the organisation. Obtain executive team support to maximise API programme success.
- Establish a consistent training programme that prepares teams for an API-centric approach.
- Establish a lightweight API governance model that ensures consistent API design and standards compliance.
- As your API programme grows, implement a federated governance approach to support large development teams distributed across business lines and varying regions
- Build in API portfolio management to encourage platform growth and quality.
- Apply an API lifecycle that encourages rapid delivery combined with stakeholder involvement.
- Deliver a comprehensive developer portal that covers the full end-to-end process for discovering, onboarding, and consuming your APIs.
- Make it quick to get started with your APIs and encourage continual communication for those who want to stay informed.
- Engage other roles within your organisation in your API programme.
- Support solution teams to ensure they have the knowledge and
resources necessary to successfully find and integrate your APIs.
- Shift to a product-centric approach to API ownership, with solution teams working directly with API owners to encourage a “you build it, you own it” approach.
I expand on each of these principles in the whitepaper I wrote for Tyk.
APIs are becoming the ultimate do-over for the IT department. No matter your business model or size, design your API programme to support this opportunity. Design APIs based on the business capabilities and jobs-to-be-done, and then adapt the implementation of these APIs to integrate the appropriate systems and necessary data sources. These APIs will represent the future state of your enterprise — even if the current state isn’t quite there yet.
If you’re interested in learning more about API success, be sure to check out our free whitepaper to get your API strategy started.