Whipping IT data into shape

No one likes data integration. It’s painstaking, hard to automate, and hard to measure in terms of business ROI. Yet it’s required for making systems work together, whether as a result of an acquisition, as part of a migration to new tools, or in an effort to consolidate existing assets.

“The first question is always, ‘What database are we going to use as our customer source?’ ” notes John Kolodziejczyk, IT director at Carlson Hotels Worldwide. Rather than keep asking -- and answering -- that question, the hospitality company devised a common data architecture, and a platform for managing it, for all its applications as part of the migration to a service-oriented architecture. Similarly, ball-bearing manufacturer GGB decided it needed a central product information hub to ensure consistent data mapping among its Oracle e-Business Suite and three aging ERP systems, rather than try to maintain a raft of point-to-point connectors, says Matthias Kenngott, IT director at GGB.

Much enterprise data is either locked away in data stores or encapsulated within applications. Traditionally, applications “know” what the data means and what the results of their manipulations mean, in essence creating a consistent data model, at least locally. As modern enterprises mix and match functions across a variety of applications, however, the data models get mixed together as well -- often without the IT developer being aware of it.

Click for larger view.

“The more you distribute the data, the more likely there will be problems,” says Song Park, director of pricing and availability technology at Starwood Hotels. The result could be what Don DePalma, president of the Common Sense Advisory consultancy, calls “frankendata,” calling into question the accuracy of the results generated by the services and applications.

“There’s always a context to data. Even when a field is blank, different applications impose different assumptions about what that means,” notes Ron Schmelzer, senior analyst at SOA research company ZapThink.

Ultimately, frankendata can make a set of integrated applications or a vast web of services both unreliable and hard to repair. Many relationships must be traversed to understand not only the original data components but how they were transformed along the way. The antidote to frankendata is to provision data needed for multiple applications as a service -- incorporating contextual metadata where needed and reconciling discrepancies among distributed data sources.

The SOA imperative
A twofold advantage of SOA is that creating services that perform oft-used functions reduces redundant development -- and increases agility by making application functionality available across a variety of systems using standardized interfaces and wrappers. The loosely coupled, abstracted nature of SOA has profound implications for the data that the services use, manipulate, and create.

“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.