10 steps to APIfy enterprise IT for a serverless, conversational future

The longstanding ideal of business computing as a set of Lego-like components that can easily be snapped together to get a job done is nearing fruition. It's been a long time coming, but finally the enabling technology of APIs — application programming interfaces — has gone mainstream with today's more fungible Web interfaces. Now the emergence of serverless computing (also known as functions-as-a-service), along with conversational voice and messaging agents running in the likes of Alexa and Slack, is piling the pressure on enterprise IT to 'APIfy' the application infrastructure.

Someone who's been a long-term advocate for this API-centric approach to enterprise computing is MuleSoft founder Ross Mason. We caught up on a visit to London this week and I was keen to get his take on whether the emergence of serverless and conversational computing is helping to spur adoption of APIs in the enterprise. He says:

There's all these interesting vectors between automation, and then the consumer experience, and integration. We see APIs as being — not the magic bullet — but the key construct to open up and provide that capability across the organization ...

If you have these APIs available, it gets a lot easier to spin out these orchestrations, whether it be in Slack or functions-as-a-service, to automate things much more easily.

This is part two of our interview — part one yesterday probed Mason's take on AI's 'brain-in-a-jar' problem. Today, here are 10 steps based on our conversation on how to bring APIs to enterprise IT.

1. Towards intentional self-service IT

Business users across the enterprise want to grab functionality and get things done. They're either going to go off and do that off their own bat — creating a huge 'shadow IT' hinterland within the organization — or IT can get ahead of them and intentionally create an architecture that allows them to self-serve the functionality they need. Mason explains:

Rather than you going to buy apps and circumventing IT and then calling them when you get stuck — which is the bane of every organization right now — IT actually starts to get ahead of the curve and say 'I'm actually going to open up some of these capabilities so that you can plug in your Tableau data sources into a set of APIs that I've created, and then you can go and do reporting without filing a project request for every type of data form that you need.'

I think IT is starting to rotate to this idea that the best way to stem off what I've been calling the 'IT delivery gap' — which is just the amount of demand in the business versus what IT can actually deliver — is to start creating these self-service capabilities. The base of that is APIs.

2. Serverless and the composability index

The advent of serverless computing is all part and parcel of a move towards APIs, and adds fuel to that trend. Mason even argues that perhaps enterprises should be measured against a 'composability index' that reflects how agile their API infrastructure allows them to be.

[Serverless computing]'s rise in popularity is because APIs exist. And the continued rise in popularity will be the fact that other APIs exist as people start using it and getting more value from it.

Like everything, it's going to get abused. There'll be horror stories of writing a thousand functions and not being able to figure out how everything's connected.

But I think net-net, it's quite positive in that it's sending us down the direction of where everything should be an API, and what we're really doing is stitching APIs together to perform different activities.

This composability — the ability to compose and recompose something based on any kind of new input or new application that sits on top — should be like the Holy Grail for many enterprises. There should be a composability index that probably directly correlates with your agility and even your ability to drive innovation. I think if you look at macro trends of the way companies leverage technology, this is a pretty key foundation of the shift that's happening.

3. Think APIfying not appifying

During our conversation I noticed Mason drop in a word I hadn't heard before. During the surge in mobile apps a few years ago, it was common to hear the verb 'to app-ify'. Mason's new word is to API-fy (pronounced 'ape-if-eye').

We were talking about the new PSD2 open banking regulation in the EU, which came into effect last weekend. It requires banks to open up interfaces so that third-party payment processors and application providers can access account information and transactions. Banks could have treated PSD2 as a compliance exercise and just done the bare minimum, using manual processes or workarounds rather than a true API approach. But Mason believes most are seeing it as an opportunity to modernize infrastructure that's long overdue for a refresh — although it does require a big rethink about processes that often haven't been touched for a very long time.

PSD2 I think was seen by a lot of these banks as a good forcing function, to start thinking about APIfying other areas of the bank as well, not just payments, but also loans and originations, appraisals, all that kind of stuff ...

It's weird that people are asking for extensions to the deadline because it's not actually that complicated. But what they're really asking an extension for is, my organization is still getting their head around, how do I break up a traditional verticalized capability into a set of APIs? That's really what the extension is saying, I think. But I think we're seeing more organizations really understand that's the way to go.

