Whipping IT data into shape

To make the scope manageable, IT organizations generally define the rules and context for one subject area and then extend the system out to other subject areas over a period of time. That’s what Carlson Hotels is doing, starting with the customer-oriented hub IBM acquired from DWL. According to Carlson’s Kolodziejczyk, however, the hospitality company is not yet sure whether it will extend that hub to include product data or use the product hub IBM acquired from Trigo.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell Return to special report DOWNLOAD PDF Click here to download InfoWorld's special report Managing data

Deciding whether to start with a subject-specific system -- such as product information within SCM -- or a generalized system depends on how targeted the integration efforts are to specific application suites. It may make more sense to start with a subject-specific hub if your focus is on interactions with an ERP or SCM system, whereas a generic hub makes more sense if your focus is on an SOA in which services interact with a wide variety of applications.

Building a data architecture
MDM tools can help, but they do little good if the enterprise doesn’t understand its data. “I see a fair amount of hype around the concept of master data management,” says Fred Cummins, a fellow at EDS. Because centralized data stores deal typically with after-the-fact results, not with states and transactions, the more an MDM system looks like a traditional data warehouse or master database, the less likely it meets the needs of a transactional system, whether in a traditional or SOA environment, Cummins says. “It’s unrealistic to expect that there is one master database that everything reads or feeds. Some of the data is transactional,” concurs Paul Hernacki, CTO of consultancy Definition 6.

For an SOA, MDM tools that simply repackage EAI tools are not very helpful, Cummins says. That’s because an SOA should be driven by business processes, whereas EAI typically focuses on connecting applications together without worrying about the underlying data context for each. Even for traditional integration efforts, “you can’t just put in middleware and off you go,” adds Brian Babineau, an information integration analyst at Enterprise Strategy Group.

“Primarily, it’s a design issue,” echoes ZapThink’s Schmelzer. “We have great tools for databases, messaging, transformation, etc.,” to implement the design, he adds. Designing the architecture and the specific services correctly requires that developers understand all the data used and generated by services and the applications they interact with -- a labor-intensive process.

That’s why IT needs a commonly accessible set of data services or at least data mappings. “At some point this will have to be formalized as a repository,” Common Sense’s DePalma says. Critical for an SOA, this approach is also very useful in traditional environments, he adds.

With those mappings created, IT can then focus on building the connectors or services that implement them. IT must understand which mappings should be available to multiple services and applications -- and thus implemented as separate processes -- and which are endemic to specific business logic and should be encapsulated with that business logic, consultant Hurwitz says.