What does data integration look like when you’re inside a
Software as a Service (SaaS) world? Some things look very much the same, and some
things look quite a bit different.
What looks the same are the issues. Simply put, how do I get data into the
application, how do I get information out of the application, and how do I make
sure that it’s the right information? The last item can often be the trickiest, dealing with semantics and
data quality issues.
The ways you get data in and out, and how you deal with data
quality, look quite a bit different. Most applications offered as a service have a set of APIs available for
integration, and most are available as some kind of Web Service. Though Web
Services have been around for a few years now, the average IT department does
not have the same level of experience with them. So we have a whole new paradigm for dealing
with applications that looks a lot different than using an ETL tool, building a
data warehouse, or using the TIB.
The other thing to think about is that SaaS applications do
not live in a vacuum. The main driver is
to connect existing applications (Software as Itself?) with SaaS
applications. So now we have to combine
old school integration (ETL, EDW, TIB, SQL) with the newer SOA-based
integration. Not as easy as it may
sound. (In fact, one customer mentioned
that the group dynamics among Salesforce.com admins, SOA gurus, and the EDW
crew is a challenge in itself.).
All of this got me to thinking that this may be the perfect
time for ‘Data Services.’ The term has
been gaining momentum since Gartner started talking about it a while back. It’s what we do here at Ipedo. The basic idea is to take integration
functions and make them available as a service via a platform. So the goal is not to move bulk data in
batch, but to expose information and make it accessible on demand. Included in the data service are security, performance
optimization, semantic mediation, and potentially even data quality.
To make things more concrete, here are a few examples. You want to combine information from Oracle,
DB2 and an order management application available as a Web Services, apply some
logic, and update a customer record in Salesforce.com. Right there you have two kinds of SQL,
SOAP/WSDL, and the Salesforce.com API (SOQL)
to deal with. Or go the opposite
direction. Your company is moving from
Siebel to Salesforce.com, and you still need to create those weekly reports in Crystal. So you need to deal with the Siebel API or
data mart, the Salesforce.com API and somehow get it to output in SQL (and it
would be nice if you didn’t have to start from scratch).
There are more examples, to be sure. But one thing becomes clear to me. In the future, there may be no way stations
for data. It’s needed inside the
firewall, outside the firewall, in the applications you own and the ones you
rent. So it would seem data services
offer the perfect solution.
Software as a Service requires ‘Integration as a Service,’
aka Data Services. But unlike SaaS, Data
Services also need to deal with the past twenty years of application data
inside your company. So while I’ll never
bet against there someday being a new startup called Integration.com, for the
foreseeable future a Data Services platform inside your firewall that can deal
easily with both internal applications and rented SaaS applications seems like
just the ticket.
I’ll be digging into this idea in more depth. Watch this space.