Whipping IT data into shape

“Do you divvy it up, or do you provide a central service?” asked Starwood Hotels’ Park when the company began its SOA effort. That question led it down a path many enterprises must travel en route to SOA: a services approach to data based on knowing what data means no matter where it comes from. “SOA raises the fact that data is heterogeneous,” Schmelzer says.

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld Return to special report DOWNLOAD PDF Click here to download InfoWorld's special report Managing data

As services exchange data, the potential for mismatches and unmapped transformations grows considerably. “SOA propels this problem into the stratosphere,” Common Sense’s DePalma says. “Put together your first three- or four-way data service,” and you’ll quickly discover the pain of data management. Without an initial data-architecture effort, an SOA won’t scale across the enterprise, says Judith Hurwitz, president of Hurwitz Group.

The solution, according to analysts and consultants, is to develop a data services layer that catalogs the correct data to use and exposes its context to other services. This approach decouples the data logic from the business logic and treats data access and manipulation as a separate set of services invoked by the business processes. Without such a scheme, enterprises will find themselves with loosely coupled business processes that rely on tight data dependencies, eliminating SOA’s core benefit of loose coupling.

This effort is a change from past data integration approaches. “We used to solve data integration by imposing controls at critical choke points,” ZapThink’s Schmelzer recalls. “SOA eliminates these choke points, so I now have a data integration problem everywhere. That means every data access point has to be able to transform and manage data,” he says.

“Data integration and process integration are inexorably linked,” says Henry Morris, group vice president of integration systems at IDC. “You need to think of services to manage data. Think about the processes that affect the master data wherever it lives,” he advises.

SOA also raises concurrency issues, notes Nikhil Shah, lead architect at the Kanbay International consultancy. For example, how data changes during the process may affect the results, especially in a composite application, as old data is propagated through the process, or when multiple services access the data at different times. Shah recommends that IT implement monitoring services -- or at least services that notify other services when changes occur -- so that they can determine whether to restart the process or adjust their computations.

Moreover, the more granular the data services, the greater the impact orchestration overhead has on processes, which could slow response time and create synchronization issues, Shah says. He advises IT to model data management requirements before a service can consume that data. Generally speaking, the more transactional the service, the more the specific data manipulation should be hard-coded into the business logic, he says.

Another SOA data issue is the “snowplow effect,” which occurs when services pass on the context about their data manipulations to subsequent services in a composite application, says Ken Rugg, vice president of data management at Progress Software, which provides caching technology for data management in SOA environments.