iconimage - Fotolia

The API economy – or the API Tower of Babel?

Application programming interfaces promise to open up back-office systems to the business and third parties. We assess the impact

Application programming interfaces (APIs) seem to be all the rage at the moment. Everyone is going on about the "API economy" as if the world will fall apart at an economic level unless something is done now to manage APIs.

Are APIs that important? Well, yes and no, as any analyst will be happy to tell you.

We first need to look at why APIs are needed, how they can be used, and how they are more important now than they have been in the past.

Historically, applications were focused on a single area of the business. HR systems looked after employment issues, CRM systems looked after customer interactions, ERP systems helped manage the running of certain back-office functions. Each was, to a certain extent, self-contained – they created data, they had reporting systems included in them, people got on with using them and all was fine.

Except that it wasn’t. Each system created its own data silo. Organisations realised they needed to bring these data silos together so better analysis could be carried out, and this led to enterprise application integration (EAI) and enterprise service buses (ESBs), enabling a certain amount of interaction to take place between the various enterprise applications that were in use.

This approach required a way of dealing with each application – and so the API was required.

The basic idea of an API is that the owner of one application creates a set of access methods that can be called by another application. The API is documented and, if used correctly, creates a level of abstraction between the two applications. Through this means, changes can be made to either application without affecting the way they interact.

System of engagement

This need has become even more important with the increasing use of various mobile devices. The need for the 'system of engagement' (the manner in which a user creates, and interoperates with, the data) and the 'system of record' (the way the data is stored and managed) has to be effectively abstracted so that changes can be made to the system of engagement at the rate now expected by users without the system of record needing to be changed as well.

So far, so good. However, many APIs contain undocumented functions. For example, application owners may reserve certain functions for themselves for greater functionality or performance, so putting third parties at a disadvantage. Other APIs can be badly written and contain vulnerabilities that may be used by hackers.  

Where application programmers write directly to the API themselves, the problems that were seen around the previous attempt at creating composite applications with a service oriented architecture (SOA) repeat themselves. SOA was meant to stop the use of tightly coupled code (code that creates a dependency between two functions), instead freeing up the services to be loosely coupled and replaced at will.

However, many SOA-based applications still carried forward a tightly coupled approach – and it looks like the same problems will carry forward as users code between discrete APIs, rather than coding for multiple APIs.

Read more on API management

To muddy the waters, cloud computing has come along. For cloud to really deliver on its promise, a completely different approach to what constitutes an application is needed. Instead of using a CRM or an ERP system, cloud provides the capability to move to a ‘composite application’ – one that is built up from a set of specific functions pulled together as required to meet the needs of a specific process.

These functions could be in-house, could be in a private cloud or could be in a public cloud. They need to be brought together in a fast and effective manner – and this can only really be done through the APIs

But what happens if the APIs are poor or not open? Can you take the risk that the composite application will have security issues or that the application will not work because the API calls being used have not been documented properly?

Role of API management

This is where API management comes into play. Many suppliers have software that plays in this space, and Quocirca expects to see many more enter the market as the reality of cloud computing kicks in.

The idea with API management is that the software manages authorisation and security between the calling and responding functions, as well as managing audit and information transformations (making sure that the way the calling function submits its calls is the way the responding function can understand it).

Many systems also provide portals that can manage billing and self-service, but these can be viewed as ‘nice-to-haves’ rather than necessities.

So who are the main players? CA acquired Layer 7 in 2013, which has provided it with strong API management capabilities. IBM’s API Management Service has capabilities that enable organisations to bring together functions across a range of platforms, including IBM’s own SoftLayer environment.

WSO2 is an open-source API management system that is expandable and has strong capabilities. Apigee is proving popular and has a free API creation system with its Edge product. Fiorano Software is taking the composite application approach directly, using ‘microservices’ as its basic terminology for the various functions it can pull together.

Intel acquired Mashery in 2013, and is an API management supplier, but is probably not top of many people's API management shopping list. Akana (previously SOA Software) is highly regarded, and has a good history in dealing with the first generation of loosely-coupled SOA architectures. 

Dell, with its acquisition of Boomi, gained an API integration and management capability that it is playing to a good extent with its cloud aggregation offer. 

Other players include Axway, MuleSoft and some of the older ESB players, such as Tibco, alongside ETL suppliers such as Informatica.

As with any new(ish) market, the problem is apparent – there are a lot of suppliers fighting for position and all are taking different routes. There are few standards in the area, which means the wrong choice of tool could leave a buyer without the capability to embrace new functions or systems and needing to reverse out of one product and move into another to keep up with the changes in the way applications are constructed and used.

Make the right choice

It is therefore important to make sure the right choice is made – or at least, the least wrong choice. Make sure that the chosen API management tool is flexible and has a broad set of connectors and proven methods of accessing both the data and business logic held within existing enterprise applications.  

Look to suppliers that have a good ecosystem built around their offering, with channel providers who can offer the bespoke work required to provide API management for applications that are domain- or organisation-specific. Make sure the chosen tool not only provides a means of making APIs work, but also monitors the APIs and applies security and audit capabilities across the total composite application. 

Where hybrid cloud systems are being used, look for systems that can manage billing, thus enabling the real-time use of commercial functions in an ad-hoc manner. In many cases, this will be a case of seeking service providers that offer API management capabilities that can work with your own systems. Check that the data they provide is understandable and usable within your environment, and make sure the requests sent by your system will be understood by the service provider's system.

The market for such API management tools is still young. There is a need for more maturity in most of the offerings that are out there. Many suppliers will find it difficult to evolve their tools and will find themselves left by the wayside. Others will come in with new approaches, such as API management as a service, and put pressure on the early movers to become more fleet of foot.

The biggest issue for users is to avoid the many traps there could be along the way towards the API economy. Assuming that all applications and functions will use the same APIs and capabilities is the road to ruin. Developers will continue to create their own APIs under the misapprehension that theirs is the best possible way. It makes far more sense to assume that different applications and functions will move their APIs along at different speeds and to apply a flexible API management tool over the top.

Ensuring that all the different APIs can work together requires a system that can act like Douglas Adams’ proverbial Babel Fish: it needs to be able to accept anything in and make sure that what comes out is understandable to the system dependent on it. This is where skill and domain expertise are required – this is where suppliers will win or lose.

Clive Longbottom is founder of analyst Quocirca

Read more on Service-oriented architecture (SOA)