Most people we talk to know that APIs can streamline integration and improve business agility. But with all the different products and approaches in the market, what they’re really grappling with is the best place to start and what technology they need to support their API strategy. In this blog I’m going to discuss the key areas you should focus on when starting down the path of API-led connectivity.
Refine your strategy
For IT Executives, integration strategy can often be a tough sell to the business. In our experience the best approach for raising support for your integration strategy is to identify or focus on acknowledged current business challenges, then position and demonstrate how your strategic initiatives can solve those challenges. Be prepared to adjust your strategy to suit the needs of the business.
An example of how to articulate how IT limitations / challenges are impacting a business is described below:
Every organisation will likely have a different starting point for their API strategy. For example, one organisation’s API integration strategy may enable to them to achieve very specific business outcomes such as launching new products, connecting with new partners or major service improvements while another organisation may want to build a new business model by sharing or monetising core information assets such as customer or inventory data.
Whatever your business objectives are, make sure you align your API integration strategy to it so that you can demonstrate value quickly. Once you have defined your strategy you must then align it to an implementation roadmap. This will allow you to prioritise the delivery of information assets and give the business a clear view of the implementation timeline.
The number of technologies to support API integration has grown significantly in the last 18 months. Where there was once 2 or 3 core products there are now 20 or 30 to choose from, which can make it difficult to make a decision.
There are a few key areas I’d recommend you focus on when choosing technology to support your API integration strategy.
The first is identifying the key capabilities that you require to support API initiatives. This needs to come ahead of any purchasing decision on integration technologies, which may result in a solution not fit for your current and future purpose. The capabilities that should be defined include:
- API Lifecycle Management
- Middleware & Micro-services
- API Design & Development
- API Operational Management
- API Infrastructure
Some example scenarios that would help you determine the capabilities you require are:
- Scenario 1 – Are you an SME organisation with a small number of APIs? A lightweight API Gateway product may be more suitable than a full featured API Management product.
- Scenario 2 – Do your APIs need to integrate with a number of core systems? If yes, an ESB platform may be required to build integration flows to support your APIs.
Leading on from capabilities, you need to define the components and features that you require. An effective approach is to map out the use cases for the components and features and highlight the tools that could service these requirements, as shown in the example table below:
The uses cases are based on your unique situation and business requirements. If you have competing priorities or are unsure of the different tools available to meet your needs it can be beneficial to seek independent advice to help you weigh up the different options.
Architecture and Governance
The second aspect you should consider is the architecture and standards you want to leverage for integration. For example, if you want to align your contract definition standard to the OpenAPI (Swagger) specification you need to ensure you select a technology that supports that.
You should also think about the level of governance that is appropriate for your business. In the past many organisations have made huge investments in web service catalogues and directories that have been under utilised. If you prefer an information approach to governance instead of an organisational approach you can invest in a lightweight ESB as opposed to a more expansive SOA Suite.
Finally, you should choose the product/s with licensing commercials that suit your needs. For example, if you’re a business that has high volumes of requests in short bursts (such as a University during student enrolment) then you will likely need a more mature API Gateway product that can commercially support your short-term HA requirements.
You could take a year to develop 10 APIs that you think cover all of your integration requirements, but chances are the business needs and priorities will change or evolve in that time.
Instead, I recommend applying a product management discipline to your API delivery i.e. delivering APIs incrementally over multiple sprints. This approach allows you to prioritise implementation around business initiatives and demonstrate the value of your API integration strategy. I will be discussing this in detail in my next blog.