MuleSoft CEO Brent Hayward on how to drive composability and reuse

(© Tom Wang - Adobe Stock)

Recently, I've been writing about the concept of API-first composable IT and its advocates among a new breed of 'headless' e-commerce and web content vendors. But as Brent Hayward, CEO of MuleSoft, reminded me today, composability is also part of the DNA of the integration Platform-as-a-Service (iPaaS) vendor, which Salesforce acquired four years ago.

He cites the example of Rocket Mortgage, a MuleSoft customer that uses its technology to pull together a set of 'headless' services so that clients can discover their eligibility for a loan:

You look at something like a Rocket Mortgage that largely started with, 'We have a headless scenario, we have the underlying data, it needs to be packaged into a mobile experience.' It does a lot on the back end — checks credit score, checks demographic, then says whether you fit into a profile for a loan or not.

I think MuleSoft has actually been used — our methodology, the composability, the APIs and the reuse — are commonly used and have been for many years to support those headless environments.

I was reminded of a conversation several years ago, before MuleSoft became part of Salesforce, with its founding CEO Ross Mason. His view was that composability should be a business imperative. He told me:

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.

Changing attitudes

But if that's the case, why are so many enterprises, even among MuleSoft's customers, still deploying APIs within a more traditional application integration strategy? Attitudes need to change, as Hayward explains:

The optimist in me says we're in a very different place than we were five years ago. The pessimist in me says, I still get RFPs every day where a customer is like, 'What's the fastest and cheapest way that you can take the 10,000 interfaces I have going into SAP and move them over there?' And I just see a light bulb goes out in my brain a little bit, because that is the moment to not just modernize, but to think about adopting a different way of doing this work, so that the outcome is a much more composable architecture underneath.

We're trying to compose all these services. You can't compose all these services, without actually having composition in the underlying architecture.

The most progressive CIOs, he goes on, have a different mindset in which they see their role more like a product manager. He explains:

If the mindset is, I'm producing a set of products for a consumer, not I'm producing a set of widgets that only an internal expert can use, the whole landscape changes. And also what's cool is the technology today could take that service that started internally, but if designed the right way, could be flipped and made available externally. So you're writing once and enabling a ton of future deployment models outside and inside.

I'm a technologist. I love the platform we've built. At least 50% of the problem is an organizational evolution of the way we do this work. It's the mindset and then does the technology reinforce and measure whether we're achieving the mindset or not?

Showing impact

Part of that reinforcement is achieved by building telemetry and dashboards into MuleSoft's products so that customers can measure usage of the APIs they've deployed and show the impact. He cites some examples:

AT&T, we're now able to map that to, that composability and those processes are saving end service and sales users 30 minutes of their day. Worldwide, it's over a billion dollars in selling and service time.

We're able to look at other customers that are reducing their time to development by as much as 40%, because of this composability.

You have to be able to reinforce the behaviour, and show in the tooling, how this is leading to a faster time to deliver. You're not just getting the architecture benefits. But what are the real, faster time to deliver, easier to govern, less maintenance?

Since becoming part of Salesforce, MuleSoft has built out accelerators and templates to speed integrations and extended the range of systems that it can bring into the API framework, including adding RPA capabilities. More recently, it has connected the API infrastructure into Salesforce Flow, a point-and-click environment that allows non-developers to build applications and automated workflows. This means that, for example, the ability to query inventory in a back-end SAP system simply becomes a building block within the workflow builder. That's important to counter the shortage of enterprise IT resources, as Hayward explains:

There's so much backlog of IT work in this new digital time with all these different tools that we're not just solving for technology landscape fragmentation. We also have a people solution here.

There's not enough developers in the world, and there won't be, to develop our way out of this mire of complexity. So how do we look at this different class of workers we call knowledge workers? There's over a billion of them, only 22 million developers. They are mostly digitally native, maybe they didn't grow up with an iPhone in their hand, but certainly are experts in business process, experts at using these applications. How do we get them these building blocks in a way that they can de-burden IT by doing some of this work?

Valuing IT

But again, there needs to be a change of mindset so that IT specialists are encouraged to support their non-technical colleagues and maximize reuse. He comments:

When are we going to start to change the system of rewards? Because we've rewarded IT work really based on building deep IT competency, hoarding your knowledge and protecting it. Because if you're the one human being that knows that particular back end system, you're very valuable.

Now you're coming along and saying, 'I want you to abstract your knowledge so that a less skilled worker can take advantage of that.' I don't know about you, but that feels a little bit concerning. And yet in reality, this composition idea says that if I do that, and it gets used 100x, other than me responding to that same boring interface request, time and time again, it's so much more valuable to the org.

So it's got to be the organizational system. We have to productize these capabilities and really get that consumption production measured and out there. And then I do think we have to look at how we're valuing and rewarding workers. Are we valuing them for composition? Or are we valuing them for hoarding the piece of the estate that they happen to own?

My take

A useful reminder that it's never enough to simply change the underlying technology, without at the same time changing mindsets, cultures and organizational structures.

Check out diginomica’s dedicated Dreamforce event hub.