In this series, we’ve discussed developing the MDM blueprint by developing the Common Information (Part 2), Canonical (Part 3) , and Operating (Part 4) models in our work. Part 5 introduced the Reference Architecture model into the mix to apply the technical infrastructure or patterns we plan on using.

The blueprint has now moved from being computation and platform independent to one that expresses intent through the use of more concrete platform-specific models. The solution specification is now documented (independent of the functional Business Requirements) to provide shared insight into the overall design.

Now, it’s time to bring the modeling products together and incorporate them into a MDM solution specification we can use in many ways to communicate the intent of the project.

First, the MDM blueprint specification becomes the vehicle for communicating the system’s design to interested stakeholders at each stage of its evolution. The blueprint can be used by:

• Downstream designers and implementers to provide overall policy and design guidance. This establishes inviolable constraints (and a certain amount of freedom) on downstream development activities.
• Testers and integrators to dictate the correct black-box behavior of the pieces that must fit together.
• Technical managers as the basis for forming development teams corresponding to the work assignments identified.
• Project managers as the basis for a work breakdown structure, planning, allocation of project resources, and tracking of progress by the various teams.
• Designers of other systems with which this one must interoperate to define the set of operations provided and required, and the protocols for their operation, that allows the inter-operation to take place.

Second, the MDM blueprint specification provides a basis for performing up-front analysis to validate (or uncover deficiencies in) design decisions and refine or alter those decisions where necessary. The blueprint could be used by:

