Dreamforce 2018 - explaining MuleSoft's application network graph

Today's announcement of an application network graph by Salesforce's recently acquired integration business MuleSoft may leave quite a few Dreamforce attendees scratching their heads. For anyone who's wondering what is an application network and why does it need a graph, here's a brief explainer. And for those who want the tl;dr — it's a platform for automating integration to make it faster, simpler and more reliable.

As soon as I saw the announcement, I realized that it brought together several concepts that I'd heard in conversation over the past year or so with MuleSoft founder Ross Mason and the company's CTO Uri Sarid. So what follows is not so much my explanation as theirs.

What is an application network?

Before we get to the graph — which believe me is the really interesting bit — first of all let's quickly go over what is an application network. This is a term MuleSoft has been using for quite some time now to describe how enterprises should think of its API-based integration platform. It's really about changing people's habits, moving away from point-to-point connections towards creating reusable services.

Mulesoft thinks of the application network in three layers. System-level APIs communicate with data stores and other IT resources. Process-level APIs add operational functions, and the third layer are the engagement APIs, which provide the user experience. The goal is to break down the old monolithic enterprise infrastructure with its hard-wired connections into an adaptable network of reusable microservices that are readily available for use. Once in place, this becomes a platform for changing the way people interact with IT resources, says Mason:

As you build this capability, every time you add a node, it should add more value to the network.

You’re not building an architecture, you’re building a substrate for change. It’s really the consumers on the network that drive the value. We believe the application network will be how any employee or outsider gets value from your organization. They’ll know where to go because there’ll be an engagement layer. This is how you start to drive the operating system change, because you start to encourage people to self-serve.

There's more about how the application network works in practice in this interview I did with Mason back in January this year. I would add that it's not just a MuleSoft thing — this is the direction that integration — or digital connection as I prefer to think of it — is evolving across all of IT, as I explained in a recent piece about engagement, functions, resources — a connected digital enterprise architecture.

What does a graph add to the application network?

The other important aspect of the application network concept is that the network imposes a set of guidelines that govern how APIs behave. As Mason explained in that more recent interview:

Modern APIs have API management, which means you’ve got flow control, management contracting, authorization and authentication, negotiation and that stuff built in.

This was the origin of thinking about adding a graph to the application network — a graph being, essentially, a set of entity definitions and a map of the relationships between those entities. Or as CTO Uri Sarid, who earlier this year was using the term 'topograph', puts it:

In a nutshell what the topograph is all about is turning this otherwise unstructured data into structured data and being able to query across it.

He told me that MuleSoft had realized that when developers use the vendor's tools to build an application network, the tool can gather information about what they're trying to do. This is valuable information that later gets hidden behind the API when it's deployed. He explains:

Because we're part of the life cycle, we have the original source code. We have the reason, the intent that [the developer] is having. If we can make that intent, put that in a mathematical term, put that in a graph database, we'll have the answer.

This matters because it paves the way towards various ways of further automating and industrializing the process of building digital connections that have been hinted at in today's announcement. An application network graph shows the relationships between the various elements across the network, which can then be analyzed and interrogated, says Sarid:

All of a sudden it allows us to ask the application network questions instead of somebody going into every single piece of integration and trying to figure out what it was doing. And that I think just changes the mindset completely. It starts to say, I can govern, I can control — or alternatively I can encourage, I can come back and teach, I can make recommendations. I could figure out where data is flowing, whether that's for security reasons or whether that's for compliance reasons. So all of these things that used to require a lot of either heavy structure or a lot of individual code analysis or people following policies become programmatic.

Changing the mindset around APIs

This is a big change from how we've thought about APIs in the past, as WorldWide Web creator Tim Berners-Lee explained on stage at MuleSoft's annual user conference in May. APIs have traditionally been built without exposing their inner workings:

You don’t allow me to mess with it because you reserve the right to change the way it works afterwards. You’re going to provide a certain functionality ... and all the intermediate values that you arrived at, you keep to yourself so you can change those algorithms afterwards. So information hiding is a big part of the concept of procedural, functional programming, APIs.

The notion of the application graph is all about lifting the lid a little on this 'black box' philosophy around autonomous services and peeking inside to get some idea of how the service operates. This is not so that service consumers can insist that the provider builds it some other way, but so that they can exercise a more informed choice about their use of the service.

This is particularly important from a security and data protection point of view. Speaking in the same keynote about the concept of an application graph — again, calling it a topograph at the time — Sarid gave one example of why this matters:

Sometimes it’s very important for the enterprise to know what’s happening behind the API. [For example] you’re using it within the rules of the API, it seems to be OK, but the guy who implemented it didn’t realize you would be storing sensitive information. They never imagined, because they just gave you a string, that what you would put in that string is a social security number. It’s not something they could have anticipated, but it’s the kind of question you can answer with a topograph.

Sometimes it’s good to really not pay any attention to what’s happening behind the interface. And sometimes it’s critical to understand the downstream side effects of actually using that interface. With a topograph, you can do both.

Applying this knowledge stored in the application graph about the make-up of each API makes it possible to catch all kinds of errors at the design stage, well before deployment. Sarid went on to demonstrate an example of how the application graph could detect a potential point of failure where an application tries to send a data field that isn’t recognized in the target API.

Applying AI to real-world outcomes

The application network graph can also solve what Mason described to me earlier this year as AI's 'brain in a jar' problem. AI isn't much use unless it has some way of applying its analysis to real-world outcomes:

I liken the AI engines a bit to a brain in a jar, which is very smart. You can put loads of stuff into it, to get insights. But then when you actually have something you want to go and act on, there is no nervous system to go reach into the organization and automate a process, or a command, or an update, or just even basic things. It’s actually quite difficult ...

We think about APIs and the application network as a nervous system. If the brain is in a jar, if it doesn’t have that API network nervous system, then it’s going to be really difficult for AI to really take hold and see a ton of value in the automation space.

The graph adds the mapping that's needed to be able to bridge that gap between the AI analysis and how it can be applied to the real world of digital connections in the enterprise.

My take

Look past the geeky subject matter and this is a very important step on the journey to automate the enterprise through connected digital technology, and a platform for much more to come. One unanswered question — will this also be integrated into Salesforce's own technology infrastructure and will that mean more low-code integration tools for Salesforce admins in the future?