THE MULESOFT ACQUISITION AND THE IMPORTANCE OF CONTEXT PART I
Salesforce recently signed a definitive agreement to acquire Mulesoft for $6.5 billion. This represents a 36% premium over their current share price. Enterprise Service Buses (ESB’s) are not a particularly new technology, so what is it about Mulesoft that allowed it to gain the kind of traction it has seen in the market and why was it so valuable to Salesforce in particular?
This is part one of a three-part series discussing the recent MuleSoft acquisition. Part 1 will look into some of MuleSoft’s strengths and how they might complement Salesforce. Part 2 will highlight a few areas where MuleSoft’s functionality overlaps with AppBus and how the two solutions can complement one another. Part 3 will dive a little deeper into the unique AppBus eXperience Platform and why it is required to fully realize higher level organizational goals like digital transformation.
The first reference to the term “Enterprise Service Bus” is attributed to Roy W. Schulte from the Gartner Group in 2002. Long before the phrase “microservice” entered the popular vernacular, enterprises have been pursuing digital transformation initiatives aimed at making their IT portfolios more modular and service centric. If you ask any CIO what his vision is for his company’s IT organization and it will probably sound a lot like his predecessor from 10 years ago. The point here is that implementing true digital transformation is an old problem and improvements in the tooling to achieve this transformation have only contributed to incremental gains.
MuleSoft, more than any other ESB on the market, does a good job at meeting the needs of enterprise developers. The word “enterprise” here carries a lot of meaning because it can often be relatively easy to provide tooling for small teams with a significant or considerable degree of control over their testing and production environment. Within an enterprise, there is a high degree of specialization, globally distributed stakeholders and internal review processes that can make a little mistake or miscommunication result in weeks of delays. Mulesoft makes it easy for architects to design API’s and communicate project goals to backend developers. The backend developers are empowered through studio tools, which combine the freedom of coding when appropriate and GUI based flow tools to help keep the project manageable as it grows in complexity.
The goal of a tool like MuleSoft is to make new and existing services more standardized, connected and discoverable. It may seem self-evident, but why do enterprises value these kinds of integrations and why is Salesforce willing to pay 6.5 billion dollars for a tool in this space? As one of the founders of Unix, Doug McIlroy, said “Write programs that do one thing and do it well.”. Often the solution to any well-defined problem can be most effectively addressed by adopting a best of breed solution. However, over time this leads to an explosion of point solutions, and this ultimately leads to “tools consolidation” efforts that seem to go on for decades. Much like Dunbar’s number, there is a fixed limit to the number of tools any organization can be expected to manage effectively when they exist as standalone solutions. MuleSoft helps create an API economy which allows organizations to keep some of their best of breed solutions (at least those with pre-existing API’s) while integrating the functionality they provide in valuable and stable ways.
At the end of the day, enterprises are in the business of making money. Therefore the data contained in their Customer Relationship Management (CRM) system is extremely valuable. The most successful projects in IT (and the ones most beneficial to a project leader’s career) are those that can be shown to directly affect the company’s bottom-line. However, for many managers in IT, there can be a few degrees of separation between the value they are providing to the business and how the business generates revenue. It is often easier to sell the business on a solution that reduces average call time by 20% in your contact centers than it is to get them to buy into a new configuration management solution. This is not because the problems that operations teams are solving are less valuable to the business, they are just often harder to tie to green dollars.
Salesforce’s acquisition of MuleSoft is exciting because, if appropriately developed, it should effectively allow IT service to access data that impacts the business. Salesforce will be able to provide an added layer of context that can often be missing from integrations, allowing for more valuable services to be created within companies. As an example, let’s say that your company runs its own datacenter or rents space at a colo. With this approach, your company could potentially save a fair amount of money relative to using the public cloud. However, your company loses a lot of the flexibility that comes from using the public cloud, so capacity planning becomes very important. With the new MuleSoft acquisition it could be possible to build an API that uses sales pipeline data to model capacity that automatically recalculates when changes come in. This is just one example of how CRM data that was either not previously used by your IT organization, (or if used, it is likely stale), could be leveraged to help run the business more efficiently, ultimately saving the company money.
Context is so important to businesses because it informs a user’s choices as they work through a business process. The easier information is to surface, and the more intelligent a business’s systems are for processing contextual data, the more effective its workforce is going to be. One valuable piece of context is the user’s activity as they navigate through various applications during a workflow. While MuleSoft does an nice job at allowing in-house developers to build API’s, ultimately how those API’s are delivered or consumed by a human are outside the scope of the MuleSoft’s solution. Additionally, MuleSoft generally assumes that the systems you are interfacing with will have some standardized access protocol (JMS, Web Services, JDBC, HTTP, etc…). This leaves a number of business-critical application out in the cold, unable to participate in the API economy you are creating. In Part 2 we’ll discuss how AppBus’s integration technology and edge delivery mechanism can compliment a MuleSoft deployment by providing this valuable context to be related to a user’s workflow and by allowing legacy applications to participate in your company’s API economy.