Could Microsoft Be Contemplating a Data Services Cloud Offering?

Loraine Lawson

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?).

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
Apr 8, 2009 1:57 PM Steve Rdzak Steve Rdzak  says:

Data Services, IMO, are a good idea. I will have to respectfully disagree with Rob Eamon. I think the point to be made is that your SOA needs to have a taxonomy of services that support different contexts of consumption.

One context of consumption is the service consumers who just want to have a question answered which is primarily concerned with retrieving data for review. Another context is a consumer who needs a simple atomic task completed by a transactional service. Another potential context is a consumer who needs a complex, multi-task, long running capability completed by a process service.

Where I do agree with Rob is that if you ONLY provide the data service context in your SOA then you are too narrowly focused! If that is what he was saying then we are in agreement. But what I have seen in practice where I work is that the number of consumption use cases for data services far outweigh the use cases for the other service types.

Businesses are producing and storing more data at astounding rates than they ever have and the trend will just continue, and consumers of this data want quicker, more reliable access to this data without waiting weeks/months for IT to produce a new data mart or report. So the elasticity of the cloud for storage with a quick way to service enable the data using web standards for consumption looks like a wise move to me.

Apr 15, 2009 6:08 PM Robert Eve Robert Eve  says:

Wow!  It is great that data services are finally getting their due, even if it takes Microsoft's brand and Cloud Computing's buzz to bring them to light.

But rather than think about the supply side alone, IMO it makes sense to also look at data services demand.

Retrieving data from disparate systems in order to do BI functions alone is an over $3B software license and $20B consulting services business today.  Enterprises are using data services to provide an ever growing portion of this data, gaining SOA-style agility, and cutting these costs.

Further, even in a transactions-centric (versus data query centric) SOA adoption strategy, common data services such as GET_CUSTOMER, GET_PRICE, GET_TAXRATE, and more are proving highly valuable when automating an order-to-cash business process for example.  This is just the tip of the data services within business process automation iceberg.

Finally, there are many use cases where analyzing data is the business process -- for example interest rate risk analysis in banks (don't we all wish they had better data services here 3 years ago) or single view of "person of interest" in intelligence agenices.  Data services that simplify sharing of data are critical enablers for this class of processes.

Not only is there significant and growing demand for data services, obviously with "old school" data integration companies such as Informatica and "diverse" players such as Microsoft joining the fray, data services enabling technology supply is increasing to fulfill it.

It will be interesting to see how well the new entrant's first generation efforts meet requirements relative to suppliers such as Progress and Composite Software who now have second and third generation offerings.  Either way, the users win!

Apr 16, 2009 7:11 PM Rob Eamon Rob Eamon  says:

Rdzak said: "...if you ONLY provide the data service context in your SOA then you are too narrowly focused! If that is what he was saying then we are in agreement. But what I have seen in practice where I work is that the number of consumption use cases for data services far outweigh the use cases for the other service types."

That is indeed what I was getting at. CRUD activities are too narrow. I think that they are narrow enough to warrant a DQ for being classified as a service in the SO sense.

There is undoubtedly a ton of demand for "data services"--that's what people are used to asking for over the last several decades. "I just need that data over here."

SO is supposed to change the focus from data to doing something germaine to the business. If you find yourself wanting to get data, ask the question "what do you want to do with it?" The answer to that will give you the service (or the operation within a service) that needs to be defined.


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.