Mulesoft CEO Brent Hayward - orchestrating enablement of the business versus narrowing the developer bottleneck

There is so much digital development work to be done that it is now an insurmountable task for the developer community to address alone, and if they spend most of their working time making minor adjustments to component apps in much larger applications, the bottleneck is only going to get tighter.

This is the view of Mulesoft CEO Brent Hayward, who sees the only option available to businesses as a two-fold change in direction: 

1. Change the way the existing developer community is incentivised, so that they no longer see developments, such as AI, no-code application building and APIs, as direct and imminent existential threats.
2. Make widespread use of those new technologies to ensure that businesses stay competitive.

On the second point, Hayward see those three technologies cited above as playing a central role in achieving both goals. In a variety of combinations they can together open the doors of applications development to the vast army of 'reasonably-tech-savvy-but-well-versed-in-the-business-processes' exec,  who know what needs to be done, but don’t have the full coding skillset to achieve.

With the addition of AI, no-code automation and APIs, many of the smaller applications modifications and adjustments can – and in Hayward’s view should – now become part of their job-spec. This will free up developers to address the tasks ahead that really warrant their talents, of which he feels there will be many: 

“We only have 25 million developers in the world, it's the slowest-growing class of technical resource. In the meantime, the fastest-growing class are these knowledge workers. I don't think developers will ever cede authority to the business user for security and governance and data trust, they kind of can't. But they certainly can give them the functionality to be able to work more effectively in their context. They may not understand SAP, but they sure as heck understand the words 'inventory’ and 'retail store'. So any technologies that allow them to participate in more digital work just means the developers we do have are working on the right stuff, the tough, differentiated stuff.

Automating the interconnect

Generative AI is, of course, this year’s solution to just about anything anyone can think of, but in this particular use case Hayward sees it having a real role to play, especially given Mulesoft's status as part of Salesforce and Salesforce has a high demand for re-usable blocks of code. He sees the need for such blocks, and the rate at which they are re-used, only growing.  

He feels the impact of AI generally will be profound in a number of different ways, especially when the goal is to deliver the right data to the right application at the right time. The big demand will be increasing the automation of interconnectivity and what is passed across it, for that will include not only tasks for the latest cloud-native applications, but also legacy systems or applications that don't have an API or are an old web service. On the other hand, some will be no code, applications where that integration is already understood as an open API.

Connectivity is also about them being able to do something constructive with that data. Because Mulesoft is already used to connect CRM to all these systems, Hayward sees the type of workload the tech-savvy exec could take on as being those where joins between functions can be created that improve function or end-user service levels. A case in point there might be the ability for a customer to change a delivery date, a workflow that can now be automated by such staff without going near applications such as NetSuite or SAP, he suggests: 

 “Fundamentally, Mulesoft is kind of an orchestrator of connected applications. I think AI is simply going to double down on the importance of being able to get data in and then automate back out. I think we're going to find close-to-real-time will end up being the goal. I mean, a lot of these processes are already real-time and what's been missing is we just haven't linked the speed of the AI making a recommendation with the speed of the action actually happening.

Despite that being the goal, Mulesoft still holds the position that humans are very much part of that loop. There is still a real need to make sure a process works correctly before giving it over to full automation, and that it is a process worthy of being automated and works reliably. From the MuleSoft perspective, there's going to be a new explosion of endpoints and AI-driven prompted services and there will not be enough developers to build them all.

But AI is also going find a role as an assistant to every developer. In Hayward’s view, AI is going to recommend code snippets, remind and find code that can be re-used, remind developers if they are not following the security or governance policies, and will literally present the developer with the material needed to build the code.  He sees that being a great boost to productivity:

What's cool about AI is I think it's going to really blow the doors off the number of use cases, because we're going to be able to tap into the collective knowledge of these systems. So when I want to look up all inventory for a product in South London, I don't even need to know if SAP exists in the organization. And I think it's more interesting work. They're no longer the bottleneck. They're the enabler of the business versus the bottleneck.

When the job title says '...and orchestrator'

There will need to be changes in the mindsets of staff. Hayward smiles at my suggestion of execs coming to earn '...and orchestrator' as an addition to their existing job title, but acknowledges that, in terms of the structure of such a job, this is already starting to be seen in practice. At the same time the traditional protective mindset of developers is now starting to change, he argues: 

I think the younger generations coming out of school are taught that you just don't start with a command line. You're always composed. Ninety-nine percent of all organizations have some form of an API, and so when you look at any of the newer modern applications, you really are a composition of other external and internal capabilities.”

The older generations of developers, especially in the legacy world, still tend to be protective of their own IP, much more tied to their job security and self-care. As a result, the tendency is to want to create 1,000 versions of the same interface, because that protects their job, whereas writing one API that gets reused by thousands does not. This is where Hayward says that C-level execs now need to look at incentivising these people very differently. The need is for incentives to drive the organizational behaviour, he advocates: 

What I've seen when that happens is they're overjoyed because there's a lot of calories spent in protecting your IP. They end up doing the same tasks over and over, it's kind of miserable. They stop innovating because they're spending most of their time maintaining.

APIs are, of course, a cornerstone of orchestration, but to make this happen they do need to change and develop from their original conception of proprietary interface for purely intra-single-vendor connectivity. Today they have to be agnostic and able to work with the world. This is driving subtle, but significant, change in technology, and as Hayward observes, this comes in three flavors. For a start, they have to be discoverable:

The whole point of composition is that other people can build things with that building block. So it has to be designed in such a way that it is discoverable.

Then they have to be described, ideally in a common language, in such a way that someone who is not an expert in the underlying technology can then use them. It must be clear what they do, how to call them, and what data to give them in order that they can function properly. But there is no need to know anything technical about the application itself.

Lastly, they have to be easy to plug in to other composable services, because composition is all about the interoperability of the services. Hayward suggests there are probably some other capabilities, such as monitoring, governance and security, but they key is being able to expose these units of value.

In a way, therefore, does he see the API growing to become analogous to the container? He responds: 

The short answer is yes. I mean, you are literally describing the 'any point platform'. There's a palette of reusable connectors, there's a palette of templates, there's a palette of snippets and code standards and API's, and the starting point is composition. So, whether you code, you're actually auto-filling in the composition, or whether you drag and drop with no code, you're dragging, dropping the components and configuring what they do. What's really cool is a generative AI will be putting a prompt inside that interface. You can just describe what you want and it will step out and start to put in and recommend the code that can be used.

This whole topic is even on point when it comes to another crucial agenda item – sustainability. Reusable code can certainly play a part in at least slackening the speed of exponential growth in data Hayward observes: 

There are copies of copies of copies of data. Anytime you have something that gets used over and over again, and recycled and recycled, which is what composability is, versus having copy after copy after copy of a file sitting out there needing to be digitally-touched, digitally-maintained, you certainly get those sustainability economies of scale.

Within most organizations we run into, they spend almost 70% of their IT budget on just maintaining what they have. And oftentimes, it is hundreds and thousands of copies of the same object. The interesting thing there is that figure has rarely changed in the last, how many years? I think it's actually gotten way worse, because I think systems have become more complex.

My take

That figure of 25 million developers worldwide is important to consider, for while it sounds a large number, it is parsimonious in the extreme when spread across the global need for new applications development. Their role really should be working on all that new applications code that has yet to be started, and pulling together code from across the open source community to help build them. Modifying a business process to meet new needs is actually best done by the people who understand and work with the process, and now the tools that can automate the technology aspects are readily available there is no reason why they should all get the chance to become 'orchestrators.