MuleSoft wants to make enterprise data integration fundamentally easier and give everyone, not just developers, the skills and tools to create APIs. Just before Dreamforce last week, the Salesforce company announced a series of initiatives to do just that, including, Flow Designer (a new tool that lets users create integrations and automate processes without writing code), pre-built integration templates called Accelerators, training initiatives (via Trailhead), and updates to the Anypoint API Community Manager and Anypoint Exchange that make it easier for people to find and share APIs.
I had a had a chance to talk with Uri Sarid, MuleSoft CTO, about the announcements, how MuleSoft is making it easier for people to create APIs, how Mulesoft is connecting things behind the scenes for Salesforce customers, and the company's vision to make enterprise data integration more "plug and play." The following is an edited transcript of the interview.
Making the secret sauce of data integration less secret
Bill Detwiler: So let's not really talk about the announcements. We're going to talk about that in a little bit. What I really want to focus on is how MuleSoft is that secret sauce behind the scenes connecting all the different platforms and all the different products that Salesforce offers.
Uri Sarid: Yeah. Makes a ton of sense to talk about that. I actually would like to start even higher than that.
Bill Detwiler: Okay. Great.
Uri Sarid: Because I think that it's really important as we dive down and as we get into the technicalities and really how things work and what makes it secret and so on, to still keep context of that vision. So we're on a mission to make it much easier to interoperate and connect things together. And one way to approach that vision is to say, well, you know, MuleSoft to just somehow magically connect everything under the scenes and everything somehow is automatically connected and so on. I think technical folks know that really doesn't make sense.
Bill Detwiler: It's like the movies when they show the hacking and these just random characters on the screen.
Uri Sarid: But the vision is absolutely correct that in the end to the consumer, to the customer, to the person at the end, it should feel like magic. And the best technology feels like magic. So what can we actually do to allow our customers, which are companies, to create these magical experience sometimes automatically, what do we need to do under the covers to actually make that happen? And the other contention that I would have is that yes, there is a secret sauce. We should make it a lot less secret. So I'd love to talk about what is that sauce and...
Bill Detwiler: Definitely.
That was great. Google helped very much on the consumption, maybe not so much on the production. At some point, blogs came out. At some point, social media, like Facebook came out. And now everybody could actually produce as well as consume.
Bill Detwiler: So the barrier to entry was much lower.
Uri Sarid: Exactly. And that is the direction that we are embarking. We want to take all the world's capabilities and make them easier for everybody to consume, but then easier for everybody to also produce. And that requires some fundamental changes at the bottom and it requires a little bit of a different mindset. So people don't think about integration as this hard thing you do under the covers with some magic secret sauce and then eventually you get to this great outcome because that eventually probably never comes.
Making enterprise data integration more "plug and play" with APIs
Bill Detwiler: I think you hit on something really important. You mentioned interoperability and it's always been something that we've talked about in the IT space. But interoperability is really important now more so in the past because as you and I were talking before the interview, modern organizations deal with dozens of vendors, dozens of systems in different geographic locations. Talk a little bit about how important it is to make sure that all of those systems can work together to sort of unlock the potential for the data and the individuals.
Uri Sarid: Absolutely. I wish it were dozens. It would make our life easier.
Bill Detwiler: It wasn't hundreds.
Uri Sarid: We actually did a recent connectivity benchmark report. It turns out that the average enterprise uses almost a thousand different applications.
Bill Detwiler: Wow.
Uri Sarid: And that's because a lot of it has come up through the shadow IT space, so they're actually using a lot more stuff. They just don't know that they're using these things. So there's a lot of stuff that's actually powering the business. And with microservices and other trends, there's going to be hundreds and thousands of times more. So we've got to get really good at this thing and we've got to sort of at the core make things interoperable. You can't make things interoperable by business agreements between companies. That simply doesn't scale for combinatoric reasons.
So we've got to make them fundamentally more plug and play. And that's kind of where we're going is the secret sauce is really the API. And again, technical people have had APIs forever. But if you have a million different types of APIs and you have to be really good at each technology, it kind of doesn't help. It gives you a physical way to connect, but it doesn't give you an easy way to make things interoperable. So what our approach has been and what has been really successful for the market is this notion of when I'm going to connect to something, I'm going to, if necessary, build an easy API in front of it if it doesn't already exist.
In some cases, it already exists. And I'm a connect through that. And then the end result of that in many cases is I'm going to produce new APIs. Now what do we mean by API? Again, it isn't something that's going to be highly technical and difficult and very specific. The key with APIs is simplicity. And that's again, something that's very similar to what happens with microservices that do one thing and one thing well. So an API should expose a capability and expose it really well. If it's really well and it does one thing, it's likely to withstand the test of time.
And so now think about everybody's producing APIs because they need it for their own needs and all the connections go through these APIs. So what does that mean? It means that the integrations are actually a lot more robust because they go through these well-defined contracts and it means that a lot of APIs are being produced. And so when you go to build the next integration, you're more likely to find that the pieces are already there. And that starts to generate this cycle, this network effect that starts to do the the kind of creation and we've seen that in every other network.
We saw it on YouTube with videos. We saw it with Facebook as far as postings go. Every time you make it really easy to produce and consume and discover, the network effect kicks in and you get a tremendous amount of value generation. And I think that's the trend that will sweep along versus waiting for people to do it one by one.
More Salesforce Dreamforce news and analysis:
Demystifying APIs with Accelerators that support the Salesforce product ecosystem
Bill Detwiler: And what is it that MuleSoft is doing, either through the new announcements, through the accelerators, through the integration with Trailhead, people being able to train themselves and get skills to be able to create these APIs? What is it that you're doing to help with that, to make it easier to create APIs that are interoperable?
Uri Sarid: Exactly. So we're putting our money where our mouth is along all the channels. It actually starts with product. We have to invest in making at the product level the creation of API is a creation of integrations more and more accessible to everyone. Which means that those places that have unnecessary friction, we have to remove. Those places that are making it inaccessible for people to get at, we have to remove. So on the product side you will see we have a Flow Designer today and you'll see us completely invest in making it easier and easier for more and more people to work with tools like flow designer.
There will be others in the future that allows you to do that kind of composition very easily and you will see over time that people can also produce their own APIs. There are different types of APIs. We can get in the moment into what kinds of APIs. But when I described those, people will start to say, wait, an API is actually a really easy thing for me to understand. Even if I'm not an extremely experienced developer, even if I never considered myself a developer, wow, that's all they meant by an API, that's amazing. And then in parallel you also have to enable the people by giving them the skills.
And so we're now part of Salesforce and Salesforce has an incredible platform for skilling people up and scaling up the skilling. And so we're leaning into that. Then we've got a pledge that within five years we're going to have 100,000 integration trailblazers. Right now we're talking at scale. And then for people who need to do that right away, we also need to grease the path for them and say this is how other people have been successful. And so you'll see us roll out accelerators time after time again, but basically have everything you need to get going.
For example with integration with Salesforce, but they're accelerators for things outside of Salesforce. So for example, if you want to do e-commerce, how do I use Commerce Cloud? How do I look at both the prebuilt APIs, prebuilt integration templates, prebuilt examples, documentation, reference architectures, all of those bundled together and available out there and more and more of those will roll out. I think over time other people will produce accelerators and you'll have a content ecosystem to support the product ecosystem.
Bill Detwiler: And that's one of the things I wanted to touch on too. What do you think the industry needs to do, not just Salesforce, not just MuleSoft, but the industry as a whole to make these APIs? You talk about standardization. It happened with standardization around networking and we talk about standardization around code and languages. Talk about standardization around API.
Uri Sarid: Yes. Incredibly important. And again, standardization actually sometimes is literally around the APIs, like let's go use the same API surface. More often than not, it's actually standardizing around, for example, how do we model the data in similar ways, how do we have the same domain model for these things. There are a thousand ways to think of a customer. A customer is a customer and the customer tends to be described in terms of data shape maybe in several ways, but it still means that the customer. So if we can attach that semantic meaning to a customer and to an order and to a healthcare record and so on, then all of a sudden our systems can become smart enough to say, wait, I know how to connect this patient record to this patient record because I know their patient records.
And then the mapping can start to be done automatically. You already see inside a Flow Designer that we have machine learning to recommend mappings. At some point, those mappings will be completely automated when there's enough confidence inside of the system. So I think we will need to standardize some conceptual models, standardized some data models, standardize some APIs, and make sure that there's as much incentive as possible to share these kinds of things. That requires an organization mindset change. Instead of saying, it's all about me, you have to be open to sharing these things, at least on an industry by industry basis.
Bill Detwiler: Do you think that the age of, to use an overused term, walled gardens is over? I mean you see this competition, you see this vendor lock-in. It's still even in today's world of multi-cloud, multiple vendors of interoperability and the customer's demanding more interoperability saying, I don't want to be locked into this vendor. I want to be able to take my data. I want to be able to take my applications and move them across vendors. Do you think that it is impossible for vendors today to continue to push lock-in? Or those vendors just won't succeed in the marketplace maybe as they did in the past because customers are just demanding more interoperability and you'll just fall by the wayside or you'll get on the bandwagon?
Uri Sarid: Right. So longterm it doesn't work.
Bill Detwiler: Right.
Uri Sarid: Short term, it is still inherent to organizational dynamics to say, hey, I've got a good thing here. I own the platform. For example, I own a particular ecosystem. Let me tilt it towards ways that make me some revenue short term. Long term, it doesn't work. So the question organizations have to ask themselves is, am I going to go with a vendor that explicitly promotes interoperability, that shows what interoperability means that invites vendors in that has an inherently open architecture? Am I going to go with anyone that's going to be locking in?
And I do think that over time we'll see all the major vendors embrace interoperability, and interoperability over time should not mean well I work with them and I work with them. Interoperability means I work on some open architecture, some open standards. I am actively sharing information with other vendors in this space and as a result of that, our customers get the benefit of their choosing us for the right reason instead of choosing us because they're locked in.
Bill Detwiler: They have to because all my data, all the investment that I've made in this application, the training for my people is here...
Uri Sarid: Exactly.
Bill Detwiler: And I can't take it anywhere else?
Uri Sarid: Exactly.
Bill Detwiler: So we touched on a little bit earlier when you talked about sort of the technical side because our audience is a little more technical.
Uri Sarid: Yes.
Bill Detwiler: I'd love to wrap up there just with a little bit of a peek behind the veil a little bit or what is going on sort of? Well, what's maybe the most exciting to you on the technical side of APIs and what MuleSoft is doing right now?
Uri Sarid: It goes under the general area of modeling. So I'm a huge believer that when you have a good, powerful and yet simple model of the problem you're trying to solve, you're going to be incredibly faster and more effective at actually solving. And by models, I literally mean a modeling language and modeling framework and treating models as data and storing them appropriately and querying across models. So when we look at an API spec, for example, that really tells you in a machine readable way, how do I actually, what are the capabilities exposed by this API.
We don't look at it as a document. We don't look at it as a blog. We look at it as a graph of meaningful notes. What is a meaningful note? It's for example, this is a resource. This resource has the following HTTP methods associated with that. This is the data type that this resource exposes. And by the way, that data type is itself a little graph of notes. That is actual data. So now you can ask the graph, you can ask these API specs, are you guys consistent? What capabilities are you exposing? Is this information sensitive, and so on.
Wait, is this information sensitive? What does it mean to be sensitive? Let's go model sensitivity. Let's go model data types. Let's go model the business semantics. So this isn't just an HTTP post that returns a 201, this is a create invoice that returns an invoice successfully created. Well, how do we model the business semantics on top of this and link it to this actual HTTP transaction? And now when I have the business semantics naturally, technically, directly overlaid on top of this interaction, now I can create business user facing tools to allow them to say, what would you like to do when an order is created?
And I can generate a business event out of that and say, whenever a new order is created, I'd like to subscribe to that and create this, for example, a license. Now imagine business users orchestrating their enterprise saying, I want some magic. I want to say that whenever an invoice is generated or whenever a new license is generated, I'd like to also engage with that user in some kind of promotion to get them to do more. So these are the kinds of tools that I think we'll be seeing when we have this combination of true modeling data under the cover.
Bill Detwiler: And it's pushing that no code, low code philosophy through the API, right?
Uri Sarid: Yes.
Bill Detwiler: Which is, I think like to your earlier point, something we haven't seen before because people think of an API, it's kind of complicated or it's just ...
Uri Sarid: Exactly.
Bill Detwiler: The way I get data out or something...
Uri Sarid: Exactly. Exactly. And I think that's where I was saying before around different types of APIs, we should also realize the ability to publish events is also an API. It's also a contract. You may rely on me publishing events to you so that you can do something with those events. So we're investing heavily in AsyncAPI, which is an open spec for how do you actually capture those events and turn them into contracts. So where we're going is down underneath in the very structure in the same way that was the structure for the web with HTML and HTTP on content negotiation.
We're going down at the very structure of what we call application networks and saying, what are the standard pieces and the standard models that have to be in place to allow everything to be built on top of that in the easiest possible way?
ZDNET'S MONDAY MORNING OPENER
The Monday Morning Opener is our opening salvo for the week in tech. Since we run a global site, this editorial publishes on Monday at 8am AEST in Sydney, Australia, which is 6pm Eastern Time on Sunday in the US. It is written by a member of ZDNet's global editorial board, which is comprised of our lead editors across Asia, Australia, Europe, and North America.