You're probably all too familiar with terms like 'digital transformation' or 'digital disruption'. There are endless concepts and trends behind these fancy words but you could say that they are 'a new way of developing, deploying and maintaining software'.
The vendors are changing how software products are made, and more importantly, they're changing how software is sold; there are new architectural styles (Reactive Manifesto and 12 Factor Applications, for example), and there are lots of new technologies in the mix: Platform-as-a-Service (PaaS), Software-as-a-Service (SaaS), the Internet of Things (IoT), Artificial intelligence (AI), Big Data, Responsive Web Apps, API Management, to name just a few.
The landscape is fast-changing and endlessly diverse. So what does this mean for businesses? It means they need to figure out how to stay relevant and competitive. They need to boost innovation internally, and re-use internal assets in the most efficient way. That's not the only major challenge though as businesses also need to deliver data to multiple audiences (customers, suppliers, employees, partners, and so on), and to deliver through different channels - think desktop, mobile, tablets, TV, and everything else. The risk here is that IT will get overwhelmed by all the changes and requirements, and turn to point-to-point (P2P) integrations to deliver on time and on budget. We know this approach lets us deliver quickly in the short term, but we also know it has huge maintenance costs, and that it doesn't scale when the number of components grows. So we know that it's not sustainable in the long term.
Solving this problem has always been one of the main objectives of the service-oriented architecture (SOA). That means having well-defined services that are discoverable and reusable, and avoiding P2P integrations. The basic principle hasn't really changed at all. What has changed is the technology that is used to implement SOA. The traditional way uses 'fat middleware' appliances that are expensive, difficult to scale and, as a general rule, tricky to use and configure.
This is the reason many organisations are migrating to a microservices-oriented approach these days. Many people think this is an alternative to SOA, but in fact it's an evolution of a 'fine-grained SOA'. It tackles the drawbacks that come with the traditional SOA approach, and is a much better match for the data-centric and diverse IT landscape we live in today. For a deeper dive I strongly recommend reading our blog series Microservices: everything you need to know.
We all know that there is no silver bullet in IT, and that, if you're looking to adopt a microservices approach, your organisation needs to be ready for it. As with anything, it comes loaded with risks and drawbacks. One of the risks is that services can proliferate internally, and can become unmanageable if no governance is applied.
This is where the correlation between microservices and APIs comes into the picture. The industry (unofficially) agrees that microservices aren't necessarily meant to have an interface, because they're there to serve a well-defined piece of functionality. When the service is mature and ready to be consumed by a broader audience, that's when it should "graduate" to an API, which, by definition, is reusable and discoverable. So in this context, the API is letting the microservice functionality be exposed as a product. This creates internal value, and potentially, external business value as well. You'll need an API management layer when the number of microservices in your organisation starts to grow very quickly. That's when the layer would become a single point of access for the whole organisation - a point where the users can request access, read the documentation, share information with other users, give feedback and so on. The API layer is also used to enforce access control, rate limiting, and policies.
This idea doesn't apply only to microservices - it applies to every asset in an organisation. If you put APIs in front of legacy systems, ERPs, on-premise or SaaS applications, it will promote their re-use, and will make them discoverable. It will also provide a single point of access for all kinds of audiences inside the organisation - it will abstract the underlying communication protocol, standardise access, and so make it easy to consume. Also, the APIs don't necessarily mirror the underlying systems, but they can, (and they should) reflect the user experience that customers are expecting - they should filter the data of interest, or aggregate data for multiple systems. An example I like is the Mulesoft's Application Network, which reflects this principle really well.
The External API Economy
When you use an API to generate profit, it means that your organisation is participating in what's called the "External API Economy". Internal assets and services are exposed to the outside world via APIs, letting them generate revenue through monetisation policies. In fact, many major vendors generate most of their revenue through APIs these days, like Salesforce (ca. 50%), Expedia (ca. 90%), and eBay (ca. 60%). Many companies have it as their ultimate goal to compete in the external API economy - I think that's clear when you see that the number of public APIs is increasing exponentially. As I'm writing this article, the total number is over 20k!
Bear in mind though, that participating in the external API economy (i.e. generating revenue via APIs) is 'only' the final destination in a long journey, that goes through multiple steps, or 'API maturity stages'. Generally speaking, an organisation will need to establish an 'internal API economy' first; this stage is all about getting the APIs mature enough to create business value internally and to compete on the market outside of the organisation.
You need a discovery phase as a preliminary step, where you identify your organisation's strategic assets (or services). Mulesoft suggests creating a C4E (Center For Enablement), which does exactly what it says on the tin: it's a cross-functional team that takes on harvesting reusable assets and best practices, promoting consumption and collaboration, and collecting feedback and metrics throughout all of this.
When you have discovered your assets, you are ready to get on the path to API maturity. You will pass through this series of steps:
- Assets are “unlocked”, through system APIs being defined, removing the limitations of legacy systems and SaaS. At this stage, the APIs are mostly 'wrapping' the services underneath, allowing for consumption, but not focusing on user experience yet.
- The APIs evolve so they can be used in mobility, and via multiple channels (i.e. having different APIs retrieving data from the same system, but adapting to the user experience)
- APIs are exposed to partners (B2B)
- APIs are exposed to the public
You might be wondering: "which tools would I use to achieve this?". The answer lies in the API Management platforms; there are lots of options on the market, but they all seem to agree on these features:
- API definitions can be designed, documented and tested (via mocks) on the same platform, promoting a design-first approach;
- APIs are discoverable via Developer Portals, and users can request access to them, and also provide feedback;
- The API gateways can consume both on-premise and Cloud SaaS applications seamlessly;
- The API Platform represents a single point of entry for all the APIs;
- Governance, service level agreements (SLA) and security can be applied to APIs via the API Gateway;
- Usage statistics can be collected, and the APIs' success can be measured;
- Monetisation policies can be applied.
As you can imagine, getting to participate to the external API economy isn't necessarily a straightforward process - your internal APIs need to reach the very highest level of maturity. That said, once you've gone through this process and reached that level, APIs can be used to generate revenue, and ROI has the potential to be massive.
The next post in my series will be about API management - I'll be covering what it is, why you need it, which tools to use and more.