MuleSoft's Ross Mason on the future of enterprise APIs

I was expecting an interesting conversation earlier this month when I met with MuleSoft founder Ross Mason — our talks usually pan out that way. But what I didn't expect was to discover that the impact of digital transformation on IT is remarkably similar to its effect on HR.

It turns out that implementing reusable services across the IT infrastructure requires consistent practices, in the same way that implementing self-service HR across an organization demands consistency. Furthermore, enabling self-service means that central functions are no longer the go-to resource (and therefore the bottleneck) for getting things done. Instead, they must get better at collaborating with and advising lines of business to help them do things on their own initiative.

In the first part of our interview, Mason speaks about changing the way enterprises deal with APIs. What comes across clearly is that building an API-led infrastructure isn't just a matter of swapping out technologies. It requires a new approach to the way the enterprise creates new applications and services — one that's tuned for reuse, service aggregation and a more iterative development style.

This thing, this application that emerges, it emerges by you creating a discipline and some simple abstractions. Not by a big architectural project or by making large transformation statements. You've actually got to change your behavior, which is hard for a lot of organizations.

An opinionated platform

MuleSoft has become increasingly prescriptive about the best way to achieve that. Mason likes to say its Anypoint platform is "opinionated", which means that it imposes a certain approach. I observed that no one complains when a functional application like SuccessFactors or Workday imposes a certain way of operating, but it's more unusual in the IT sphere. Mason is unapologetic.

We're actually quite prescriptive in how you use the platform. We talk about API-led. A lot of the new features and capabilities are really centered around this notion that there isn't a thousand ways to build APIs, there's really only one or two. You're subscribing to an approach when you come to our platform ...

Having more opinionated standards around how you exchange information — having opinionated standards around if you're going to put us in a PaaS, then make sure all inter process communication goes through an API layer that we run, because then we can track everything.

And then the dashboard and metrics you get — you get this network view of your environment. You actually know what's going on. You know if you change something down here, something up here is going to break ...

So when we say opinionated it's two things. It's steering people in the right direction to build the right things, and it's also about enabling organizations to put in the right level of abstractions in areas and being able to enforce them through the tool itself, versus through governance mechanisms. So for example, if I'm going to build a new API, you can say you've got to go through one of these four API templates — that allows you to enforce standards. They make life easier and not harder.

Three API layers

An important part of that prescription is the way that Anypoint separates APIs into three layers. At the foundation layer, system-level APIs communicate with enterprise applications, datastores and other IT resources. The next layer consists of process-level APIs, which add functionality that works with the system APIs. Finally there's a layer of engagement APIs which provide the user experience. These three layers form the building blocks of what Mason calls the enterprise application network.

As you build this capability, every time you add a node, it should add more value to the network.

You're not building an architecture, you're building a substrate for change. It's really the consumers on the network that drive the value. We believe the application network will be how any employee or outsider gets value from your organization. They'll know where to go because there'll be an engagement layer. This is how you start to drive the operating system change, because you start to encourage people to self-serve.

So when a customer such as Unilever implements Anypoint, IT begins by building system-level APIs to interact with its core systems, then adds process-level APIs that can connect to system outputs, and then finally developers can use portals, templates and micro-applications at the engagement layer.

The reason why we have system-level APIs and the process-level APIs is to unlock that data so it can be moved more easily to these areas. That's exactly what Unilever was doing. They've got about 80 system-level APIs, they've got process-level APIs, but now the guys on the front end who are doing the in-depth integration have easy access to a lot of the SAP data.

Multi-cloud strategy

An important advantage of creating this standardized framework for connecting IT assets is that it then gives much better oversight of what's happening. Later this year, MuleSoft is rolling out a multi-cloud strategy that means its software — which enterprises can run both as MuleSoft's public cloud service or on-premise within their own infrastructure — provides oversight across a hybrid environment. Mason explains:

Our strategy is to be running on all the major clouds, through the major ones, by the end of the year ...

The value is we'll be giving people a lot more flexibility in thinking about where they run their environment, how they manage cost control around different things.

Then you have to do the analysis and say, this service is heavily used and it's on Azure right now, it's actually cheaper to run it on Amazon. Let's move it over to Amazon. Or, it's getting more used in the east coast of America than it is in Australia, let's move it to a different place where we'll have a different service level agreement.

MuleSoft has adapted its licensing model so that customers can run on-premise or in the cloud without having to worry about price variations.

We used to separate on premise and cloud. We don't do that. You just now buy [virtual cores] and you can deploy wherever. It just makes it super easy because people didn't always know when they would deploy things. Whether you're running, actually bare bone in your data center ... Whether you're running in Cloud Foundry, whether you're running it in Azure, whether you're running it on Amazon, whether you're running on CloudHub, which is our PaaS ... You'll get the same management, deployment and interaction behavior and you get the same metrics and the same analytics.

The ability to move assets between clouds is a sign of maturity in the cloud environment, says Mason.

What I find in this industry, we go into spikes of innovation and then pattering into management control and cost control, and almost like it's a commodity.

Commodity for the application will really be how well can you optimize across these cloud providers to get the best bang for the buck. When does it make sense to bring on site and just run it on Cloud Foundry? That's going to be a big part to play in this, I think. There will be utility based modeling of interactions in the enterprise.

Future adoption

Looking forward to the future, Ross believes there will be a lot more automation and delegation in the application infrastructure.

The way we do it today probably won't be the way we'll want to do it in four years from now.

I don't want to build all these services from scratch, I want to plug something in like an appliance that says, I'm attaching Salesforce in my application network, and the network becomes aware of it and exposes everything automatically. Or, I want to build a data marketplace with my data warehouse and I can plug this thing on top and I've got a packaged, sort of API factory, for unlocking read-only APIs in there.

I don't have to sell that to central IT anymore. I can go and sell that to other people in the business and say, this is what I want, you go and make the case for it, and we'll just plug it in. The central IT is like, that's okay because it's going to plug into my overall infrastructure much more easily than just a packaged offering.

Micro applications in the engagement layer, rather than raw API portals, will become the mechanism for widespread adoption of these services, he says.

If you've got ten thousand people using FTP to move data around, to tell them, don't do that now, go and call an API, they just can't do it. Even though it seems obvious, they'll find a thousand reasons not to do it.

If you give them a little applet that sits somewhere and behaves in the same way as it behaved before but now actually channels you to do the right thing, they're going to do it. You can put that on them.

So these micro apps that will serve ... It might only be twenty consumers but it doesn't take long to use. You can point them there and you can say switch off the other mechanisms so you're only using this. They'll actually do it. I think that notion of micro apps is actually going to be quite important.

It's a matter of packaging IT in a way that makes it easy to consume, he concludes.

I don't think we're very good at packaging a consumption experience within the enterprise without giving people too much information. Some people don't want the information, they just want to know how to get it done and move on.