Why SaaS Integrations Are Trickier Than the Average Integration

Loraine Lawson

Every time I write about SaaS, some astute reader responds that integration challenges are not unique to SaaS and, in fact, have plagued on-premise applications for years.


Take last week, for example, when I wrote about Forrester's prediction that SaaS integration solutions would achieve "minimal" success. User372756 posted:
"Integration as a challenge is not new to SaaS. It is certainly not trivial or unimportant. However that is not a reason to not go SaaS."


Well, of course that's true. But some would have you believe that SaaS integration is also no better or worse than on-premise integration, and that's where I've got serious reservations.


This article from Computerworld confirmed my suspicions. It contends that SaaS integration is, indeed, trickier than on-premise integration for a number of reasons, including that SaaS is frequently adopted as a rogue solution, without IT's involvement.


True, this could and has also happened with on-premise applications. But SaaS makes it oh-so-much-easier for divisions to adopt a solution without so much as a wave to the CIO.


It's a lesson that Hines Interests, Ltd., learned the hard way when it launched Hines Real Estate Securities, a real estate investment trust business. The company relied heavily on SaaS products and soon found itself mired in "a tangled web of integrations linking SaaS to SaaS and SaaS to on-premises applications."


The article notes that it was like the old days, when nothing in the company infrastructure could share information. The piece even offers this grim warning from Hines Real Estate Securities Business Systems Architect Benny Lasiter: "When you're heavily reliant on SaaS, you're putting yourself in the position of siloed data once again."


Other factors that can complicate SaaS integration include API upgrades, changes to your systems' business processes, or new features in the SaaS product.


The article draws the analogy between SaaS integration and other B2B integrations, with the moral being that you need to practice the same due-diligence and strategy to SaaS as you would B2B. Otherwise, you may run into problems, including latency issues and difficulties with year-end-reporting.


What I like about this piece is that it doesn't just gripe about the problems with SaaS integration, but offers guidelines for avoiding these problems and a real-world example of how Hines solved its integration problems while avoiding future vendor lock-in.


You'll note this article is also part of a series called "SaaS Surprises." Links to the other articles, which includes a look at SaaS functionality and PaaS (platform as a service), are included in the sidebar on the first page of the SaaS integration article.

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


Add Comment      Leave a comment on this blog post
Mar 23, 2009 4:55 PM John Moore John Moore  says:

Really good article.  I have been developing SAAS applications for 10 years now and it was easier for customers when they only had to perform the integration with one SAAS vendor.  Through the years, as companies have correctly looked at the ROI for most SAAS solution they are now seeking to tie in multiple SAAS products.  This is great as long as customer's and SAAS companies remember:

-  These integrations are more complex, as noted.  If the SAAS companies provide robust APIs or Web Services the problem is somewhat minimized so it is imperative for SAAS providers to keep this in mind.

-  SAAS products are simply tools in a company's toolbelt.  It is often beneficial to work with companies that have capable services organization that can consult and ensure that the tools are properly integrated into the business processes, even helping the businesses refine and improve their processes as the implementations occur.  Of course, it depends on what kind of application you're discussion.  For example, my eFax account doesn't require me to spend time with their services team.  However, if you were to roll out a more complex system, say a CRM solution, it would be different.



Mar 24, 2009 11:05 AM Benny Lasiter Benny Lasiter  says:

You may have taken my quotes out of context, or at least added implied meaning which is not true.  Perhaps the wording could have been more clear but seeking confirmation of one's suspicions doesn't exactly lend itself to open consideration of all interpretations.

Hines Real Estate Securities in no way went down the path of implementing SaaS solutions without careful planning and integration for each new vendor's data as they were brought on board.  We recognized how many SaaS vendors do not integrate with each other (although this is much less a problem than five years ago when we began) and saw the need to integrate those "silos" of data with each other, as well as with our internal applications.  My personal approach was that SaaS presents the same integration challenges everybody has seen before, thus the reference to being back in that situation.

Regarding the "tangled web" of integrations, those were the author's words, not mine -- in Hines' case, it COULD HAVE created a real mess if not managed properly but it did not.  In fact, I would choose to refer to our situation as a complex system of integrations -- all very carefully implemented and managed to meet the needs of our organization.

Please do not make the assumption or give the impression to your readers that Hines got itself into a bad situation from which it had to be rescued.  In short, we quite successfully used proactive analysis to recognize potential pitfalls to our SaaS-heavy business environment and developed an implementation strategy to build a long-term architecture without actually suffering through learning anything "the hard way".

I was specifically invited to contribute material to the article because of our success, not our failures, and to help make others aware of the POTENTIAL issues they might face in similar projects.


Benny Lasiter

Business Systems Architect

Hines Real Estate Securities, Inc.

Mar 24, 2009 11:45 AM Loraine Lawson Loraine Lawson  says: in response to Benny Lasiter

I under, Mr. Lasiter. However, I don't believe I made assumptions or took information out of context, since the article itself put it this way:

"When Hines Interests Ltd. launched its real estate investment trust business, Hines Real Estate Securities Inc., as a complement to its real estate development business, it built the IT infrastructure around a bevy of SaaS products. But the need to exchange data between various hosted applications -- transaction processing, CRM, literature-fulfillment, and expense and vendor payment systems -- created a tangled web of integrations linking SaaS to SaaS and SaaS to on-premises applications."

I can agree that, given the information you've provided here, I wouldn't have used the term "grim warning," although, really, it is a good warning for other companies.

Mar 25, 2009 9:43 AM Rhett Glauser Rhett Glauser  says:

A quote from the same Computerworld article:

Zamil Industrial ITG, a construction products manufacturer in Dammam, Saudi Arabia, had no problems integrating its service-oriented architecture middleware with a service management application from Service-now.com in Solana Beach, Calif. "We implemented our SOA-based Oracle Fusion middleware before we went for Service-now.com," says Ahmed Abdrabalnabi, service planning manager at Zamil. Integrating it with employee information residing in Active Directory and an on-premises human resources application was "as easy as drinking a glass of water." The process took just a few days, he says, but that's because integration requirements were evaluated upfront to make sure Service-now.com was the right fit.

A growing crop of SaaS IT management applications, including Service-now.com, are becoming quite popular with enterprise IT. These are obviously sold directly to IT. No surprises.

Every enterprise IT software deployment requires integration with both SaaS and traditional on-premise applications and IT pros plan for these integrations. It is the vendor's responsibility to make these integrations as easy as possible.

Our customers' expertise, Web services and open APIs of our Net-native SaaS, dozens of existing integrations to the most popular IT applications, and our commitment to customers to develop new integrations at no additional charge make for an efficient SaaS integration experience that is "as easy as drinking a glass of water."



Feb 10, 2011 4:35 PM Mike Telon Mike Telon  says: in response to Rhett Glauser

Great article. I'd make the claim that SaaS actually simplifies integration as many of the SaaS IT management software such sa SAManage are using standard based integrations and API's, which makes it easier to integrate with other SaaS or on-premise vendors.

Integrations has always been the vendor's responsibility, and using standards significantly simplifies the effort involved with building and maintaining them.

Lastly, SaaS is all about integrations with the eco-system and out-of-the-box integrated solution. This is a significant difference when compared to the on-premise world where each customer would have to own and maintain these integrations.


Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.

Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.