For example, while Merck’s Solfaro works on the product information effort, another group will work to standardize customer information. Rather than work independently, creating data-architecture fiefdoms, the two groups are coordinating, using common principles in their efforts. That collaboration will make it easier to unify the data architectures and make data exchange much easier, Solfaro says. He expects the project to take a year.
“We will go from the local level to the enterprise level,” Solfaro says, using coordination of individual projects to lay the groundwork. Nationwide’s Gopal also coordinates with other departments with the goal of building toward a standard data architecture. “If you don’t tackle this, you can only work on patch-up projects,” he says.
Both Nationwide and Merck have focused on “one-way” data rationalization efforts, in which data moves along a specified path to a system of record. In an SOA environment, data paths won’t be so linear because services from different systems could be combined to create new functionalities that access data in a nonlinear way. But consultant DePalma encourages IT not to get hung up over this possibility. In many cases, even in the SOA context, there will be clear stages to data’s use and definition.
Customer information related to shipping predictably can be needed for shipping and call-center purposes, for example, so worrying about whether a customer-acquisition system knows what to do with that data isn’t worthwhile. The key is to ensure that the system knows to ignore aspects of the data irrelevant to it — or never sees it in the first place.
Rather than worry about designing a data architecture and data model that accounts for every possible use, DePalma says IT should focus on ensuring that the data model doesn’t become static. Definitions and needs will change, so IT should continually assess its data model and adjust its master data management systems accordingly. “You need structure and an application development model for future development so that new things plug in to your system,” he says.
“Everybody needs a vision, and data architecture is that vision. As soon as you stop thinking about a data architecture, you’re in trouble,” DePalma advises. Even if you never fulfill your vision, having it will keep everyone moving toward the same goal, helping reduce incompatible designs, keeping complexity manageable, and opening up new ROI opportunities as unexpected synergies arise. “With a common vision, you’re not just doing individual projects in a vacuum,” he says.
That’s Merck’s philosophy as well: “From a grander viewpoint, our enterprise architects have already tried to unify the architecture and the strategy,” Solfaro says. “Even if there are tactical differences on projects, we’ll still be moving in the same strategic direction.”
Read more about data management in InfoWorld's Data Management Channel.