How One Company Handled SaaS Integration

Loraine Lawson

TechTarget published a detailed look at how one company is handling data integration as its cloud portfolio grows.

 

The piece ran on TechTarget's Oracle subsite, and the company involved ultimately decided to use a slew of Oracle solutions; as a result, it starts to sound like a salespitch for Oracle. But keep reading, because eventually that ends and you wind up with a look at what happens when you start moving more applications and functions to the cloud.

 

The company under discussion - Loomis - is a cash handling and ATM servicing company based in Houston, Texas. The CIO, Wayne Sadin, shares a great deal about the company's business drivers for integrating Salesforce.com, Oracle CRM on Demand and, finally, on-premise data with these two cloud options.

 

Needless to say, by using more Oracle products, Sadin simplified the problem for his company-but that's not always practical or optimal for companies with a more diverse application portfolio.

 

As Dana Gardner, a principal analyst with Interarbor Solutions, points out, some companies may opt for point-to-point integration, which-as we've seen with internal IT-can lead to a heck of a mess later on:


 

"I think in a lot of cases what you've got are tactical versus strategic issues. On a tactical basis, companies might just look at one particular application like CRM and decide that they don't need to do an architectural reevaluation because they're simply going to bring in one little data stream and use that across several different processes that they're focused on. But if you start doing that for multiple applications, you're going to run into a complexity roadblock."

 

In other words, those that do not know integration's spaghetti code history may be doomed to repeat it in the cloud. To avoid that trap, you're going to need to think strategically, including examining how SOA, formal data governance and <span>data quality</span> can eliminate integration problems down the road.

 

I've written quite a bit about the problems of cloud and problems of SaaS integration. Just this week, in fact, I shared some of the possible problems with marrying internal SOA initiatives with the cloud.

 

But this piece offers a bit of balance to that discussion. Despite the warnings, the main takeaway of this piece is that the data integration piece can be solved, particularly if you're willing to plan well, make needed changes-and even experiment a bit, according to Sadin.

 

"If you have a running e-business suite and you have a running on-demand system, you can analyze this to death, or you can take the approach of putting the product right into test. You'll probably find that you need to modify less than you thought. ... Don't be afraid to integrate on premise and on demand."


Add Comment      Leave a comment on this blog post
Sep 14, 2009 11:34 AM Wayne Sadin Wayne Sadin  says:

Rather than think of it as "a salespitch for Oracle" think of it as a "salespitch for commonality or a salespitch for integration."

In this case we had a lot of Oracle applications already and the Oracle CRM application was less expensive than the one we were using. AND we had to set up a large call center quickly without having a VoIP or call center infrastructure in place. So in this case the Oracle apps made a lot of sense.

If we had the Microsoft ERP products instead I could have made the same case for integrating various Microsoft applications (on-premise or on-demand, depending on costs/needs).

And since we run two business lines on bespoke .Net applications and have several business-critical applications running on Windows Mobile, we've also done a lot to integrate Oracle and Microsoft infrastructures usng SOA, Biztalk and Fusion components.

The points I was trying to make were:

1. A mix of on-premise and on-demand apps may be best in some situations;

2. Data and application integration is a very good thing;

3. It isn't as easy as the vendor salespeople say it is,  but modern tools make it fairly painless.

Here's something else we learned: as application integration increases you have to think of change control in new ways.

Two examples:

-- We now have our Cisco VoIP platform integrated with our AD and Exchange platforms, and we recently had to postpone a VoIP upgrade since it required "just a little" AD schema change the vendor expected we'd make on the fly.

-- This Sunday morning our call center had a problem. Seems our on-demand telephony vendor made a change in the wee hours and our PC Java stacks were no longer supported. The fix was simple once we tracked it down, but we had an exciting few hours this weekend.

So don't be afraid to move, but expect to learn new things!

-Wayne

Reply

Post a comment

 

 

 

 


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

 

null
null

 

Subscribe to our Newsletters

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