SOA requires that you get your data act together

The bottom line is that application developers need data access in an automated and simplified manner. Give it to them. Your SOA process architects will thank you later on.
Written by Dana Gardner, Contributor on
I've said it before, and I'll say it again: Architecture is destiny. As many enterprises (and vendors) are destined for SOA, charting the course -- and identifying the tactical and strategic accelerants -- is the name of the current game.

In a recent well-received blog I provided some business logic for the tag-team of SOA and AJAX. But after a briefing this week with ObjectRiver I'm reminded of another essential methodological ingredient to SOA preparedness. And that is getting your data act together, putting a master data model in place, and managing divergent while parallel paths for your data architecturally.

So embrace ETL and consolidate all that data pooling about your business ecology. Build that data model (no easy trick). And define the future of your data for real-time as well as reports-like uses, such as call-centers. For example, one path for your data strategy is for real-time transactional data integrity (say, for a trading system), and the other path meets the SOA needs of meta data that plays a mounting role in customer-facing and supply chain applications and processes. So there's the data, and the increasingly important data model.

Because of the nature of SOA and event-driven applications, accessing as much data centrally is imperative for applications to attain their full value, hence ETL and data consolidation, along with standards-driven access-distribution (via SDO, ADO, and JDO, among others). The bottom line is that application developers need broad data access in an automated and simplified manner. Give it to them. Your SOA process architects will thank you later on.

That's because the stakes are much higher for the comprehensive and coordinated attainment of data as SOA becomes common. You can't really get to SOA without the data act together. Having a bunch of services and orchestrating them with some independent logic is fine and dandy. But if the comprehensive data on what the services and processes themselves reflect is not available or timely, well ... architecture is a destiny I'd rather not have as a CIO in that instance.

IBM has been on a powerful tear (building, buying, standardizing, and partnering) to make this well-managed data act attainable (industry by industry) for enterprises. Oracle has been conducting a similar drive to specialized data management in its own way: via the higher-level business applications themselves. I was also impressed that IBM is upping the volume on the importance of information (a superset of data).

This shows a huge commitment by IBM to the management of data and information as a tactical and strategic competitive differentiator. The move to optimize data and information (for true knowledge commerce) will make IBM competitive as an IT products and services provider, and it will make IBM's customers more competitive within their vertical industries.

So don't put the SOA cart in front of the meta data horse. If anything err on the side of the data investment. That way your SOA will readily reap the rewards of your hard work in data management and optimization for maximum process efficiency and knowledge commerce.
Editorial standards