MuleSoft founder Ross Mason on the API-led enterprise

API platform vendors tend to talk up the impact of APIs on the enterprise and MuleSoft founder Ross Mason is no exception, but he warns that technology alone can't achieve the necessary change:

The platform's important because it's the technology that enables something else to happen — but it doesn't happen automatically. There's no software right now that's going to make enterprises go faster and organize themselves the way they need to be organized to survive in the next five or ten years as change continues to occur ...

Just because you plug in our platform does not mean you're going to drive digital transformation. Working with us will help you understand where we can be good levers in that journey, but we're not the only thing.

That realization has meant MuleSoft has shifted its approach to market in recent years, focusing much more on enterprise goals and business outcomes, he tells me in conversation during MuleSoft Summit in London earlier this month.

Now, when we engage with customers, we define a joint success road map so they can understand, you're not just buying software from us. We're actually going to run this program with you. That's part of the subscription. We do that investment from year one.

The reason we can sink that cost is because the platform is very sticky. Customers that get wildly successful in year one buy three times more than the customers that are left on their own to do it on their own.

For us, it's also a lot more fun to be delivering great outcomes for customers and them deciding they're going to use you in more interesting ways. There's a bit of a selfish aspect that I want to be doing fun stuff, I don't want to be just selling enterprise software.

Get the internals right

The last time I sat down with Mason, two years ago, the conversation was all about using APIs to expose internal services to an external ecosystem of partners and customers. But while that's still an important objective, the company now focuses much more on enabling services within the enterprise. That's because the external services don't work that well if the internal architecture isn't right, he explains.

It's very hard to have a public API conversation or even a partner API conversation with a company that's never really been successful building an internal API. They just don't understand it ...

Even when companies do say they want to open up a public API, they haven't got the infrastructure internally to really do it well.

The way some enterprises have enabled mobile applications is often a good example of the wrong way to do it, he says, citing the experience of one customer who he didn't name.

They created a big database in the sky and they would sync data into the sky, but it was only ever updated 3 times a week at maximum. They wanted to create a good mobile experience from that but that was the best they could do.

Well now they've backed that all out but they've gone down an API-led approach and they've said, we're going to put these system-level APIs in front so we can actually unlock the data, put some good caching layer in there as well so that we're not hitting backend systems too much, and then build from the inside out. It's worked a lot better.

Once the internal architecture has been overhauled, it's much easier to start opening up services to the outside world.

If you imagine you've got this big public application network [in the cloud]... You've also got private ones within your organization. At some point you'll start opening up the walls a bit to allow certain parts of this network to operate in the public realm.

The key is getting the organizations to understand that moving this direction a) will serve their immediate needs in needing to go faster and drive more agility, and b) will drive a lot more innovation and will allow them to think differently about what services they offer publicly to people.

Why change is needed

The challenge is getting people to understand what they have to do. That means explaining why change is necessary.

I think the key thing is first, help people understand the way they're doing things today isn't scaling, isn't working. It used to work. It was fine. Now it doesn't.

Helping them understand that taking this API-led approach, and every time you touch a system you should be thinking about opening up a reusable asset on top of it — but don't spend months architecting the hell out of that thing, just make it available and make it iterative — is a mindset change.

... I think the biggest mindset change is realizing that there [are] other ways of doing it, and stop saying 'no' to problems on old thinking. Think about how you'd solve it in the new way.

Not everything will fit the model, we know that. We're not trying to cure the world with APIs. APIs aren't magic fairy dust — but leveraged in an organization with the right discipline, they completely change the way IT and the business operate with each other.

In part 2 of this interview, Mason explains why MuleSoft has become more prescriptive about the API architectures it helps customers build, and discusses some future directions. Plus my take on what this tells us about the changing role of IT in the enterprise.