This is a guest post for the Computer Weekly Developer Network written by Alessandro Chimera in his role as director of digitalisation strategy at enterprise data software platform company Tibco.
Often written in stylised form as TIBCO to denote the organisation’s stance as The Information Bus COmpany, the focus for the business now is to position itself as the ‘connected intelligence’ technology platform of choice for data in all its forms, functions and touchpoints.
Pointing to his firm’s pre-existing commentary in the API space, Chimera highlights the Tibco ‘Ultimate Implementation Guide to API Management’, where the organisation’s technologists define the steps to implement a successful digital transformation by using APIs.
Chimera writes as follows…
There’s a lot of talk surrounding the question of whether or not we should refer to APIs as a ‘product’ these days. In truth, almost anything could be a product, even if it is essentially a service or something more ephemeral.
Perhaps a more insightful question would be, are APIs a brand product i.e. are they synonymous with an organisation’s customer-facing staff base, its reputation for service quality and its wider market regard for the way it operates? If an API can do all that (spoiler alert: yes, it needs to), then it is a product.
An API essentially remains a piece of code tasked with conjoining intersections and forming assured bonds between applications, services and systems… but it is also a product in the sense that it can work to make an organisation’s digital assets available for everyone’s consumption.
Engineered, built, deployed and managed effectively, an API can facilitate an instantaneous business turnaround in response to market shifts that dictate a change in the customer journey. As we all now know, global disruption does happen, within days if not within a day – so using APIs to form and establish essential bridging connections should now be part of our core technology vocabulary.
Viewing API as products, we can expose an organisation to new businesses, partners and ecosystems – and they can do all of these things quickly and with agility, creating a competitive advantage. The journey starts with getting the first API product on the roadmap.
Building ‘Team API’
While not every organisation has a dedicated API team, the role of the API product manager is gradually being formalised, recognised and popularised. What we now see among the programming community is API development being democratised and expanding to become a more ubiquitous discipline and skill.
If there actually were a perfect ‘Team API’ (if you can excuse the slightly gung-ho twist) then it would include not only software engineers and IT product experts, it would also include citizen developers and incorporate the use of some low code/no-code tools.
Because we have the API product manager role in place, we can now (collectively, as a combined group of business and technical staff) make sure that APIs work as a significant engine of business growth and a prime instrument in the modern-day IT stack.
In many ways, the challenge with APIs is a human one. By this I mean that APIs are fast to implement and (when built carefully and conscientiously) execute their functions quickly and succinctly. The shift that’s also needed is one of human mindset. This is because using APIs effectively requires a new way of thinking about partnerships, a new way of thinking about collaborating, connecting and coordinating.
In an API-first world, business and technology teams come together in new ways and at a new pace; so this is why having a centralised governance and organisational model is critical
Defining an API strategy
Defining and subsequently building an effective API strategy means understanding how APIs are now the de facto means for providing access to enterprise data and enabling complex system interactions at scale in the modern architecture stack.
We must also remember that internal APIs (connecting internal systems or knowledge, record and action) are becoming more prevalent, providing significant tangible gains by reducing technical debt, reducing time-to-market for new products and improving the developer onboarding experience.
There are three organisational API strategy archetypes and understanding that APIs can be leveraged inside one of these three use case core vectors is a fundamental prerequisite:
- API security archetype
- API-led archetype
- API monetisation archetype
Business value & monetisation
Lastly here (for now) let’s also talk about APIs within the context of defining and prioritising business value.
Whether APIs are monetised or not (and our three key monetisation strategies are listed below), there needs to a fiscal appreciation for where this technology functions inside any IT deployment. Core API monetisation strategies are as follows:
- Pre-paid (time-bound, subscription)
- Post-paid (chargeback)
- Real-time (depletion against balance)
Understanding how an organisation’s business and technical drivers work with (and mesh to) its wider industry drivers is key to a successful API strategy. This process of deconstruction-to-construction will ultimately be the process through which a firm is able to map the vision and goals of your executive leadership team to the shape of its API footprint and wider IT stack.,
The IT function must be mindful to deliver Total Cost of Ownership (TCO) and Return On Investment (ROI) justification through Key Performance Indicators (KPIs) that denote its APIs’ (plural) effectiveness in terms of the desired quantitative and qualitative outcomes.
Those API outcomes are a measure of an organisation’s API performance in the market and its impact on your company’s way of doing business.