MuleSoft and Salesforce Q&A: Integration and Data

Still, there are challenges — including handling large volumes of data efficiently and balancing the increasing demand from customers for transparency, trust and good citizenship. 

How does a business overcome both in a timely and efficient way that works within the current constraints of the business model?

We spoke with MuleSoft CTO Uri Sarid and Salesforce EVP, Solution Engineering, APAC and International, Dan Bognar about the challenges and potential solutions. 

In part one of this two-part conversation, we’re looking at them from a technological angle — part two will tackle the human side of the equation.

First of all, how do you define ‘integration’?

Uri Sarid: I define it as composing capabilities that span multiple applications to meet use cases that naturally span those capabilities. Sometimes this is accomplished by synchronising data between those applications, sometimes this is accomplished by creating processes that span these applications, and sometimes you intentionally only do a part of the composition: you expose data and capabilities to others, so they may complete the use cases. The latter is becoming increasingly important.

Why do businesses require an integration solution?

Uri Sarid: Where people are running into serious, almost existential, problems is dealing with the complexity that arises from the sheer number of applications, systems and integrations within their businesses.

Nobody wishes they had less data or capabilities, but a lot of people don’t know what to do with all that richness, are concerned about the data quality or the security of the capabilities, and don’t know how to manage them. They might have 12 different systems in the business, but they have no structural way to make sense of the tangled web of data and capability.

Dan Bognar: Because of this complexity within typical businesses, most of the effort in an integration project is up front. Part of the reason for that is because an organisation needs a scalable and repeatable approach to solving integration. Every program or project is going to demand it. The simple act of having an integration solution means you’re able to reduce that complexity and deliver in a much more scalable manner. That is what businesses are increasingly looking for.

Why is the integration problem important to solve?

Uri Sarid: It’s about being fit enough to survive — ‘fit’ in an evolutionary sense, of meeting current needs adapting to change. If the current data complexity within businesses is not solved, the business is already at a competitive disadvantage, and life is only going to get more difficult for those businesses as they grow. These businesses that take over industries — the Ubers and Airbnbs — are the ones that put these pieces together well and rapidly, and, as a result, continually provide more holistic capabilities to their customers. Businesses that don’t get their systems integrated, over and over again, will fail.

Dan Bognar: The risks involved in not integrating are very real. It has two implications from an end-user or employee perspective. First, poor user adoption. If employees are using applications that aren’t integrated, they’re having to move between multiple applications to manually stitch together the data they need to solve a customer’s problem, which impacts employee experience. Of course, taking longer to solve queries means the customer experience is also impacted. 

Second, your time-to-value is impacted. You end up having a delicate dance between the parts of the business that want to move faster and be more agile, and the technology team that says, ‘First we have to deliver all of these integrations’.

An integration program gives you the agility that those parts of the business are looking for. If you don’t solve this strategically, you end up tripping over that complexity every time you want to make a change. That can become a bottleneck for innovation and can stifle insights, and therefore damage competitive advantage.

And data integration is easier today than it will be tomorrow — the amount of data a business holds will only increase.

How do we go about implementing a solution?

Uri Sarid: The only way strategic people can sleep at night is if we can sketch a structural path out of this mess. And we can. But if that path takes five years and requires the entire organisation to work on something that doesn’t add value other than getting out of a mess, then it’s not viable. They need a path that works quickly and allows them to not only deliver the things they need to deliver, but also to accelerate the pace at which they deliver.

Dan Bognar: Also, whatever path is recommended to a business must be respectful of the existing environment. Organisations begin to feel a sense of anxiety when they’re told they have to get rid of everything they’ve done up to this point and replace it with this new approach. The discussion has to be about how integration can be complementary or can add on to what’s already there. 

Uri Sarid: It is a challenge, but a structural path offers a map and allows the business to see a light at the end of the tunnel.

Dan Bognar: What makes a solution more achievable for CIOs and their teams is if there is a clear business outcome around what must be delivered, developed and understood across the business — not just in the IT department. This outcome defines the data insights that will be necessary for it to be delivered. With that clarity around business outcomes, you can then work backwards to figure out the integration requirements.

What does a solution look like?

Uri Sarid: The question is, again, how does a business become fit? In an integration sense, often it begins with systems that do not have well-defined APIs on top of them: no well-understood, supportable mechanisms to access the data and capabilities of that system. We begin by putting well-defined APIs in place, because that’s a major step to reducing unnecessary complexity in the business.

If various components are wrapped in something that takes away that complexity and makes it easier to use, alone and in conjunction with other systems, then it will make life much easier, now and in the future. That’s what we call ‘API-led connectivity’. 

So first, wrap it in an API that you treat as a simple product, then integrate it with other things you’re doing. And don’t wait until everything is wrapped in APIs — create APIs only where there’s clear near-term value, or where there’s clear strategic value to expose data and capabilities. In this way you naturally and sustainably create application networks, rather than applications that stand alone.

Dan Bognar: As Uri has indicated, the real benefit of this approach is that the APIs themselves become reusable. While you might invest in them for a specific project, you then have the ability to reuse them across the organisation in future projects. The network effect is that there are going to be libraries of pre-built integration that now exist in the enterprise, and they can be complemented by libraries of integration that third parties deliver.

Can you share an example of how that might work?

Dan Bognar: When you’re looking into an integration problem and you’ve already started to build out your application network, you’re not starting from scratch. You’re saying, ‘Okay, let’s see what exists in our current API library, and what third parties can provide. If there’s a gap, I can fill that myself’. It gives you so much more speed, as well as choice and flexibility. It’s about delivering a solution faster, often with higher quality, as well as less complexity and less cost.

Uri Sarid: Exactly. For example, if your business is growing very quickly, you might be spending a lot of time onboarding new employees, but a simpler way would save your company many hours. So for that faster and simpler solution, you make sure there’s a very good API in your HR system for ‘Where do I put information about an employee?’. Then you take your talent management system and make sure there’s an API for, ‘How do I find information about a candidate?’.

Now you have a simple way to deal with candidates who become employees. Importantly, you then take the result, which is your onboarding process, and you expose that as an API, too.

So tomorrow, if you acqui-hire an entire team, or you have a new talent agency, or you want to write a mobile application, you just plug them into that process. And you can extend that process easily, or measure its KPIs. You don’t have to reinvent or potentially break your process every time a new need arises, and you can offer the process to new constituents rather than having them work around it.

Dan Bognar:  It’s so important to respect what you already have in place in your business — then optimise what exists today. Don’t destroy what is already there but don’t simply accept what is already there either.

Ultimately, what integration will deliver for the employee is a much better experience and less friction in how they solve customer problems. They’re not having to switch across multiple applications to piece things together. Everything they need can be seamlessly brought into their application, giving them immediate insight. It improves productivity, engagement, and the experience they can deliver to the customer in terms of responsiveness. It creates an enormous number of downstream benefits.

In part two of this conversation, we’re focusing on the humans — because the other part successfully innovating with emerging technologies is bringing people along on the journey. 

Why is trust important and how does integration help? What is the role of the CIO and CTO, and of other employees? And what do an organisation’s culture and ethics have to do with enabling the right kind of technological transformation?

Great technology, it seems, is all about being human. Find part two here.

We spoke with more than 100 IT leaders in North America, Asia Pacific and Europe about the 10 priorities driving IT now, and the skill levels and strategic maturity around each. Download the Enterprise Technology Trends report to find out what we heard.