Listen to my interview with Richard Nucci, chief technology officer and co-founder of Boomi, which provides integration in the cloud to link up SaaS applications and other services.
In this podcast, hear why enterprises are looking to connect with data from their SaaS applications, and learn what's different about application integration in a multi-tenant SaaS architecture.
Listen to or download the 9:49 minute podcast below:
---Transcript---
PW: Rick, when people buy SaaS applications, I think typically integration hasn't been front of mind. In fact, I think in the past, in a lot of cases, it's been business managers buying SaaS precisely because they didn't want to end up with a complex enterprise IT project — they wanted to get stuck in with the application. And I think as a result of that, there's a bit of a myth that's grown up that SaaS applications don't integrate. And yet here you are, you obviously decided that they do, because you set up a company whose mission is indeed SaaS integration. So why do you feel there is a lot of demand for integration out there in the cloud?
RN: Yeah. Sure. No, it's a great question. And as you said, one we definitely spend a lot of time thinking about. I mean the first point I would make is that the approach of SaaS ISVs by-and-large is to go relatively narrow but very deep in their application functionality, versus trying to accommodate a very broad but then shallow set of functionalities. And so the net out of that is you very quickly see a proliferation of SaaS apps across the enterprise. And any time more than one of those SaaS apps is housing data about your customer, you have an integration problem that's going to come back and bite you at one point or another.
The other trend I'd say that you accurately point out is, you have the beauty of SaaS as, I can get it running quickly. Certainly, the SaaS ISVs are doing their part in minimizing the integration story a little bit. But the very interesting trend we see is the customers, the consumers of SaaS, are starting to become wiser.
Now it could be because they're purchasing their second SaaS app. It could be because they're talking to their friends who already have put up their first SaaS app, and they're beginning to ask for the integration solution in the sales cycle. And the answer, 'Well we have APIs, you can just code to those APIs,' just doesn't cut it. I mean because to your point, we're talking to divisions of companies not IT departments, and so the answer to that integration story needs to be something that the division — that group — can consume without having to bring in resources and proliferate that implementation cost and that setup cost.
And then, the final point you made that I thought was very interesting was the perception of SaaS not being able to be integrated, period. Yeah, certainly a myth, and the thing that I always like to point out is, there's this really great opportunity of being able to accomplish a very, very meaningful integration — and that is made possible by and large by the multi-tenant approach that a true SaaS ISV is going to take.
And what I mean by that is, when the API is forced to be delivered in a multi-tenant environment, what the SaaS provider does is, he exposes not only his business objects — customer data, invoice data, whatever it might be. But he also exposes any customizations that a particular tenant has made in his SaaS application.
And that's unheard if you look at the enterprise world where they stand up an API to the app, and if you have customized the app, well, you have to customize the API. And now you have this big code management problem.
Whereas the SaaS ISV, if I go into Salesforce and I add a custom field to my customer screen, it just shows up in the API. Well, how great of a way to make a very, very meaningful integration possible that is not just the base data — which is one value prop — but also my data, incorporating my business processes and the things that are unique to me as a customer of that application.
Right. Right. Okay. So the multi-tenancy angle here is actually sharing the integration, so that many different customers can actually use the same infrastructure to do the integration. And because it's shared and it's multi-tenant, it's flexible and adaptable to the way that each customer has amended the application.
Exactly. So you've got your base API infrastructure, and then a programmatic way to say well, tell me about what's unique to my application. And then in an application such as Boomi AtomSphere, we can very easily expose that in a nice data-import wizard and show them their data, their formats, their customizations, without having to do any special setup on the SaaS ISV side or do any sort of gymnastics; it just becomes available. So like I said, a very meaningful or complete integration is now possible.
And there's an angle here also which is around the fact that you're doing this as an independent integration vendor, so that the multi-tenant integration is separate from the multi-tenant application and therefore remains loosely coupled — doesn't get built into the application in a more fixed or hardcoded way.
And I thought interesting this week, there was — or in fact, last week — there was an announcement by NetSuite that was all about connecting NetSuite's ERP product with Salesforce.com's CRM product. And of course, those companies have been traditionally huge rivals and the idea that they would connect to each other used to be anathema. They really wanted customers to choose either one or the other platform. But I think the power balance seems to have shifted now to emphasize the cloud over an individual vendor.
And that I think is why perhaps we're seeing more opportunity for third-party integration vendors like Boomi — and I think there are several other vendors in this announcement by NetSuite — that mean that the integration can be done better if it's independent, rather than having a point-to-point connection from NetSuite direct to Salesforce. Is that — the need to use an intermediary to have the more loosely coupled connection — is that why that announcement did involve third-party vendors like Boomi?
Yeah. No, you hit the nail on the head. I mean the temptation — and you do see folks doing this — the temptation is what you just said, which is, 'Well, I'll just hardcode my integration to the other SaaS app,' forgetting the point we were just discussing, which is the multi-tenant nature of these applications. You can hardcode an integration when you're dealing with an API that does not have any nuances from tenant to tenant to tenant; exactly the same data source. So you're talking about a Facebook API, or a Twitter API, or a WebEx API. By and large, those are not changing per tenant.
But when you're talking about connecting to Salesforce or NetSuite, each tenant will do things differently. And you're exactly right, you can't hardcode that — because what you're hard coding is something that the very first customer who goes and uses it, again, he will have added his own field, she will have added her own field, and all of a sudden that pre-built integration is incomplete, or in worst case, just flat-out won't work.
So the role of an intermediary is to allow you to consume in a self-service way, in an on-demand model — which is Boomi's whole focus — just like you're consuming NetSuite, or consuming Salesforce, you can consume the integration setup experience that is personal to your business and your environment. And that's both the complexity of doing this multi-tenant integration, and, yeah, it's the reason why NetSuite is going to say, hey, integration is really not our business. We're happy to be reliant on an intermediary who understands these nuances that I'm describing and can really focus on it and nail it.
And do you think that customers are comfortable about dealing with lots of different providers in this way? Because it does — instead of having a single throat to choke, as it were — you're suddenly dealing with an integration vendor, CRM vendor, ERP vendor, collaboration vendor. Are we going to see customers getting a bit fed up with dealing with multiple providers, or is there another way — let's go to a new channel of solution providers, for example — to take on some of that headache?
Well, that's — I mean you just nailed it. Yeah, I mean the role of the solution provider, 2.0 if that's what we want to call them, yeah, becomes huge. Because certainly there's going to be a cultural mindset of the one throat to choke. I mean you're exactly right and certain organizations are going to want that and demand that and what we'll hear is the multiple SLA challenge, which is that I've got multiple SaaS apps and they have different SLA's, different maintenance windows, and so how do I manage that?
And the answer is a channel provider — a solution provider as you call them — can offer such a very explicit vertical expertise and portfolio of applications and services. And because they're not going on site and installing this stuff and having to be experts at operating systems, and databases, and all this sort of stuff that they would have had to do in the old days — where yeah, they're really going to be limited in terms of the amount of applications they can really become proficient in and truly being able to manage for their customer.
Now, when all that burden is shifted onto the actual ISV, and their focus is solution expertise, business process expertise, now the customer engages that solution provider. The solution provider brings with him an arsenal of pre-thought-out, best-of-breed SaaS apps that are pre-integrated yet customizable to meet that customer's unique workflow. And I think that's a huge opportunity for sure and something that's really just in its early days.
Leave a comment