Building a consistent architecture for data is what MDM is about. When SOA is involved, that means building a consistent approach to encapsulating and delivering data as services.
In MDM SOA projects, defining the objective becomes more important than ever. "If you have started an investment like this and don't know what success looks like, you have already failed," says Rob Karel, an analyst at Forrester Research Inc.
"With this level of complexity and cost, your business case should specify whether the project is to improve the bottom line or help manage risk mitigation up front."
Before you purchase your first piece of technology, "you should already know what part of the business you should be monitoring," Karel adds.
Stepwise approaches can buy some time, but an organization must eventually grapple with the full problem.
"The best approach is to look at the full MDM SOA undertaking as a long-term project," says Aaron Zornes, chief research officer at The MDM Institute. "People can do lightweight definitions of customers along the way," but they should understand that some objectives are part of a longer march.
"Similar to an SAP or Seibel implementation, it is a big thing," he says.
Brad Wright, senior product marketing manager at data integration specialist DataDirect, says, "MDM itself courts risk. Master data projects can have pretty high failure rates. It is hard."
But even when you succeed, you should understand you may create another data source, he said.
"In the context of operational scenarios, MDM helps create a golden record. But it can compound problems if it just created another island of data," Wright warns.
MDM stores for SOA can be distinguished from stores for data warehousing and CRM by speed and update frequency.
"The clock speed is different," Zornes says. "You can take a data warehouse and make it the system of record, but it wouldn't be optimized for fast access.
"Or you could take CRM and say 'that is the system of record.' But you choke yourself because there are so many hot spots. Or you can take data models, [deploy] a special database and optimize for fast access. There are multiple ways to data nirvana."
With the SOA and MDM project, "too much too soon" can be a hindrance, explains Wayne Eckerson, research director at The Data Warehouse Institute (TDWI) in Renton, Wash.
"Most companies would not start with real time. At first, the SOA MDM system is refreshed much like the data warehouse. That is, overnight."
Proper project sizing is key with both MDM and SOA. "With MDM, you can try and get the uber-MDM solution and never really get it," says Ken Johnson, product line manager for Red Hat's MetaMatrix Enterprise Data Services Platform.
"You can get too far into the creation of the perfect master index and spend a lot of time there. A more iterative method is better. Using a federated tool, you can mock up views of data," he says.
"With the mockup views, you can quickly get to something you can get into the proposed form and validate it with the applications that will be consuming it. You can iterate and validate."
Robert Eve, executive vice president at Composite Software Inc. in San Mateo, Calif., says, "MDM projects as well as data warehousing projects tend to be longer-range, multistage initiatives. Tools can add value as a faster, cheaper incremental approach on that journey. I think the value of incremental approach to larger SOA and MDM projects is quite high."
Eckerson adds, "Enterprise SOA and real-time enterprise applications do not suddenly appear. They are big, incorporating many moving parts. They tend to roll out in increments. This affects planning for MDM."
SOA and MDM: GIGO 2.0?A five part special report
Part 1: SOA with MDM prevents messaging confusion
Part 2: SOA and MDM: New techniques address old problems
Part 3: Data architecture project practices with SOA and MDM
Part 4: MDM brings SOA and BPM closer together
Part 5: With MDM and BPEL, business users become data stewards