MuleSoft founder wants CIOs to say, 'There's an API for that'

Phil Wainewright Profile picture for user pwainewright August 3, 2017
MuleSoft founder Ross Mason talks about building an API-led enterprise integration strategy that gives CIOs the tagline 'There's an API for that'

MuleSoft founder Ross Mason at Connect 2017
Ross Mason, MuleSoft

Popular trends like the Web and the iPhone App Store are helping integration vendor MuleSoft encourage enterprises to emulate these models of reusability and easy discovery to achieve a more responsive and scalable integration strategy. Integrations shouldn't be six-month projects, they should be available off-the-peg, says company founder Ross Mason:

What we're trying to do with the enterprise is get them to think, 'There's an API for that.'

The web has been a great enabler for winning acceptance for this philosophy, he told me last month during a visit to London:

The Web has been an excellent playbook for the enterprise to understand how you create composable units out of complex systems, and then drive agility and innovation by packaging up those building blocks in ways that make it really easy for any type of developer-consumer to discover and use.

We just never had that before. We didn't know what 'great' looked like. It was really hard to get it right. I think the Web's just shown us — and the consumer innovation we've seen through the apps and through the phones — that it really works.

All MuleSoft and other companies are trying to do, honestly, is drive that same thinking, that same behavior, in the enterprise to unlock those the assets that they own.

Rapid innovation at Wells Fargo

One example of this rapid unlocking of IT assets through APIs comes from US bank Wells Fargo, which broke down its mortgage approval process into APIs, and then found it made sense to open up those APIs to external partners:

Wells Fargo have broken down their big monolith into a set of APIs.

They created about 40 APIs in total. What they realized very quickly is that a number of those should be opened up to their partners. Very quickly from getting good at opening up internal APIs, they started opening up something to their partners as well, because they saw a strong opportunity to create better product partnerships with some of the other smaller banks and other financial houses.

I always thought it was going to take probably 18 months to get comfortable doing that. They did it in about three or four. I think the agenda for publishing capabilities and actually starting to think about revenue generation is accelerating.

This is a trend that's been brewing for some time. When I spoke to Mason three years ago, he was talking about opening up APIs to third parties. But he's always emphasized the importance of getting the API strategy to work internally first, and that's become an increasingly stronger theme, informed by experience:

It's very hard to start to opening up things that work well on day one. What I've seen time and time again is that what they built there isn't really what they needed to build, but if they start [internally], whatever is useful in their own organization tends to be quite useful to people outside their organization too.

CIOs must take the lead

Mason is quite clear that this has to be driven by the CIO rather than by line-of-business executives. Although the driver for change may come from the business, it has to be managed by the CIO, he says:

The CIO has to move first. If the CIO doesn't commit to creating these reusable components so that they can be used by other parts of the business, then there's nothing for the CMO or the VP of Sales Ops to respond to.

In other words, the two go hand-in-hand. You can't change the behavior without the technology, but you won't get the best out of the technology unless you change the behavior:

That's why we operate the way we do and why we sell to CIOs. If you want to change behavior, it has to be a mandate and a commitment from the exec level that you've got to change the way you build things. Otherwise, it's too easy for everyone else to snap back into default behavior.

The successful pattern that MuleSoft promotes to foster change in enterprises is something it calls a Center for Enablement approach. This focuses on evangelizing the API model and making people outside of central IT feel more confident to access resources by picking up the API and working with it, Mason explains.

When you say something like 'center of enablement,' it sounds like it might be this big heavyweight and it actually isn't. It's just a couple of people that understand what assets are available in the organization.

One of those people tends to be more evangelical in wanting to get people to understand how to use things the right way and will spend time with them. You just need one or two people that are sort of wired to be the governor, if you like, of the App Store, the API Store — and then help people understand how to get value out of those APIs. It doesn't need to be a big process.

How Unilever opened up integration

The huge value of this approach is that it allows people outside of IT to immediately harness the work that IT has done, rather than pushing in a request and then having to wait for ages for something to pop out — a model that often just slows everything down even more. Mason cites the example of consumer brands giant Unilever, which took an API-led approach to eliminate a huge swathe of legacy integration tools.

People are starting to get more enabled to do more on their own. It's actually reducing the number of projects that go through to central IT, which was the key goal. Central IT at Unilever, they were doing about 100-150 projects about getting data out of one of their warehouse systems, every year.

Those projects will take about 20 weeks because they have to spec out the request, they have to contact someone who understands the back-end system, they've got to then schedule the work. What also happens on the business because it takes 20 weeks, [is that] people start throwing all sorts of other requirements into that dataset. They're like, 'If you're gonna get this, I need these things as well too.' So they're creating these monsters that are completely not usable anywhere else. It's just like a random dataset.

Of course, the way every company does this is, they don't connect you to the data warehouse system. They extract it, they create an ETL process, and they put it into a brand-new database. They've created all this new infrastructure just so that you could get read-only access to a bit of information in the data warehouse. Rinse and repeat that 150 times a year and you can see why that becomes a very big problem for someone like Unilever.

An API factory

An API-led approach turns this whole model on its head, Mason explains:

This new approach says, 'No, we're just gonna put read-only APIs directly on top of the warehouse and those queries we can then cache on a daily basis.' You're not putting extreme load on the back-end system. But also, once we've done one or two read-only APIs in that data warehouse, it's really quick to take a new dataset, shape it, and then make that into another read-only API that you can just publish into the marketplace.

They've turned this into an API factory, basically.

You're also stopping the bad behavior from the business side, because they start just requesting what they need. Typically, the API factory team are also asking questions like, 'Is there anyone else who needs this type of dataset or should we shape it slightly differently so everyone can use it?' What we find is once we've done a few of these, people start to see the patterns pretty quickly and go, 'Okay. Well, you're asking for this part of product, but we should give you these bits as well.' That way, we won't get asked to do another product API.

It's an iterative learning experience where you've got to open something up to spark the idea and then you drive some behavior change and with that, you support the behavior change by making it more and more efficient.

Opening out API access

What MuleSoft is now doing is opening out the APIs even further by adding a developer tool that's designed for less technical users to simply harness the APIs they need — but which still leaves central IT in charge of what they're able to do and monitoring what's going on.

The palette is now dynamic and it means you can start packaging up resources and data and capabilities for different types of users so that, when they get there, they're not having to configure things like Salesforce credentials. They're not having to ask permission to go and get things. They can see the stuff they've got available to them.

I see that as a very necessary step as we get more of these SaaS applications in the enterprise. You can't expect central IT to go and manage them all. But what we do give them is a way to audit exactly what's going on and make sure it fits into the overall architecture of IT. The big focus has been, don't let people do whatever they want. You're going to package it up in a way that you give them the things that they need and they can go and have degrees of freedom without doing unnatural craziness.#

My take

I first met Ross Mason a few months before he founded MuleSoft back in 2006. So it's been interesting to watch the company's emergence to become one of the giants of digital enterprise integration, completing a successful IPO in March this year. This has become a huge market, and one where creativity and flexible solutions are at a premium. The company's emphasis on reusable patterns is in tune with today's needs and there's still a lot of evangelism needed to get this message accepted within the enterprise. The old-school methods of point-to-point, project-based integration have certainly had their day and rapid reusability is definitely the way things are headed. MuleSoft offers CIOs a clear path forward into a new era of API-led, policy-governed, rapid-deployment integration.

A grey colored placeholder image