Working with APIs that give the business room to develop

There were two significant factors that I took away from the recent MuleSoft Connect conference in London.

One is that businesses can now start to exercise real, vendor-free choice on how they build increasingly complex business services out of collaborating applications - and do it at a sensible cost.

The other is the key business development which follows from this, namely that Line of Business (LoB) managers can be, and are being, empowered to take business risks.

As Gartner VP and Fellow, Massimo Pezzini, put it during a conference panel session, the cost and speed of integrating applications that is now possible together means that the fear of failure is greatly reduced:

The failure of a project is no longer considered terminal to career prospects. In fact taking risks is now being encouraged. Business managers are beginning to realise that they can be one of the disrupting companies, or one of the disrupted.

And in his view, the collaboration that can come from loosely integrated applications, both new and legacy, enabled by the cloud and stretching across what is now being called the Internet of Everything, is becoming very disruptive:

Take a car crash as an example of what might be possible. The accelerometer on a driver's mobile phone can detect the fast deceleration and automatically check that person's vital signs, for trauma. It also logs the status of the car from its on-board sensors, then calls the emergency services and the driver's insurance company. As far as I know this is a fictional example, but it now possible.

As with many other possible services that can now be created, the desired outcome is a seamless, timely collaboration across all the IT assets of all the stakeholders in such a service.

Individual applications

The key to this is the ability to create APIs for individual applications that define the required data inputs and outputs that are needed and the way that they need to be delivered, so that applications can be loosely integrated together to build automated, collaborative services.

According to Ross Mason, MuleSoft's founder and VP of Product Strategy, the most important objective is for every company to exploit the ability that APIs give to connect applications together, particularly with the pairing up of new and innovative SaaS and the legacy systems that still bring real value to the business:

There are new disruptive business models coming through all the time, and the cost of entry to any or all of them is lowering all the time. I started the company because I felt integration should be easier, especially with the growth of SaaS-based applications. And while the new enterprise landscape is very fragmented, the need is still there for an integrated 'whole' for the enterprise.

The traditional way to achieve this has been with point to point solutions offering only tightly coupled integration. This, he said, has usually proved to only work until any change is needed, no matter how small. The impact analysis of any change makes it something to be avoided.

Yet, as he pointed out, $527 billion is spent on point to point solutions every year:

Integration is no longer about simply connecting applications. It is about unlocking the right data and delivering it to where it is needed at the right time. This allows new partners and channels to market to emerge and be exploited, as well as enterprises integrating new SaaS and established legacy applications.

MuleSoft's AnyPoint platform is its primary tool for this task. A hybrid integration platform, it can run anywhere appropriate for the user. It brings together tools for a lot of different use cases on one platform, which collectively fall into three categories: SOA, SaaS and building APIs.

SOA is the common use case amongst the enterprise community, where the primary target is connecting with legacy applications and data. With SaaS applications, the key targets include data synchronisation, process orchestration and batch loading. The growth of SaaS applications is growing fast, so this is a big challenge for most companies.

Building APIs is about connecting things together, especially the link between mobile devices and business applications. Mason suggested that this is currently a key driver bringing MuleSoft into play across the board in the enterprise marketplace.

A new version of AnyPoint, V3.5, was introduced at the conference. This added batch processing: a stock in trade requirement for large enterprises with legacy systems. It also adds DataSense, which provides all the data needed to connect a wide range of devices, applications a services together.

Lastly, it also adds AnyPoint Templates to help users with common integration tasks get up and running quickly. According to Mason, it lowers the bar to make integration easy between different systems.

The role of the API

According to Uri Sarid, MuleSoft's Chief Technology Officer, the place of the API is generating a new school of thought - that of the API as a product:

Developing APIs requires a budget, plus internal and external support, that means treating it like a product. So first off, you need to know who is the customer, what do they need and how to provide and package it for them. You also need to make it discoverable, which means using something like a value-add catalogue. You must tell people what it can do, give use case examples and show how to get started without asking experts. You also need to do this for every API, even the internal ones. That builds the experience of doing it.

That means APIs need to be produced using readable source code, and for this the company recommends RAML, the Restful API Modelling Language:

This is designed to be both highly readable and highly writeable,” he added. “It generates tooling, plus having a live console to see what live calls will look like, and comes with an API Notebook that logs what you have generated. This can be shared, and builds a track record of how you have built APIs.

The key to remaining agile with APIs is to manage the versioning of them, and define which version is required for which task, This leads to the Agile API Lifecycle.

An increasingly important driver behind the increased exploitation of APIs, according to Pezzini, will be the growing imperative of building real time collaboration between legacy, back office applications and the Internet of Everything:

This now means connecting on a completely new scale of trillions of things, and connect in real time. The question then becomes how to manage this level of integration when everyone is doing it. That means not just integration specialists, but LOB managers, applications developers and even `citizen integrators. It has to be ever more simple, yet designed for levels of interoperability that cannot be predicted.

This requires a bimodal approach to API development, he suggested. The traditional systematic approach is both costly and time consuming, and produces big systems as a result. The enterprise bimodal model uses templates that drive economies of scale and re-use wherever possible, with IT departments being expected to compete with external service providers such as SIs.

My take

The bottom line here is, much as Pezzini suggested to the conference, that this is just the beginning of a long journey for enterprises in exploiting APIs.

It is also the start of a fundamental change where it becomes the users, rather than the vendors, that decide what applications and tools are integrated together to form the collaborative services that businesses need.