• Architects and requirements engineers who represent the customer. The MDM blueprint specification becomes the forum for negotiating and making trade-offs among competing requirements.
• Architects and component designers as a vehicle for arbitrating resource contention and establishing performance and other kinds of run-time resource consumption budgets.
• Development using vendor-provided products from the commercial marketplace to establish the possibilities for commercial off-the-shelf (COTS) component integration by setting system and component boundaries and establishing requirements for the required behavior and quality properties of those components.
• Architects to evaluate the ability of the design to meet the system’s quality objectives. The MDM blueprint specification serves as the input for architectural evaluation methods such as the Software Architecture Analysis Method [and the Architecture Tradeoff Analysis Method (ATAM-SM) and Software Performance Engineering (SPE) as well as less ambitious (and less effective) activities such as unfocused design walkthroughs.
• Performance engineers as the formal model that drives analytical tools such as rate schedulers, simulations, and simulation generators.
• Development product line managers to determine whether a potential new member of a product family is in or out of scope, and if out, by how much.

Third, the MDM blueprint becomes the first artifact used to achieve system understanding for:

• Technical managers, as the basis for conformance checking, for assurance that implementations have in fact been faithful to the architectural prescriptions.
• Maintainers, as a starting point for maintenance activities, revealing the areas a prospective change will affect.
• New project members, as the first artifact for familiarization with a system’s design.
• New architects, as the artifacts that (if properly documented) preserve and capture the previous incumbent’s knowledge and rationale.
• Re-engineers, as the first artifact recovered from a program understanding activity or (in the event that the architecture is known or has already been recovered) the artifact that drives program understanding activities at the appropriate level of component granularity.

Blueprint for MDM - Where this fits within a larger program

Developing and refining the MDM blueprint is typically associated with larger programs or strategic initiatives. In this last part of the series, I'll discuss where all this typically fits within a larger program and how to organize and plan this work within context.

The following diagram (click to enlarge and use your browser to magnify the png file) puts our modeling efforts within the context of a larger program taken from a mix of actual engagements with large, global customers. The key MDM blueprint components are highlighted with numbers representing:

1. Common Information Model
2. The Canonical Model
3. The Operating Model
4. The Reference Architecture

Click to enlarge

I have also assumed a business case exists (you have this right?) and the functional requirements are known. Taken together with the MDM blueprint, we now have a powerful arsenal of robust information products we can use to prepare a high quality solution specification that is relevant and can be used to meet a wide variety of needs.

Typically, use of the MDM blueprint may include:

• Identifying all necessary components and services
• Reviewing existing progress to validate (or uncover deficiencies in) design decisions; refine or alter those decisions where necessary
• Preparation of detailed planning products (Product, Organization, and Work Breakdown structures)
• Program planning and coordination of resources
• Facilitating prioritization of key requirements – technical and business
• Development of Request for Quotation, Request for Information products (make vs. buy)
• Preparing funding estimates (Capital and Operating Expense) and program budget preparation
• Understanding a vendor’s contribution to the solution and pricing accordingly (for example, repurpose as needed in contract and licensing activities and decouple supplier proprietary lock-in from the solution where appropriate)

We are also helping to ensure the business needs drive the solution by mitigating the impact of the dreaded Vendor Driven Architecture (VDA) in the MDM solution specification.

Summary

I hope you have enjoyed this brief journey through “Modeling the MDM Blueprint” and have gained something from my experience. I’m always interested in learning from others, so please let me know what you’ve encountered yourself, and maybe we can help others avoid the pitfalls and pain in this difficult demanding work.

The difference between success and failure on an MDM journey is taking the time to model the blueprint and share this early and often with the business. This is after all a business project, not an elegant technical exercise. In an early reference, I mentioned Ward Cunningham’s Technical Debt concept. Recall this metaphor means doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort we have to do in future development because of the quick and dirty design choices we have made. The technical debt and resulting interest due in MDM initiative with this kind of far-reaching impact across the enterprise is, well, unthinkable.

Take the time to develop your MDM blueprint and use this product to ensure success by clearly communicating business and technical intent with your stakeholders.

Go back to Part 5.

Editor’s Note: Today’s post was written by Jeff Schaffzin. Jeff is an independent consultant with over 15 years of experience in high tech. He’s worked with a number of leading software vendors in roles such as product marketing, professional services and information technology. Specializing in data management, Jeff has spent the last three years focusing on Customer Data Integration and Master Data Management and has worked with a number of high profile companies in the United States and abroad. 

Since I’m a consultant, I have the chance to meet with a wide variety of people at different companies in various industries. About a month ago, I talked with someone I worked with a number of years ago who wanted to know more about Master Data Management. Since he’s worked more as a “functional” person for most of his career (as opposed to a “technical” one), he asked me exactly what an MDM solution would provide his company.

MDM, I told him, is not simply a software application that you ‘buy’ from a software vendor like you might with a CRM or ERP solution. You can’t just decide one day that you want to buy a “customer hub” or a “product information manager” because you heard from your IT Director (or even CIO) that it will save your company millions and cure world hunger. It’s vital to understand why your company might need an MDM solution.

You need to look at your company and do some good old-fashioned detective work. Before you take that journey, take the time to understand how your company works and more importantly, why it isn’t as efficient as it could be. Perhaps management wants to know more about your customers, but can’t do it because customer data is stored in three different applications, and even then it takes two or three months to get an out-of-date report. Maybe your company is paying too much in commissions with multiple reps getting paid for the same deal. Has your company grown so fast that you have multiple purchasing and inventory management systems and hundreds of Excel spreadsheets that have all the answers – if only you could piece them together?

Perhaps you have a more urgent need to understand your customers. If you’re a pharmaceutical company, you need to follow strict spend management guidelines related to marketing to your customers. If you’re a financial services provider, you need to comply with capital management standards like Basel II and to understand your clients as mandated by federal Anti-Money Laundering legislation. Perhaps you’re a publicly held company and need to ensure that you comply with Sarbanes-Oxley. In any case, failure to comply with such legislation can lead to fines, damaged reputations or even imprisonment of top executives.

These all are commonly found reasons for pursuing an MDM solution. Take a moment – what reasons do you have for exploring MDM? If your company is like most that I talk to, you’ve got the problems that master data management can help solve.

I’m sure regular readers of this blog have noticed the reduced frequency of new articles in the past few weeks. It doesn’t mean that I don’t care about you, the reader – honestly!

But it does mean that it’s gotten much harder for me to write for this blog, because I’m typically at a client site Monday – Thursday, and correspondingly, life seems as it’s on “fast forward” lately, as I try to squeeze everything else into weekday evenings and Friday – Sunday.

I did find time to write a guest post for Identity Resolution Daily, a great blog maintained by Infoglide Software.

Here’s a brief excerpt:

There definitely seems to be a trend lately with small companies in the master data management (MDM) and data quality space being purchased (as in the asset acquisition of Exeros by IBM) or partnering with larger firms (such as Silver Creek Systems’ OEM relationship with Oracle).

I think this is a good thing. Using the classic “build, buy or ally” strategy, it isn’t surprising that sometimes companies will conclude that it’s faster and/or cheaper to buy a technology, or partner with another company that has that technology, rather than build it themselves internally.

For the complete article, please click “The Growing Role of Identity Resolution in MDM“.

Thanks for being patient with me as I re-adapt to life as a road warrior!

digg this | del.icio.us | Reddit | Stumble It!

Editor’s note: from time to time, the Hub Designs Blog profiles companies and solutions you may not have heard of yet that are relevant to master data management (MDM).

Company & location: Gryphon Networks, headquartered in Norwood, Massachusetts, provides “on demand contact governance” solutions.

Value proposition: Gryphon’s approach combines compliance and preference management, converting consumer contact preferences, compliance policies, and corporate governance into a consumer contact database, tracking the legal methods for contact. This gives you a “safe” list that expands your marketable base.

What point in MDM lifecycle: This is particularly useful when you’re using an MDM hub to support marketing activities and you’re concerned about maintaining a “single source of truth” on “Do Not Call” status, as well as opt-in / opt-out status for fax, email, and direct mail campaigns.

Relevance to MDM: Today’s hubs are evolving into “policy hubs”, where the enterprise can go beyond basic customer name & address data to tracking advanced attributes like contact preferences and managing compliance with a growing list of privacy regulations. But for a lot of industries, the current generation of MDM hubs doesn’t go far enough. That’s where Gryphon Networks comes in – it provides a real-time, on-demand contact governance capability that your MDM hub can interact with via Web Services.

If you’re in an industry like financial services, hotels, healthcare, telecommunications, insurance, etc. where there’s a need for a lot of outbound marketing activities and at the same time, strict privacy regulations around “Do Not Call” and opt-out status for e-mail, fax and direct mail marketing, your MDM strategy should probably include integration with Gryphon Networks’ platform.

For more information, contact Bob Hadden at rhadden@gryphonnetworks.com.

digg this | del.icio.us | Reddit | Stumble It!

The  Oracle Applications Users Group (OAUG) COLLABORATE 09 conference has wrapped up, and this year was a good one.

Attendance was down overall, from about 7,500 people last year to roughly 4,500 this year (caution, these are unofficial “word of mouth” numbers). But given the gloomy economic picture over the last 6-8 months, I was just happy the conference wasn’t canceled altogether. And I noticed that the people who were there were more engaged. These are the folks who had to fight to attend, so once they got there, they were more focused on getting the most out of it.

On the Master Data Management front, we had a great roster of presentations this year.

I particularly enjoyed Bob Barnett on “Design Guidelines for Oracle PIM MDM Processes”, Shyam Kadigari on “Oracle Customers Online Implementation”, Mani Kumar Manda on “Golden Rules to Tame the MDM Beast” and William McKnight on “Top 10 Mistakes Companies make in forming Enterprise Data Governance”.

I thought Pascal Laik, VP of MDM Product Strategy at Oracle, did a great job on “Rapid ROI with Oracle Master Data Management”. He did a demo of the ROI Analysis tool that Oracle has created, which looked very comprehensive and should save MDM teams a lot of time. Oracle customers can get access to this through their Oracle sales team.

There were a couple of presentations I was looking forward to but had to miss, including Bill Swanton from AMR Research on “Master Data Management for ERP Suites – It’s Different” and Brent Zionic from Sun Microsystems on “The Lunatic, the Lover & the Poet – Beyond Imagining Data Management”. Word of mouth feedback on these presentations was very good.

The OAUG is planning to offer a number of eLearning webinars over the rest of 2009, so we’re inviting all of the presenters (and anyone else interested in doing an eLearning session) to submit their ideas at http://secure.meetingexpectations.com/oaug/elearning/elSubmission.aspx.

I’ve been a member of the OAUG’s Education Committee for several years, and with the aid of the OAUG Special Interest Group (SIG) coordinators for Customer Data Management and Product Lifecycle Management / PIM, I’ve been planning the MDM track at each year’s conference. So if you’re interested in presenting at a future OAUG COLLABORATE conference, please sign up for Hub Designs’ newsletter, so I can keep you posted on the next Call for Papers.

digg this | del.icio.us | Reddit | Stumble It!

I’m heading to Orlando, FL this Sunday to attend and speak at the annual Oracle Applications Users Group (OAUG) conference.

I’m a volunteer member of the OAUG Education Committee, managing the Master Data Management track.  As such, I get to work closely with the Special Interest Group coordinators, and have a lot of fun planning the the MDM part of the conference.

This year, I’m very interested in hearing what all of our great MDM track speakers will have to say, and catching some of the Oracle executive presentations on their progress towards the Fusion applications suite.

As you might expect, I’m particularly interested in the Fusion MDM Hub, and Pascal Laik from Oracle will be doing a session on that.

I’ll try to write a few “dispatches from the front lines” here during the conference to share my thoughts on the various sessions.

Hope to see you in Orlando!

digg this | del.icio.us | Reddit | Stumble It!

Here’s a brief except from my monthly column in the May 2009 issue of Information Management magazine.

Master data management for product data (known as PIM, for product information management) is a different kettle of fish altogether from MDM for customer data (also known as customer data integration, or CDI). It is important to recognize and consider the fundamental differences between the two.

Click on “Product Information Challenges” to continue reading.

Please let me know what you think of the article by commenting here.

digg this | del.icio.us | Reddit | Stumble It!

In this series, we’ve discussed developing the MDM blueprint by creating the Common Information (Part 2), Canonical (Part 3), and Operating (Part 4) models in our work streams. We’ve introduced the Operating Model into the mix to communicate with the business how the solution will be adopted and used to realize the expected benefits. And hopefully we’ve set reasonable expectations with our business partners as to what this solution will look like when deployed.

Now, it’s time to model and apply the technical infrastructure or patterns we plan on using. The blueprint now moves from being computation and platform independent to one of expressing intent through the use of more concrete platform-specific models.

Reference Architecture

After the initial (CIM, Canonical, and Operating models) work is completed, then, and only then, are we ready to move on to the computation and platform specific models. We know how to do this – for example see Information ServicePatterns, Part 4: Master Data Management architecture patterns.

At this point, we now have enough information to create the reference architecture. One way (there are several) to organize this content is to use the Rozanski and Woods extensions to the classic 4+1 view model introduced by Philippe Kruchten. The views are used to describe the system in the viewpoint of different stakeholders (end-users, developers and project managers). The four views of the model are logical, development, process and physical view. In addition, selected use cases or scenarios are used to demonstrate or show the architecture’s intent. Which is why the model contains 4+1 views (the +1 being the selected scenarios).

Rozanski and Woods extended this idea by introducing a catalog of six core viewpoints for information systems architecture: the Functional, Information, Concurrency, Development, Deployment, and Operational viewpoints and related perspectives. This is elaborated in detail in their book titled “Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives”.  There is much to learn from their work, I encourage you to visit the book’s web site for more information.

What we are describing here is how MDM leadership within very large-scale organizations can eventually realize the five key “markers” or characteristics in the reference architecture to include:

• Shared services architecture evolving to process hubs;
• Sophisticated hierarchy management;
• High-performance identity management;
• Data governance-ready framework; and
• Registry, persisted or hybrid design options in the selected architecture.

This is an exceptional way to tie the technical models back to the stakeholders needs, as reflected in the viewpoints, perspectives, guidelines, principles, and template models used in the reference architecture. Grady Booch said “… the 4+1 view model has proven to be both necessary and sufficient for most interesting systems”, and there is no doubt that MDM is interesting. Once this work has been accomplished and agreed to as part of a common vision, we have several different options to proceed with. One interesting approach is leveraging this effort into a Service Orientated Modeling Framework introduced by Michael Bell at Methodologies Corporation.

Service-Oriented Modeling

The service-oriented modeling framework (SOMF) is a development life cycle methodology. It offers a number of modeling practices and disciplines that contribute to a successful service-oriented life cycle management and modeling. It illustrates the major elements that identify the “what to do” aspects of a service development scheme.

These are the modeling pillars that will enable practitioners to craft an effective project plan and to identify the milestones of a service-oriented initiative—in this case crafting an effective MDM solution.  SOMF provides four major SOA modeling styles that are useful throughout a service life cycle (conceptualization, discovery and analysis, business integration, logical design, conceptual and logical architecture).

These modeling styles: Circular, Hierarchical, Network, and Star, can assist us with the following modeling aspects:

• Identify service relationships: contextual and technological affiliations
• Establish message routes between consumers and services
• Provide efficient service orchestration and choreography methods
• Create powerful service transaction and behavioral patterns
• Offer valuable service packaging solutions

SOMF Modeling Styles

SOMF offers four major service-oriented modeling styles. Each pattern identifies the various approaches and strategies that one should consider employing when modeling MDM services in a SOA environment.

Circular Modeling Style: enables message exchange in a circular fashion, rather than employing a controller to carry out the distribution of messages. The Circular Style also offers a way to affiliate services.

Hierarchical Modeling Style: offers a relationship pattern between services for the purpose of establishing transactions and message exchange routes between consumers and services. The Hierarchical pattern enforces parent/child associations between services and lends itself to a well known taxonomy.

Network Modeling Style: this pattern establishes “many to many” relationship between services, their peer services, and consumers similar to RDF. The Network pattern accentuates on distributed environments and interoperable computing networks.

Star Modeling Style: the Star pattern advocates arranging services in a star formation, in which the central service passes messages to its extending arms. The Star modeling style is often used in “multi casting” or “publish and subscribe” instances, where “solicitation” or “fire and forget” message styles are involved.

There is much more to this method, so I encourage you to visit the Methodologies Corporation site and download the tools, power point presentations, and articles they’ve shared.

Summary

Based on my experience, we have to get this modeling effort completed to improve the probability we’ll be successful. MDM is really just another set of tools and processes for modeling and managing business knowledge of data in a sustainable way. Take the time to develop a robust blueprint to include the Common Information (semantic, pragmatic and logical modeling), Canonical (business rules and format specifications), and Operating Models to ensure completeness. Use these models to drive a suitable Reference Architecture to guide design choices in the technical implementation.

This is hard, difficult work. Anything worthwhile usually is. Why put the business at risk to solve this important and urgent need without our stakeholders understanding and real enthusiasm for shared success? A key differentiator and the difference between success and failure on an MDM journey is taking the time to model the blueprint and share this early and often with the business. This is after all a business project, not an elegant technical exercise. Creating and sharing a common vision through our modeling efforts helps ensure success from inception through adoption by communicating clearly the business and technical intent of each element of the MDM program.

In the last part of the series, I’ll discuss where all this fits into the larger MDM program and how to plan, organize, and complete this work.

Continue with Part 6 or go back to Part 4.

digg this | del.icio.us | Reddit | Stumble It!

Editor’s note: another in an occasional series where the Hub Designs Blog profiles companies and solutions you may not have heard of that are relevant to master data management (MDM).

Company & location: SmartCo, headquartered in Paris, France, with an office in Boston MA, provides a product called the SmartCo DataHub, a master data management solution for financial institutions.

Value proposition: SmartCo DataHub consists of several data management modules including a Security Master, which handles every type of asset class and manages reference data, market data and corporate actions data. The product can receive information from many different internal or external sources, and then cleanse it, enhance it and distribute it to all departments and systems, so everyone shares the same data.

SmartCo DataHub also provides other modules such as Indices and Benchmarks, and Business Entity Management, which centralizes and consolidates all information about third parties with which the financial institution is directly or indirectly in business. This is linked to the Security Master for monitoring and mitigating credit and operational risks.

SmartCo DataHub has built-in connectors to data sources like Bloomberg, Thomson/Reuters, Factset, Interactive Data, Markit, Six Telekurs / Fininfo, and several others. SmartCo DataHub is designed using the latest SOA technology in order to provide users with more flexibility.

What point in MDM lifecycle: this would be most appropriate for banks and other financial institutions looking to replace one or more internally built security masters. Most financial services companies don’t regard creating their own custom security master as a competitive advantage any more. So a “commercial off-the-shelf” (COTS) solution might be a good fit for companies looking to reduce the number of security masters they’ve got to maintain, and save money vs. developing a new security master internally.

Relevance to MDM: the financial services industry is going through its biggest upheaval in more than 75 years. But consolidating multiple custom built systems that are expensive to maintain can save a lot of money and provide a very strong return on investment.

If you’re in the financial services industry and are investigating master data management as a strategy for cost savings, revenue enhancement or regulatory compliance, SmartCo is an interesting company that is growing its presence in the North American market.

digg this | del.icio.us | Reddit | Stumble It!

Editor’s note: another installment in an ongoing series where the Hub Designs Blog profiles companies and solutions which are relevant to master data management (MDM).

Company & location: Silver Creek Systems, headquartered in Westminster, Colorado, provides automated data mastering solutions which enable enterprise-wide standardization and integration of product information.

Value proposition: I recently had a briefing with several Silver Creek people. Their core product, DataLens™, applies semantic technology to standardize, enrich, match, repurpose and govern product information. I think of it as data quality for product information on steroids.

The semantic approach makes a lot of sense. I remember from my ERP days how painful dealing with product information can be (requiring endless massaging in Excel or complex SQL queries to extract and reformat it). Silver Creek seems to have an intelligent solution to one of the thorniest issues in MDM.

What point in MDM lifecycle: if your MDM initiative involves product information, you’ll quickly find out that Product MDM is very different from Customer MDM. It’s common for product data to have dozens or even hundreds of required attributes. The hierarchy management requirements for product data are typically more complex. And because a lot of product data is unstructured or semi-structured, you need a specialized parsing engine if you want to automate the standardization of your data.

Relevance to MDM: data quality tools designed for customer information have a hard time handling the widespread variability of product data, its relative lack of structure, the dearth of referential data from third-party sources, the overloading of the “description” field, the classification and categorization requirements and the added complexity in hierarchy management.

As I do more work in the Product MDM area, I’m impressed with Silver Creek Systems and its DataLens solution.

Update on 04/14/09: Silver Creek Systems announced today that its DataLens™ System was named the top Data Quality product by SearchDataManagement.com’s 2008 Products of the Year program. The awards were judged by a team of industry analysts and consultants and presented by the editors of TechTarget’s Enterprise Applications Media Group. For more information, please visit http://www.silvercreeksystems.com/PR_SDMPOY2008/.

digg this | del.icio.us | Reddit | Stumble It!

Usually, when I’ve written a magazine article, I’ll post a brief excerpt here, with a link to the full article. When I moved from the online edition of DM Review (now known as Information Management) to writing a monthly column in the print edition, somehow I forgot to keep doing that.

So here are brief excepts and links to the full articles for the past few months, in case you haven’t already seen them.

Feb. 2009: For years I’ve been recommending that companies investigating or implementing MDM should include business process management in their plans. BPM allows an organization to model, deploy and manage mission-critical processes that span multiple applications, departments and business partners – behind the firewall and over the Internet.

Click on “Business Process Management and MDM” to continue reading.

Mar. 2009: I recently came across a great quote on data quality by Ken Orr in “The Good, the Bad and the Data Quality” from the Cutter Consortium: “Ultimately, poor data quality is like dirt on the windshield. You may be able to drive for a long time with slowly degrading vision, but at some point, you either have to stop and clear the windshield or risk everything.”

Click on “Data Quality and Master Data Management” to continue reading.

Apr. 2009: Third party content is an area that’s close to my heart. I started working intensively with customer and product information more than 20 years ago and was one of the first consultants to integrate Dun & Bradstreet data with Oracle’s applications suite (about seven years ago).

Click on “Filling in the Gaps” to continue reading.

As always, please let me know what you think by commenting here.

digg this | del.icio.us | Reddit | Stumble It!

Data Quality Pro^TM is a free, independent community resource dedicated to helping data quality professionals take their career or business to the next level. Founded and managed by data quality professionals, its mission is to create the most beneficial data quality resource that is freely available to members around the world. 

Dylan Jones, founder & editor, interviewed me recently, and the interview appears on the Data Quality Pro site today.

Please click here to read the full interview.

digg this | del.icio.us | Reddit | Stumble It!

In Part 2 and Part 3 of this series, we discussed the Common Information and Canonical Models. Because MDM is a business project, we need to establish of a common set of models that can be referenced independently of the technical infrastructure or patterns we plan on using. Now it is time to introduce the Operating Model to communicate how the solution will actually be deployed and used to realize the expected benefits.

This is the most important set of models you will undertake. And sadly, not widely accounted for “in the wild”, meaning rarely seen, much less achieved. This effort describes how the organization will govern, create, maintain, use, and analyze consistent, complete, contextual, and accurate data values for all stakeholders.

There are a couple of ways to do this. One interesting approach I’ve seen is to use the Galbraith Star Model as an organizational design framework. The model is developed within this framework to understand what design policies and guidelines will be needed to align organizational decision making and behavior within the MDM initiative.

The Star model includes the following five categories:

Strategy: Determine direction through goals, objectives, values and mission. It defines the criteria for selecting an organizational structure (for example functional or balanced matrix). The strategy defines the ways of making the best trade-off between alternatives.

Structure: Determines the location of decision making power. Structure policies can be subdivided into:
- specialization: type and number of job specialties;
- shape: the span of control at each level in the hierarchy;
- distribution of power: the level of centralization versus decentralization;
- departmentalization: the basis to form departments (function, product, process, market or geography).

In our case, this will really help when it comes time to designing the entitlement and data steward functions.

Processes: The flow of information and decision processes across the proposed organization’s structure. Processes can be either vertical through planning and budgeting, or horizontal through lateral relationships (matrix).

Reward Systems: Influence the motivation of organization members to align employee goals with the organization’s objectives.

People and Policies: Influence and define employee’s mindsets and skills through recruitment, promotion, rotation, training and development.

Now before your eyes glaze over, I’m only suggesting this be used as a starting point. We’re not originating much of this thought capital, only examining the impact the adoption of MDM will have on the operating model within this framework. And more importantly, identifying how any gaps uncovered will be addressed to ensure this model remains internally consistent. After all, we do want to enable the kind of behavior we expect in order to be effective, right?

A typical design sequence starts with an understanding of the strategy as defined. This in turns drives the organizational structure. Processes are based on the organization’s structure. Structure and Processes define the implementation of reward systems and people policies.

The preferred sequence in this design process is composed in the following order: (a) strategy; (b) structure;  (c) key processes; (d) key people; (e) roles and responsibilities; (f) information systems (supporting and ancillary); (g) performance measures and rewards; (h) training and development; (i) career paths. 

The design process can be accomplished using a variety of tools and techniques. I have used IDEF, BPMN or other process management methods and tools (including RASIC charts describing roles and responsibilities, for example). What ever tools you elect to use, they should effectively communicate intent and be used to validate changes with the stakeholders, who must be engaged in this process.

Armed with a clear understanding of how the Star model works we can turn our attention to specific MDM model elements to include:

Master Data Life Cycle Management processes
- Process used to standardize the way the asset (data) is used across an enterprise
- Process to coordinate and manage the lifecycle of master data
- How to understand and model the lifecycle of each business object using state machines (UML)
- Process to externalize business rules locked in proprietary applications (ERP) for use with Business Rules Management Systems (BRMS) (if you’re lucky enough to have one )
- Operating Unit interaction
- Stewardship (Governance Model)
- Version and variant management, permission management, approval processes
- Context (languages, countries, channels, organizations, etc.) and inheritance of reference data values between contexts
- Hierarchy management
- Lineage (historical), auditability, traceability

I know this seems like a lot of work. Ensuring success and widespread adoption of Master Data Management mandates this kind of clear understanding and shared vision among all stakeholders. We do this to communicate how the solution will actually be deployed and used to realize the benefits we expect.

In many respects, this is the business equivalent to the Technical Debt concept Ward Cunningham developed (we’ll address this in the next part on Reference Architecture) to help us think about this problem. Recall this metaphor means doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort we have to do in future development because of the quick and dirty design choices we have made. The same concept applies to this effort. The most elegant technical design may be the worst possible fit for the business. The interest due in a case like this is, well, unthinkable.

Take the time to get this right. You will be rewarded with enthusiastic and supportive sponsors who will welcome your efforts to achieve success within an operating model they understand.

Continue with Part 5 or go back to Part 3.

digg this | del.icio.us | Reddit | Stumble It!

In Part 2 of this series we discussed the Common Information Model. Because MDM is a business project, we need to establish of a common set of models that can be referenced independently of the technical infrastructure or patterns we plan on using. The essential elements should include:

- Common Information Model
- Canonical Model
- Operating Model, and
- Reference Architecture (e.g. 4+1 views, viewpoints and perspectives).

We will now turn our attention to the second element, the Canonical Model.

The Canonical Model (business rules and format specification) describes how the extraction of business rules from the software portfolio are managed and shared among other applications.  In addition to externalizing business rules locked in proprietary applications (for example, ERP or CRM), we also use design patterns defined here to communicate between different data formats. Instead of writing translators between each and every format (with potential for a combinatorial explosion), use this in combination with the CIM to write a translator between each format and the canonical format using rules to guide the effort. See the Open Applications Group Integration Specification (OAGIS) as example of an integration architecture that is based on a canonical data model. Implicit (and emerging now as generally accepted practice) is the use of rules (rules engines like iLOG for example) to handle reference data that must be shared across systems beyond software packages in our portfolio.  OAGIS uses XML as the common protocol for defining business messages and processes (scenarios) to enable business applications to communicate among one another in a standard manner. Not only the most complete set of XML business messages currently available (there are others several others, see the eXtensible Business Reporting Language (XBRL) for example), it also accommodates specific industries by collaborating with vertical industry groups to add and extend additional requirements as needed. For another real working example in the Product Information Management (PIM) space see GS1 Global Data Synchronization Network and the standards that make this possible. 

Nick Malik over at Inside Architecture  has written an exceptional post about this. We may not agree on all aspects (mostly semantics), but I think he has summed up well what this set of models should address in the blueprint. His post addresses the essential elements a complete modeling effort would produce. These products would typically include:

Canonical Message Schema - describes how when passing messages from one application to another we pass a set of data between applications where both the sender and the receiver have a shared understanding of what the values are: (a) data type, (b) range of values, and (c) semantic meaning. 

Event Driven Perspective (Views) - a style of architecture characterized by a set of relatively independent actors who communicate events amongst themselves in order to achieve a coordinated goal.  This can be done at the application level, the distributed system level, the enterprise level, and the inter-enterprise level (B2B and EDI).  Although we disagree on where this effort belongs (see Part IV of this series on reference architecture development), the logical view will have its origins here. 

Business Event Ontology - This ontology includes a list of business events, usually in a hierarchy, that represents the points in the overall business process where two or more objects (entities) need to communicate or share the same data values and intent (semantics).  And this, as Nick states is “is not the same as a process step. An event may trigger a process step, but the event itself is strictly speaking simply a “notification of something that has occurred,” not the name of the process.  Ontology development is a pretty exciting technology I have watched mature from simple lab exercises (toys really), to something far more useful. For more on this see Part II (The Common Information Model) or my post at Essential Analytics about the Protege ontology editor.

Business Rules - The last modeling effort is the collection (identification and grouping) of the rules used to define the behavior of the elements we have already referred to. Typically buried in application code, (if you are not lucky enough to have a Business Rules engine <g>), this model describes the business rules, protocol, and default behavior expected when the model elements interact with each other (especially useful when exceptions occur or logical constraints are violated).  Not a common artifact I find; I wish more of us would take the time and effort to accomplish this task.  For another real world reference, see the  GDSN Package Measurement Rules (issue 1.9.2) for the global definition of nominal measurement attributes of product packaging or the GDSN Validation Rules.

As I stated in Part 2, this is hard challenging work. The key differentiator and difference between success and failure on your MDM journey will be taking the time to model the blueprint and sharing this work early and often with the business. We will be discussing the third (and most important element) of the MDM blueprint, the Operating model in part 4. I encourage you to participate and share your experience, as we can all learn from each other.

Continue with Part 4 or go back to Part 2.

digg this | del.icio.us | Reddit | Stumble It!

In Part 1 of this series, we discussed what essential elements should be included in an MDM blueprint. The important thing to remember is that MDM is a business project that requires establishing a common set of models that can be referenced independently of the technical infrastructure or patterns you plan on using. The blueprint should remain computation and platform independent until the models are completed (and accepted by the business) to support and ensure the business intent. The essential elements should include:

- Common Information Model
- Canonical Model
- Operating Model, and
- Reference Architecture (e.g. 4+1 views, viewpoints and perspectives).

We will now turn our attention to the first element, the Common Information Model.

A Common Information Model (CIM) is defined using relational, object, hierarchical, and semantic modeling methods. What we are really developing here is rich semantic data architecture in selected business domains using:

• Object Oriented modeling: reusable data types, inheritance, operations for validating data
• Relational: manage referential integrity constraints (primary keys, foreign keys)
• Hierarchical: nested data types and facets for declaring behaviors on data (e.g. think XML schemas)
• Semantic models: ontologies defined through RDF, RDFS and OWL

I believe (others may not) that MDM truly represents the intersection of Relational, Object, Hierarchical, and Semantic modeling methods to achieve a rich expression of the reality in which the organization operates. Expressed in business terms, this model represents a “foundation principal” or theme we can pivot around to understand each facet in the proper context. This is not easy to pull off, but will provide a fighting chance to resolve semantic differences in a way that helps focus the business on the real matters at hand. This is especially important when developing the Canonical model introduced in the next step.

If you want to see what one of these looks like visit the MDM Alliance Group (MAG). MAG is a community that Pierre Bonnet founded to share MDM Modeling procedures and pre-built data models. The MDM Alliance Group publishes a set of pre-built data models that include the usual suspects (Location, Asset, Party, Party Relationship, Party Role, Event, Period [Date, Time, Condition]) downloadable from the website. And some more interesting models like Classification (Taxonomy) and Thesaurus organized across three domains. Although we may disagree about the “semantics”, I do agree with him that adopting this approach can help us avoid setting up siloed reference databases “…unfortunately often noted when using specific functional approaches such as PIM (Product Information Management) and CDI (Customer Data Integration) modeling”. How true. And an issue I encounter often.

Another good example is the CIM developed over the years at the Distributed Management Task Force (DMTF). You can get the CIM V2.20 Schema MOF, PDF and UML at their web site and take a look for yourself. While this is not what most of us think of as MDM, they are solving for some of the same problems and challenges we face.

Even more interesting is what is happening in semantic technology. Building semantic models (ontologies) includes many of the same concepts found in the other modeling methods we’ve already discussed but further extend the expressive quality we often need to fully communicate intent. For example:

- Ontologies can be used at run time (queried and reasoned over).
- Relationships are first-class constructs.
- Classes and attributes (properties) are set-based and dynamic.
- Business rules are encoded and organized using axioms.
- XML schemas are graphs not trees, and used for reasoning.

If you haven’t been exposed to ontology development, I encourage you to grab the open source Protege Ontology Editor and discover for yourself what this all about. And while you are there see the Protégé Wiki and grab the Federal Enterprise Architecture Reference Model Ontology (FEA-RMO) for an example of its use in the EA world. Or see the set of tools found at the Essential project. The project uses this tool to enter model content, based on a model pre-built for Protégé. While you are at the Protégé Wiki, grab some of the ontologies developed for use with this tool for other examples, such as the SWEET Ontologies (A Semantic Web for Earth and Environmental Terminology. Source: Jet Propulsion Laboratory). For more on this, see my post on this tool at Essential Analytics. This is an interesting and especially useful modeling method to be aware of and an important tool to have at your disposal.

This is hard challenging work. Doing anything worthwhile usually is. A key differentiator and the difference between success and failure on your MDM journey will be taking the time to model the blueprint and sharing this work early and often with the business. We will be discussing the second element of the MDM blueprint, the Canonical model in Part 3. I encourage you to participate and share your professional experience via the comments here.

Continue with Part 3 or go back to Part 1.