Created a Squidoo “Lens” on MDM
digg this | 
del.icio.us | 
Reddit | 
Stumble It!
A Squidoo “lens” is a view of a particular topic like Master Data Management. It’s an easy-to-build web page that can point to
• blogs
• favorite links
• RSS feeds
• Flickr photos
• Amazon books
• etc.
So when people are looking for information fast, the lens gets them started and sends them off in the right direction.
Here’s the new “lens” that I created on Squidoo for Master Data Management.
Please let us know what you think of Squidoo in general and our MDM lens in particular.
Different Styles of MDM Hub
digg this | del.icio.us | Reddit | Stumble It!
As part of a Master Data Management solution, one of the key decisions to be made is the choice of the MDM Hub architecture.
Gartner and others describe some two or three different Hub styles, but in this article, we’ll be paraphrasing those styles and explaining them based on our experience.
Registry Style: In a Registry Style hub, the various source systems publish their customer data and the subscribing hub stores only the source system IDs, the Foreign Keys (record IDs) and the key data values (needed for matching). The hub runs the cleansing & matching algorithms and assigns unique global identifiers to the matched records, but it does not send any data back to the source systems.
The Registry Style hub has an attribute locator service that serves as a reference for finding the Single Source of Truth value for a particular data element of a record. And if the hub vendor provides a metadata service, one can key in the business rules in the registry hub as well.
When a request to get a composite view of a customer is received by the hub, it has to build the view using the cross-reference data and the global customer ID. It does this by invoking each of the reference systems and fetching the authoritative values of each data element that makes up the data record. It then builds the 360O view in real-time.
A Registry Style hub is preferred when you have a large number of source systems spread across the globe. Each data source is the “system of record” for a particular record type. In such cases, it’s difficult to find an authoritative source of the data element outside of the source system and each geography may have its own political and data-peculiar turf.
The Registry Style architecture avoids the political issues about over-writing data in the source systems. However, performance can be an issue in this architecture, since calls are made to each source system and latency factors can quickly come into play.
Other benefits include low cost data integration in a fast time-frame. Very little data reconciliation is required between the source systems and the Hub.
The strength of the match engine is critical, since false positives and false negatives in matching can both be a serious problem. Because matching is a critical topic and could take quite a bit of space to discuss, we’ll cover it in more depth in a future blog article.
Transaction Style: In this architecture, the Hub stores, enhances and maintains all the relevant data attributes. It becomes the authoritative source of truth and it publishes this information back to the respective source systems.
The Hub publishes and writes back the various data elements to the source systems after the linking, cleansing, matching and enriching algorithms have done their work. The Hub needs to support merging as well as splitting of master records. This style of hub is appropriate when the organization has decided not to invest additional resources to maintain data in the source systems or when the data quality in the source systems is poor or information is not current.
The Transaction Style hub typically feeds data warehouses and data marts as well.
Technologically, this architecture requires more complex ETL rules, more intensive data reconciliation and data synchronization and thus, takes longer to implement. However, the Hub serves as the authoritative source of truth and data quality is monitored centrally in terms of accuracy, timeliness, standardization and integrity.
Security and visibility policies at the data attribute level need to be supported by the Transaction Style hub, as well.
Hybrid Style: This style resembles the Registry Style but stores more data elements / attributes than just those required for matching. Sometimes to enable a larger set of data elements, ETL tools may need to be integrated with the Hybrid Hub solution. The Hybrid Style addresses the performance issues mentioned above which are often faced by Registry Style hubs.
One can use some collaboration tools like workflows / Business Process Execution Language (BPEL) to accept the recommended changes by the Hub into the source systems and that has been a useful approach implemented at some companies.
Hybrid Style hubs can be implemented relatively quickly, because the data in the source systems still usually does not get changed, and integration requirements are less than the full Transaction Style.
Your comments, as always, are welcome.
Like this:
Critical Data Quality Questions
digg this | del.icio.us | Reddit | Stumble It!
In past issues of this blog, we’ve discussed aspects of the People, Process and Technology issues related to a Master Data Management program. In this article, we’ll touch on an equally important aspect – the underlying information.
Having decided on the domain of the data (customer, product, employee or something else), it’s imperative for the company to assign one or more project resources (preferably from the business, not IT) to gather an in depth understanding of that domain’s data. This can be done well before the software evaluation stage of the project cycle.
Some of the questions to be answered by those resources would be:
(1) As part of the MDM initiative, around which data elements will the organization will build its data quality program?
For example, a customer record can composed of: customer legal name, common or “street” name, brand name, detailed physical address (including county, landmark, driving directions, ZIP/Postal Code), e-mail address, phone number(s), parent company relationships, and additional attributes like customer type, memberships, etc. It’s important to scope these data elements up front, and communicate to the stakeholders that as part of MDM, data quality will be injected into these selected data elements on an organization-wide basis. A data profiling tool can help enormously in identifying the data elements that need better data quality.
Only the identified & scoped data elements need to be sent to the MDM Hub, e.g. only customer name, address lines, city, country, ZIP from various source systems may need to be sent to a hybrid-style hub.
(2) In how many source systems does that domain’s data reside?
For example, a customer address can reside in the ERP or CRM systems, or a self-service kiosk, a sales force automation system, a partner network or even an external data provider like D&B. One needs to identify these sources and the structure of the data in these systems. Later, a mapping exercise will be done to map the data elements in the various systems into the Hub.
(3) Who are the people that create that data? Who are the people that consume the data? Who are the people that are impacted by the data?
It’s very common that the customer legal name and address are created by the ERP system’s order management end user, with a later batch-feed to the CRM. The Customer Support Representative may then modify those data elements. Even later, the customer themselves may log into a self-service portal and modify the same data elements. The CRM may batch-feed the data to the Contracts or Installed Base system. It’s critical these data flows and the impact of the changes be understood, documented and stored in a metadata repository.
(4) Which system can be deemed as the authoritative source for each data element?
Typically, the system that creates the record is treated as the authoritative source, as opposed to another system which consumes it. However, certain elements of the record are added or modified later by downstream systems. It’s important to build business rules for each data element to identify which system can be deemed to own that data element.
A typical hub provides tools to cull from various source systems and build the single source of truth from multiple sources. But to implement that, business rules need to be written, communicated, signed off and stored in the metadata repository.
All the above are hard questions, and estimating the resources and effort for the above tasks can be a make-or-break issue for the MDM project. Therefore, if an organization can start answering these questions and documenting them in the metadata repository in the early stages of the MDM initiative, the team has a great head start on the design stage.
Your comments (as always) are welcome.
Part 2: Two Critical Foundations of MDM Success
digg this | del.icio.us | Reddit | Stumble It!
We’ll resume the discussion on simplifying an MDM initiative down to its two core elements.
On enrichment with external or “third party” content, things tend to go two different ways here. Either your industry and company’s requirements require a large number of external source systems (30 or more is not uncommon), or your situation will require no more than 1 or 2.
Dun & Bradstreet (D&B) is the largest and best known global provider of information on businesses, and Acxiom covers U.S. consumer information very well. But ask business people across different functional areas in your company; they can tell you what external providers they already use or definitely want to use.
Don’t postpone this step, however. It’s a rare enterprise MDM initiative that doesn’t need to work with ANY external information providers. And they can be invaluable in giving you non-obvious information about your customers, products, suppliers, etc. In other words, you “don’t know what you don’t know”. But a third party company that specializes in that area can help you get there.
So we can’t eliminate that one, but it probably shouldn’t drive your overall direction, since most MDM Hubs already connect to most popular information providers, or will build your favorite provider into their product as part of your implementation.
So we’re down to the core two components: the MDM Hub itself and data quality functionality. It’s possible the MDM Hub will have enough data quality functionality built-in to meet your requirements. Keep a few things in mind though – first, your data is worse than you realize.
Only if you’ve already done a pretty thorough survey of your important source systems (and then done a data profiling screen of each source system) can you feel reasonably comfortable of the data quality level you’re dealing with.
The good news is that the major data quality products are pretty mature & stable, and Gartner’s most recent “Magic Quadrant” for data quality vendors does a pretty good job identifying the stronger & weaker players.
The bad news is that you probably will need a separate data quality product, and the widespread software industry consolidation of the past few years has not spared this area, so we’ve seen products getting bought by mid-sized companies getting bought by giant companies.
So this is one area you should plan on looking at really carefully. Figure out what your data quality requirements are (separately from your overall MDM requirements), and research & evaluate which tools best fit your requirements.
Because “garbage in, garbage out” still applies with a vengeance, and the worst thing you can do is deliver an MDM initiative and Hub with bad data in it.
Senior executives who funded the project will turn up their nose at the data you’ve delivered, and your project leader will have a whole lot of ‘splaining to do.
So that means that out of our initial five areas, we’ve really narrowed it down to the two critical ones that are going to drive your success: data quality and the MDM Hub itself.
Part 1 and Part 2 together are getting pretty long, so we’ll have to cover evaluating & selecting data quality tools and MDM Hubs in a future article.
Please let us know what you think in a comment – we’re always interested in what our readers are doing in the real world, and hearing where we can improve.
Part 1: Two Critical Foundations of MDM Success
digg this | del.icio.us | Reddit | Stumble It!
As we’ve written before, we think there are five essential elements in successful Master Data Management initiatives:
(1) some type of MDM Hub
(2) some form of middleware & business process management
(3) enterprise data quality capabilities
(4) enrichment with external content
(5) data governance
But let’s try to simplify this a bit, because it can be overwhelming to think about evaluating, selecting & implementing so many different components for your enterprise MDM strategy.
Our first suggestion would be to realize that, although technology can enable data governance, there’s no “silver bullet” technology that provides robust data governance out-of-the-box. You’ll have to do the hard work of evangelizing the need for it, getting senior management bought in, and then getting your data governance program funded, built out, and staffed.
But don’t ignore this – successful MDM programs are probably better described as successful data governance programs that implemented MDM as part of their overall strategy. In other words, data governance is the end game, and MDM technology is the vehicle that facilitates that end game.
Try having trusted enterprise-wide critical master data without having a group to manage it and disciplined business processes to deliver it – it can’t be done, any more than you can have a reputable public company with reliable, trustworthy financial statements that doesn’t have a good Finance team behind the scenes, turning them out quarter after quarter.
So we can’t ignore data governance, but we realize it isn’t going to be necessary to evaluate, select & implement a separate technology component to provide it. Create a data governance organization and processes in parallel or in advance, then make sure the technology that you do select & implement is a good fit with your data governance approach.
So that leaves us with four areas to focus on: the MDM Hub, middleware / business process management, data quality and enrichment.
It’s possible your organization will have already standardized on a particular EAI tool or middleware solution. Hopefully, it’s adequate for the new demands you’re going to place on it, and will provide a robust way to move data efficiently from source systems to the Hub and back, with a high degree of automation, so you won’t be requesting a new team of 50 data stewards to manage the Hub.
So it’s possible that if your company is a Fortune 500 or Global 2000 company, you’re not going to have to worry about selecting a middleware / business process management component. Just make sure the MDM vendors you evaluate can work with your already-selected standard.
Tomorrow, we’ll finish this discussion of simplifying a successful MDM initiative down to its two core foundation elements.
Current State of the MDM Market
digg this | del.icio.us | Reddit | Stumble It!
While I don’t have the latest market sizing figures in front of me (and I’m not sure how accurate they are anyway), I do believe that the Master Data Management market is growing fast.
But I don’t think that we’ve quite left the “early adopter” phase of the market yet. There’s still a big competitive advantage to be gained from a robust implementation of a well thought out MDM strategy. That right there tells me we’re not into the mainstream phase of the market yet.
And the vendors’ products, while maturing nicely, still have some distance to go in terms of features and interoperability with different middleware, business process automation, data quality and external content providers. All products support some of these capabilities, but no product supports all of the various permutations of capability and vendor.
The resource shortages we’re seeing in the marketplace are another indicator. If the market was mature, stable and mainstream, then there would be little or no resource shortages.
This is good news, though. When a technology starts to become a “cost of doing business” and become a commodity, when vendors’ products become so stable that better marketing becomes more important than making a better product, and when all of the human resources are fully trained up on the various products, the market reaches an equilibrium point, and things become less interesting.
That’s not to say that a mature, stable technology like ERP or e-commerce is no longer interesting, or doesn’t provide any advantage to companies implementing it, but I personally really enjoy this fast growth stage, as we move from the “early adopter” phase to the mainstream phase.
So we’re not seeing the beginning of the end, but we may be seeing the end of the beginning.
We expect to see the MDM hub platforms maturing further, with more consolidation among software vendors. There will be continued resource shortages, but we’ll see large and small firms continuing to re-tool their resources and re-brand their methodologies. And companies will continue to invest in the Single Source of Truth, and get corresponding increases in revenue, improved efficiencies and better compliance.
And MDM will continuing to be a very interesting space, for at least the next several years.
Master Data Management in the New Year
digg this | del.icio.us | Reddit | Stumble It!
There’s a lot going on in the Hub Solution Designs and MDM world since we ticked over to a new year on the calendar:
- We’ve got an article coming out in the March issue of DM Review
- We’ve helped finalize the agenda for the MDM track at the upcoming Oracle Applications User Group Collaborate 2008 conference
- We’re working with a great client in the upper Mid-West
- We’re in the midst of re-designing our web site on a new platform
- We’re pursuing about 14 potential new projects at various stages of the sales process
- We’re involved in a large proposal effort with another consulting firm
So it’s been pretty busy over the past couple of weeks. One way to tell when we’re in “heads down” mode for a time is when the new blog entries start becoming further apart. We’ll try to do better in the new year of writing more short entries, rather than a few, widely spaced long articles.
Hub Solution Designs continues to be very optimistic and positive on the Master Data Management space. Yes, there is some vendor hype going on (when isn’t there?). But underlying that are a large number of real client problems for which MDM is a good way to solve the business issues and drive ROI. Sometimes alone, sometimes in concert with something else like a BI solution or a Risk Management solution.
So even though we are still, in some ways, in the “early adopter” phase of the overall MDM market, it’s starting to heat up very nicely. We continue to get contacted via a variety of different channels by people looking for help with their strategic MDM initiatives. The phone’s not ringing off the wall, but the number of projects we’re getting contacted about is very healthy and it’s consistent with where we were hoping we’d be at this stage of the development of the company.
So we hope your New Year is off to a great start. Please let us know via comments to our posts how your real world MDM initiatives are doing or what your perspectives are on this space.
