Some history
We recently worked together with an organisation on their API Management Program.
They already had a good track record with integration. This was mostly application to application work and some partner integrations as well. However, much of their effort had gone towards the technical aspects of integration, mostly vendor related. Things like architectural oversight and guidance or design patterns were not part of their approach.
Some departments already started working on developing APIs and decisions makers and business leaders understood their importance. Gradually, APIs became more important to the product and service line up, and they wanted to make sure they took all the right actions.
Archers was given the opportunity to guide them in the rollout of their API Management program.
One of the first things we did was to bring together all of the different platforms and technologies and create a tailored reference architecture. The API Management platform and its components got a clear position within the IT landscape.
Patterns and guidelines were next. The reference architecture was expanded with a set of integration patterns that covered all of their possible scenarios. This of course included APIs. API design guidelines helped API designers and developers in their endeavour to apply an API-first approach. Every API had the same “look and feel” and the consistency across the board was increased, making it easier to find and consume APIs.
The central API platform and decentralized API development required a specific setup for roles and governance. With the new organisational setup, each team is individually able to design, create and deploy their own APIs, while the central team manages the platforms, architecture, guidelines and procedures.
From a strategy point of view, each department had a clear view of where they were going with APIs. The idea of enhancing the physical product with new and exciting digital capabilities through the use of APIs was well understood by everyone.
If you look at all of the topics I just touched upon, you can see that they progressed in their API maturity on many levels. For more details about the API Maturity model feel free to visit one of our previous blog posts.
Evangelization
During discussions with the program manager he expressed additional concerns about the perception of the position of the API platform. He wanted to ensure that the program was supported by the right communication and looked at Archers for inspiration.
As stated, each team and department was already convinced of the role of APIs, but we now needed to promote the role and purpose of the central platform to different stakeholders. This question is summarised in the following expression:
“API Management as an enabler for our digital customer journeys”
The following image depicts a fairly typical situation for APIs. Different teams and departments build and deploy APIs. On the API platform they are made available to the internal ecosystem. Different APIs are combined to create digital customer journeys.
Although the API platform contained many capabilities, we decided to focus on three key capabilities. These represent the core elements in the creation and support of their digital customer journeys.
First up is the API Catalog.
An API catalog is an organised and uniform library of APIs.
API producers register their APIs and thus make them available to the various consumers within the ecosystem. Because APIs are products and they represent the business, they must be structured in such a way that its business purpose is recognisable for the API consumers.
The next capability is discovery.
Discovery is about the enablement of development efficiency and innovation. APIs must be easy to find, easy to understand and easy to get access to. APIs are your digital products and they form a digital storefront where consumers can find out what you have to offer and learn about its business value.
Finally we have the self-service capability.
The ability of API consumers to use published APIs without the involvement of the API producer.
Both the self-service and the discovery capability are delivered via the developer portal. For discovery purposes, being able to browse and search for APIs is sufficient. For self-service we need to be able to go further than this.
The developer portal should contain everything to make the life of a consumer easier. Some developer portals are very elaborate and cover the full range of features, while others are more concise.
Three roles benefit the most from the aforementioned capabilities.
Developers are always under pressure to build solutions faster and more efficient. Business and users want their features as fast as possible. One way of getting your work done faster, is to use what is already there. Reusing existing APIs can speed up time-to-market significantly. Additionally, the API producer increases its reach within the ecosystem en benefits from the feedback to improve or expand its API functionality and data.
Product managers continuously want to improve existing products and services but also create new ones. Having access to the entire collection of available APIs can help them create and design new digital products faster and easier.
The last role is the digital strategist. For this organisation the digital strategist is focused on innovation and experimentation. They will look to combine new and cutting edge technologies with existing building blocks. The available APIs exposed via the developer portal provide a clear overview of what is available within the organisation. The digital strategist does not have to look elsewhere for specificfunctionality or data.
Conclusion:
API Management is often seen as a purely technical element within the IT landscape. However, with the right message you can bring it to a business oriented audience. It is important to remember that each organisation is unique and requires a tailored approach.
Don’t hesitate to contact us for more information about this topic!
ALWAYS LOOKING FORWARD TO CONNECTING WITH YOU!
We’ll be happy to get to know you.
