MuleSoft founder on using APIs to turn your IT department into a SaaS platform

MuleSoft founder Ross Mason believes that enterprises are not making the most of their IT assets, both on premise and in the cloud, for a number of reasons. Firstly, these assets are often implemented in silo and the value of cross platform data-flows are never realised. Secondly, and more importantly, IT tends to lock down and protect these resources and becomes a blocker to the business wanting to consume them how it sees fit.

This is a pretty fair representation of how a lot of traditional enterprises operate. Start-ups tend to try to implemented more fluid architectures, thanks to having the advantage of starting from a black sheet of paper.

MuleSoft and Mason’s solution to this is through the creation of an API integration platform, which taps into and sits on top of the core technology assets of the organisation. The APIs talk each other and also become reusable assets for both the business internally and even for external communities.

Where data may have been locked down previously, it is now opened up via the use of APIs for anyone to create services. The idea being that this fuels innovation internally and more closely aligns business and IT. Mason explains:

Most organisations, at best, have thought about APIs at the edge. It’s actually really hard to innovate at the edge, if you don’t start decoupling the core. The challenge for enterprises is first to realise what that might mean for their organisation.

The biggest challenge though is the change in the operating model. Every organisation is very used to executing projects on this treadmill, the business needs something, they put a project in the pipeline, it gets triaged, it might take a year. I met with one of the big banks today and it takes two and a half years before one of their projects gets approved. That isn’t working, that’s breaking down, that’s the IT delivery gap problem.

But if IT can open up its assets to the business, this changes the role of IT itself. Mason said:

Technology traditionally has been the centralised function to procure big apps and manage the network. And they haven’t actually had to think about serving the business any other way. And the business isn’t used to self-service themselves.

They do it through things like shadow IT, where they’re not aligned with IT, but what we are saying is that they need to align with IT because when something goes wrong, it’s the CIO that gets the brunt of the pressure. So we are looking at a different approach where IT delivers these capabilities and packages them in a way that more people in the organisation can go self serve and use them.

A Centre for Enablement

However, whilst this makes sense in theory, Mason admits that it’s not enough to expose the critical systems, create the APIs and throw them over the wall, hoping for the best. There needs to be a coordinated strategy in place, via the creation of what MuleSoft calls a Centre for Enablement - a group of people who are charged with evangelising, educating and promoting the success of an API-led enterprise.

Mason said:

The challenge with that is not building the API, it’s driving consumption. A lot of the time we spend is helping them really think about not just the building, but how do you drive consumption and self-serve. What you’re really doing is turning key assets in IT into services for the business - you’re turning IT into a SaaS platform.

In most organisations, because people work in this project to project mindset, they deliver something and move on to the next thing. The first lesson is that when you deliver an API, you don’t move on to the next thing, you’re part of that DevOps team that owns that API. What we end up creating is a Centre for Enablement, which is a small team of people, and their goal every morning is to wake up and think about if the organisation knows those assets are available to them.

And make sure that people using those assets get wildly successful with it. It’s not too dissimilar to creating communities around open source software, there’s a lot of parallels. You’re evangelising what’s available to people and then making them get successful. You’re taking the feedback from those people to help drive further investment in those APIs.

But, Mason states that whilst throwing it over the wall will likely have little effect. If the Centre for Enablement does its job effectively, there tends to be a “pretty tremendous pull effect” once people start to realise the benefits. Mason said that this usually occurs within the first year.

Does IT have any control anymore?

This idea of making IT assets consumable and reusable for all appeals to me. It makes sense that organisations that want to compete in a Internet-driven world need to allow for innovation that happens quickly and naturally, outside of the normal formal structures of enterprise ‘projects’.

In fact, Mason makes the comparison between an API-led organisation and the Internet, where the Internet also uses reusable and consumable blocks and data for anyone to create what they wish. However, I put to Mason that whilst the Internet is obviously fantastic, there’s also a lot of problems bad stuff out there because of the lack of control. If you open up your enterprise, how do you stop it from leaking into what looks like the dark corners of the Web?

However, Mason argues that its easy to codify use case rules into the API and it’s much easier to kill access if something isn’t aligned with how it should be being used. He believes that organisations not using an API-led approach actually have less control. Mason said:

If you think about what people do today, there is no difference. What they do is, if someone needs information, you deem them to have access, they will extract information, and give you access to that database. Once they’ve got access to that database, you don’t really know what they do next with it.

With APIs, one of the nice things about it is that it becomes a single door into that asset. The problem with a copy database is that you do that 50 times and suddenly everybody has different versions of the data, you’re trying to sync it up - that’s the way that information has been moving around organisations.

With the API you create a front door to that information and you say ‘if you want access to this, you declare your intentions with us, we give you access, that also means there’s security and access control’. So you actually have much better visibility into what information is flowing to which applications, which you don’t really see with the database approach.

With that approach, all you know is there is a database here, and they may or may not share the credentials with other people. Everyone has to declare their intention before they get hold of it, so you get more integrity.

Scaling for success

Finally, I was keen to hear from Mason what he perceives to be MuleSoft’s challenges as the company goes forward and gains traction in the enterprise (it is attracting some big name customers).

Mason said that his biggest challenge is that as companies begin to expand their use of MuleSoft internally, it has the capabilities in place to support that growth. He said:

Our business model is subscription based and we are heavily reliant on our customers getting wildly successful. It’s not a concern, as much as a healthy reminder that every business should be there to serve their customers. Whether you buy a small implementation for a simple integration between Salesforce and SAP, or if you try to transform a bank, you get exactly the same platform.

The difference between those two customers is how wildly successful do you get at driving that change in that organisation and expanding the use? We invest very heavily in customer success and we are doing it at a rate where very large organisations are placing very big bets on us. That’s what keeps me up at night. As companies get more bold or if the urgency gets bigger, we need to make sure the platform or all the capabilities around it, scale with those organisations.

If I think about our business architecture, it’s very much around making sure we have all the support in place so that we don’t get into a mode where most middleware guys did where they are in firefighting mode all the time. We get ahead of the challenges pretty quickly.