API architecture is really a natural evolution of early service oriented architectures that came to prominence in the last ten or fifteen years. It retains the basic concept of some sort of ‘back-end’ business service that can be driven externally, but the API approach carries the independence of the service consumer further. Previous approaches depended on relatively technical and complex programming to invoke a back-end or legacy service, making it something that was normally done in-house, within the same company boundaries as the business services themselves.
By contrast, in the API world, while the building blocks for the services are still provided by the business service owner, the consumers of those services are often components built by third party developers, possibly with specific device expertise for example, with the invocation often being as simple as a call to a URL. Since they are easier to use, developers can go to an online marketplace to view available business services and build them in to the solutions they are providing. The API approach has much less restrictive skills requirements and offers greater opportunities for flexibility and innovation.
However, even the simpler and more flexible API approach has specific challenges that must be addressed. For example, once the service request has been passed to the service provider, the service provider still needs to handle all the necessary activities such as managing security, controlling traffic volumes, orchestrating the legacy components to deliver the requested service and delivering the results. These are just the practical challenges of course; there are also the usual challenges around what functionality a company is prepared to expose externally and to whom, and how to keep any external activities from interfering with internal systems of record.
An API architecture is therefore an essential requirement for successful, enterprise-class API enablement, and this is particularly important for core systems users who rely on their enterprise-class reliability, scalability, security and performance. It is worth spending a few moments considering what types of functionality and supporting activities will be required to deliver a successful API deployment. These include:
- Support for a wide range of delivery channels (e.g. phone Apps, IoT chips)
- An environment to attract and enable API-based solution developers
- An API middleware layer to make desired and authorized business functionality available to API consumers safely and reliably
- Strategy and planning activities to make the optimal set of APIs available
- Governance activities to manage partner involvement and to ensure business cases are met
The diagram below illustrates the make-up of a generalized API architecture; the specifics of a core systems API architecture are discussed later.
Why API-enable your legacy systems? The reality is that API-enabling is becoming a key topic for most major companies – indeed, IBM itself now places the API model firmly in the core systems world as an important and relevant development.
There are a number of reasons for the appeal of the API model to legacy systems-oriented companies. The benefits that attract these companies can be summarized as:
- Improved return on assets
- Wider and deeper market reach
- Faster time-to-market / increased agility
- Opportunities for new revenue streams
- Mitigation of disintermediation
The first point has already been touched upon. Over the years, companies have invested heavily in their core systems environments, and financial executives in particular are keen to ensure that these investments bring the maximum possible returns. But legacy system assets in general are fairly difficult to access from the outside. There are connectivity issues, syntactic and semantic issues at the invocation level, and a huge skills chasm between core systems and other IT staff. An API approach offers a way to overcome these issues. It addresses the connectivity and invocation problems, and cunningly bridges the skills chasm by enabling each skills group to concentrate on developing services. This is a key point – instead of telling a COBOL programmer that he has to work with OAuth and JSON, or a phone App developer that she must work with COBOL, each person is enabled to develop in his or her own environment.
One of the main reasons for creating APIs is to make them available to solution developers working in modern delivery environments. By enabling these developers to rapidly build new solutions that bring business to the company through APIs, innovation is greatly accelerated. Whether the work is done by third party developers or inhouse departments, new solutions can be quickly brought on line, delivering new channels and ways for customers to buy. New revenue streams may be created by offering an innovative new solution to customers and consumers and companies can respond much more quickly to both new opportunities and threats.
It is even possible that an API approach can mitigate the threat of disintermediation. By providing APIs to drive business activities as close as possible to the buyer, it reduces the risk of some other party getting into the gap and cutting the provider out.
-Steve Craggs, Lustratus Research
Want to find out more about API integration? Download the complete ebook from Lustratus Research.