Could Microsoft Be Contemplating a Data Services Cloud Offering?


Recently, Microsoft announced plans to consolidate its data storage and Web services business units. While most saw this as a sign of the bad economic times, Joe McKendrick thinks maybe it's actually a smart business move.


Effectively, this move puts all of Microsoft's SOA-related initiatives, including Oslo, under the same branch as its data storage and cloud services. Here's why McKendrick thinks it's a money-making, rather than cost-cutting, move:

I don't think Microsoft is retrenching or cutting back SOA to save money - rather, I think the vendor sees more opportunity in the cloud, with the growing service-orientation of data management - with SOA as the enabler.


The connection between the cloud and SOA is pretty clear. SOA is services, cloud is services delivered via the Internet. And it's pretty obvious how cloud computing and data storage go together. But what's the connection between all three?


Data services.


I like the way McKendrick explains data services: It's what you get when data management moves to service-oriented delivery of information. Of course, that's not a technical explanation. Ash Parikh, who manages Informatica's SOA and real-time data integration strategy, described how a data service would look in a 2008 webinar on the topic, which McKendrick covered in this post.


Parikh defined a data service as "a modular and reusable well-defined business-relevant service that leverages established technology standards." He explained that data services create an abstraction layer through which you access and integrate analytical and operational data. In turn, this information is delivered through other abstraction layers, such as, for instance, an ESB.


Data services require a shift in the way you look at and approach data. I thought Parikh made an excellent observation when he commented that companies view data through an application-centric lens. Because of this, data integration solutions such as EAI (enterprise application integration) are also application-focused.


Actually, I recently interviewed Parikh about this very topic. I'd wanted to interview him since I saw McKendrick's post about data services last summer. Obviously, he works for Informatica, and I was a little bit worried he'd be less interested in generic options than pushing product. Of course, he did talk a bit about Informatica-specific situations and products, but, much to my relief, he was perfectly willing and able to speak more broadly about SOA's data problem.


In the first part of our interview, Parikh explained data is SOA's last mile. So far, data has largely been overlooked when people build service-oriented architecture:

If you look at any IT organization, you're going to look at application architects and application developers and a separate organization from those who handle the data. That is really what got this whole thing going. As I was trying to build everything I could for SOA, I realized that the only thing that is left here is to address the data integration aspect.


As with all things SOA, there's always someone who disagrees. When I wrote about data services last year, reader Rob Eamon, an enterprise architect and one of my favorite participants in Yahoo's SOA Group, posted this response:

IMO, services that only provide access to data, without functional operations that provide some sort of capability, is the wrong focus. The important thing about service orientation is doing something, not just reading or writing data. A service wrapper around data access is a data oriented approach, not an SO approach. Presumably, one reads data in order to do something with it. The reading and the doing should be part of the same service, IMO. Segregating services by data vs. transaction is fundamentally flawed IMO.

That's important for enterprise architects to figure out. Data services strikes me as a fascinating concept, but I will say it hasn't garnered much attention among SOA pundits. Parikh is one of the few people I've seen talk about it, although David Besemer wrote about data services in "An Implementor's Guide to SOA." (Thank you, Robert Eve, for pointing this resource out!)


Maybe Parikh's right and it's simply because the people deploying SOA aren't responsible for the data. Or maybe Eamon's right and it's a bad idea. I'll leave that for the technicians and pundits to sort out.


Of course, you don't need the cloud for data services, but it certainly makes the idea a lot more intriguing and promising. And, certainly, Microsoft could have no interest in data services -- but if it were, I bet we'd see a lot more companies and vendors talking about data services, wouldn't we?


At any rate, my guess is neither business nor Microsoft is overly worried about whether a data service is a flawed concept. I suspect most business will be more concerned about the security components, an issue Michael Poulin -- another of my favorites on the Yahoo SOA Group, where he's frequently at odds with Eamon -- raised in his analysis of the news:

While this solution may be quite popular among developers, it also carries a huge unmitigated risk of exposing 'corporate gold' to the unmanaged Internet (we hit this problem when we Web-enabled our applications 8 years ago..., didn't we?).