SaaS Integration Headaches: Some Companies Struggle More Than Others

Loraine Lawson asked Regev Yativ, president and CEO of Magic Software Enterprises Americas, which companies experience more problems with SaaS integration and why he thinks integration as a service won't catch on. Magic Software offers iBolt, an integration suite, and uniPaaS, a platform for building and deploying full client, RIA and SaaS applications.

Lawson: When I spoke with Magic Software last, you had just introduced iBOLT and were considering offering it as a pure SaaS offering. Where do you stand with that?
Yativ: I think that was maybe a misunderstanding or briefly in his (Editor's Note: Avigdor Luttinger, vice president of corporate strategy for Magic Software) mind. Maybe we will have such plans, but we don’t have currently a SaaS version of iBOLT. Maybe we were talking about the other product, which is the developer (Editor's Note: uniPaaS).

It basically enables our customers to create new applications for deployment off-premise. So basically, if you had a traditional Magic application or a traditional uniPaaS application, if you had it written as a client-server application, today we are able to provide our customers with several additional options to deploy the same application - with some modifications on the code - but to deploy the same applications as rich internet application or SaaS.

So just to give you an example, if we have a partner that has about 50 customers in California and they would like to come up and offer the same application to customers in Europe or in Amsterdam or in Paris, but they don’t want to create their own infrastructure in Europe and develop applications in a way that they will have to install it in Europe, so they would like to reach new opportunities using that SaaS model. Today, with the tools we have, they can actually take the same application, redeploy it with some modification as a SaaS application and then simply do the marketing, the sales efforts in Europe to actually enable the customers to use that same application remotely, off premises. So that one we actually came up with and our customers are pretty happy with that.

I can tell you what we do today for all those companies that have software as a service. Basically we do have a special connector for Salesforce.com, for example. We are an official partner. We are on the AppExchange portal of Salesforce, so if you look up iBOLT there, you will find us there. We are very active in performing projects for customers. Right now, we do integration between applications whether they are on premises or off premises, so we do offer both options.

Lawson: Integration, along with security concerns, remains a huge concern for people when they look at moving to SaaS. It seems to me there are a couple of different emerging models to deal with this. One is to bring in a systems integrator, another is to buy a third-party application, such as your iBolt, that handles the integration, but there is this other option – where integration is handled in the cloud, either as part of a SaaS bundle or as integration as a service. What are you seeing in terms of SaaS integration? Do you ever deal with SaaS vendors or do you more often deal directly with their customers?
Yativ: I think if we have to be honest here, the SaaS vendors are shying away from integration. I don’t see the classical SaaS vendors out there - they basically leave it up to integration players and those who have integration products like us.

So they really are keen on cooperating with us on solving integration challenges and I agree with you that one of the major issues, scaling up SaaS applications or sometimes just the first installation. has this obstacle of, “Okay, fine, so I can have this off premises but how do I connect this with the rest of my systems?” And some of the systems are also on premises.

So what we see with our customers is, at this stage, they are not really talking to us about where the integration flow will be. They're more interested in solving once and for all the integration challenge. Right now, we are speaking with one or two vendors about the development of such a concept that basically when they actually deploy the application they will have a built-in component that does the integration and that is happening also off premises. It’s really in the discussion stage.

Most of the time, we deal with the customers of these vendors and we deal with ad hoc integration challenges. So they come to us and say, “Well, look, how is that application going to fit into the general environment I currently have,” or, “How does that fit with the SOA infrastructure I am trying to put in place,” etc., and we help them solve these challenges. But it’s down on the local level with the customers.

Lawson: Are there security benefits to keeping integration on a company's premises, as opposed to in the cloud?
Yativ: There are some security advantages having your integration process on site; however, I don’t think it’s a compelling factor for the customers whether to do on premises integration or off premises. I think there are very good solutions today - Magic has them - to deal with security off premises. So I don’t think it’s a factor that prevents this field from being progressed. I think it’s just the customers, what we see now they don’t demand this.

I can speak to what they gain from us, but in general I think they gain probably a better ability to change flows. I think agility is achieved faster if you have the machine running in front of you - the monitor is there, you can see how the flow is running on premises and change it on the fly.

If you develop the off-premises model in a very sophisticated way, you can have the same amount of agility, but I don’t think the market is there yet.

Second, I think a lot of customers are happy in terms of the business model. They are happy to pay a certain amount once, solve the integration challenge and then move on. A lot of them are not very happy to pay continuously, you know, the SaaS model payment for an integration partner. They would more look at it as a one-off investment, we integrate, we finish with this and we move on with the rest of our business. Do you understand what I mean?

Lawson: Are there companies with more integration problems than others when trying to use SaaS? Is there a way you can know that this is going to be a real challenge for a company going in?
Yativ: If you're running a very straightforward stand-out set (e.g., SAP and Oracle database) of applications, the challenges would still be there, but it’s easier to hook up into these applications and solve it.

Let me start from the first type of integration-challenged customers. We see a lot of customers with tremendous applications, huge applications that are legacy, homegrown sometimes, something they developed 10 to 12 years ago. We see a lot of customers that wrote applications on IS-100, RPG, Cobalt, stuff like that. When they want to hook them up to the SaaS world, they find it very challenging. The first type, when we look at their project and we say, “Okay, here we have a lot of work” or, “Here we have more work than the usual,” would be these kinds of companies. So that’s the first type.

And the second type of companies have a lot of logistic requirements or they have people running in the field, so they have mobile applications. They have many, many third parties reporting to them, so they have needs for time sheet integrations or they have suppliers working with them online and they look up directly into their ERP, so they have different kinds of systems that support that. So the complexity of logistics in many cases drives application architecture complexity and this is where we add value even more.

These are the two types that I see during my meetings with customers that have more integration challenges.