4. IT learns to be a responsive service provider

It's not that difficult to get started, says Mason. But MuleSoft has found that what's important is to then evangelize the new APIs so that people actually do use them, and to keep refining them based on feedback.

The building, we're finding, isn't too bad. A lot of customers are running hundreds, if not a few thousand APIs now. But getting them to understand how they drive consumption ...

You've got to keep reminding everyone in the organization that they're there. You've got to run hackathons. You've got to have people that run the API marketplace, and take the feedback and feed that back into how they invest further into some of these APIs for the long term.

That's all part of what we call the new IT operating model. You're not just delivering nice projects, but you're delivering these assets and you're actually treating the business as a consumer of those assets and taking their feedback and improving over time.

5. Three layers of APIs — system, process, experience

MuleSoft divides APIs into three layers. The system layer is down in the technology infrastructure and typically replaces or supplements the traditional legacy middleware that organizations already have in place (Unilever provides an instructive case study). The experience layer is where users interact with the functions and content, whether through traditional web applications or more modern mobile and conversational experiences. In between sits the process layer, which corresponds to the traditional enterprise applications, and is often where the most radical change takes place, says Mason.

The system layer is actually the easiest for IT to understand, because it's close enough to what they already know. So they're actually quite good at that. And we don't try to do too much at that layer. It's more about normalizing access and then managing access to data and capabilities.

The middle layer ... is an interesting one because it's where the most activity ends up happening, when you have those other two layers. Because you're abstracted from the systems and the consumers, you can actually refactor a lot there. As long as you don't break the contracts on the top or bottom, then it gives you a lot more fluidity in terms of consolidating views of a customer or creating new versions of a service for a particular part of the business.

6. Building it incrementally

A big advantage of the API approach, he argues, is that new APIs can be introduced individually, as part of specific projects. Gradually those APIs build up into what MuleSoft calls an application network.

APIs have definitely allowed us to be much more incremental. So you deliver APIs as part of project delivery. That takes a bit of training. Once people understand how that works, they can actually get pretty successful with it.

Over time, they build up a set of APIs in the organization and then we look at that really as what we call an application network — this idea that those APIs aren't just APIs, but they're actually organized in a network in your organization.

7. Finding the right granularity

The move towards Web and mobile APIs has created a generation of APIs that are much less complex than in the days of SOA and CORBA, and therefore more adaptable, he explains.

[If] an API does one thing and does that one thing really well, you can actually drive a lot more adaptation, without ever having to futz around with the pieces down below. I think we just learned that the right level of granularity and the right technology stack — around not putting too much protocol on top of it — has enabled all the innovation we have on our devices today.

8. Build it as a service

As we mentioned earlier, you can't just build APIs and then forget about them. IT becomes a service provider, and that means putting in place the infrastructure to manage them over time. Fortunately, says Mason, that's all built into modern API management tools.

The nice thing about using APIs, of course, is modern APIs have API management, which means you've got flow control, management contracting, authorization and authentication, negotiation and that stuff built in.

9. You have to slow down before you can speed up

The end goal is to get off the treadmill of having a never-ending backlog of requests coming into IT for new functionality. But before business users can start self-serving themselves capabilities from the new API infrastructure, there has to be a hiaitus while the IT team gets started on its new path.

It's a bit counterintuitive for them, because in order to speed up, they've got to slow down a bit and figure out how to build APIs, and then they can speed up again, because they can start building things on top. That's the journey we take our customers through, is how to do that without freaking out or building the wrong stuff.

10. Once you open it up, it snowballs

Once people start seeing what's possible from an API-led approach, they catch on quickly, says Mason.

We've done this for a few banks now, where they've broken up their monolithic mortgage application into anything from 300 to 500 microservices/APIs — because they tend to put three or four micro services into one API. That takes some time. It takes them probably eight, nine months to break that apart. But once they've done it, they've then got all these reusable services that can be used by different parts of the bank.

They found that once they started open these things up, it created this interesting pull for it. It's like, 'Oh, we can actually get some of these things now,' and started to change the conversation that IT was having with the business in terms of what they published.