In the first and second segments of this series, we discussed situations where implicit values are woven into business processes or IT systems unknowingly or on purpose. The examples provided may seem trivial on the surface if one considers that everybody in the business had the implicit knowledge needed to make sense of the information. It is not so trivial when time passes, employees retire or leave, and there are implicit values scattered around the enterprise that nobody remembers anymore. Add to that the fact that implicit values, by nature, are not self-documenting and in my experience rarely externally documented. By now you should be able to identify the existence of implicit values in overloaded, NULL, or implied default values within your organization. More importantly, you should understand the potential consequences of each situation and be able to intelligently challenge those who perpetuate these practices. This last section provides alternatives to implicit designs and provides methods for mitigating risks within legacy systems.

Governance Policies are where many data quality issues get resolved or avoided. Without defined Governance, the status quo becomes the standard and data quality does not improve. Adding new policies may do little for directly combatting legacy system shortcomings, but it does set the stage for preventing the proliferation of implicit values by mandating that new interfaces to legacy systems not accept them.

An involved and informed Data Governance team is the best defense to limiting proliferation of implicit values. Introducing an enterprise-wide standard to restrict the use of optional relationships between code parent and referring child tables is a start. As stated earlier, optional relationships are ones that allow NULL child table values to exist. For example, a sales table allows a discount type code of NULL if no discount applies. To satisfy such a mandate in this situation, discount code table entries of ‘Not Provided’ and ‘No Discount’ would be added. If a NULL is received, the relationship maps to the ‘Not Provided’ entry. The Point of Sale system could now default a discount to the ‘No Discount’ code value if none was given. This solution explicitly provides a discount value in all situations and provides an easy means to identify when data transformation issues occur if a ‘Not Provided’ value sneaks in. The approach leaves open possibilities for additional entries in code tables to represent a ‘Not Applicable’ business condition or an ‘Invalid’ situation which could be set if a code value is detected during loading of the sales table that does not match a value within the domain of valid discount codes.

A Data Governance body worth its salt creates standards concerning definition, collection, and dissemination of metadata. In the policy planning phase, the Governance body can define the required column-level metadata collected to include values like: Default Value, Min/Max values, Domain, and Nullability. If business users define that NULL values are allowed, a follow-up discussion is required to determine the business meaning of a NULL value. Such a discussion is the opportune time to explore options to NULL values. Forcing the business data owners to define data elements to this degree provides the rules to eliminate several forms of undesired implicit values and it makes for better business system designs.

A strong Data Architecture group plays a role in Data Governance policy enforcement. Data Architecture groups influence database and application designers to use NOT NULL and default value constraints and to define relationships as ’Required’ instead of ‘Optional.’ Mandatory peer code reviews using checklists ensure designs meet enforced policies.

Overloading, as defined in the first segment of this series, is a costly practice that is easily avoided through proper data design techniques. Overloaded code values are avoided by creating separate child fields and separate parent code tables. Overloading of transaction metrics is handled similarly by splitting transaction values into different attributes if at the same summary level or different tables if transactions are at different summary levels. Overloaded records, like copybooks, just have no place in relational database design. If somebody tries to justify them, you have my permission to mock them in public but I am not responsible for any repercussions if the mock-ee is your boss.

The goal of this article was to demonstrate that using implicit values comes with long term consequences and this practice should be scrutinized. There are compelling arguments to use implicit design methods, but doing so should be done knowing all of the options, consequences, risks, and potential long-term costs. Resist temptations for quick-fixes when it comes to data design and focus instead on best practices.

The first segment of this series defined implicit values as ones that require additional context in order to infer an unambiguous meaning from the value. The segment went on to define how coded values are a valuable design practice that does not cause concern when each component of the implicit relationship exists within a single domain. A derivation to the coded values concept called “Overloading” was discussed as an undesirable practice where one column or record spans more than one domain. In this segment, we’ll discuss the practices of implicit defaulting and the assigning of implicit business meaning to blanks or NULL values other than the business meaning of “uh, nobody put a value here.”

From a user perspective, text fields containing a NULL or any number of blank spaces look the same. Although the casual business user cannot tell the difference between NULL and blanks, the computer treats them very differently and even changes retrieval performance based on the distinction.[1]  Suppose a data source or entry screen of a Yes/No business attribute defines that a NULL has an implicit meaning of ‘No’ because the value was not explicitly set to ‘Yes’. Since ‘No’ and NULL implicitly mean the same thing, the business cannot determine if the value was intentionally meant to be ‘No’ or if the user accidently missed data entry, but intended to select ‘Yes’. Unless somebody realizes and corrects the mistake, the value will be incorrect and nobody will ever know. Now suppose this column propagates through and ends up in an MDM system and the corporate data warehouse as Null and considered the best version of the truth. To accurately perform analyses using the column with this implied business rule, one must check for a ‘Y’ or the existence of both NULL and ‘No’. Another analysis option would be to check for a ‘Yes’ or a Not Equal to ‘Yes’ condition. In either case, a consumer of this column has to implicitly know that a NULL and ‘No’ are the same and even with this knowledge, the consumer still does not have confidence that the column was intentionally meant to be ‘No’.

Expand the above discussion to consider a lookup code value. The practice of allowing NULL code values is referred to as creating an ‘optional relationship’ within a parent (code table) and a child (reference table). Code tables are, by definition, explicit domains of allowable codes with each having a mutually-exclusive meaning for a record. Allowing NULL values for codes poses a similar ambiguity towards the data meaning. Did the user or source neglect to enter a value? Does the existence of NULL implicitly mean something else, like ‘Not Applicable’?

I can think of no positive business value to introducing ambiguity in data, ever. Moreover, there should be no compelling argument to intentionally inject ambiguity into new designs, especially in MDM or BI systems which are supposed to be reliable and pristine. When doing data integration from multiple systems, such as merging data into MDM or BI systems, the existence of NULLs and implicit values introduces several unnecessary challenges. MDM and BI systems are tasked with the collect of information from multiple sources with the intention of conforming it to a single Enterprise view. Adding implicit values to that process ensures logic will be needed in the transformation layer to conform it to the “Best Version of the Truth”. Once in the MDM Hub, more logic is necessary to transform the data back to its implicit form for each of the consuming systems.

“Oh what a tangled web we weave when first we try to cut corners and be implicit.”

In the last part of this three-part series, we will review the revelations thus far and discuss ways to both manage implicit legacy conditions and implement policies to keep from creating any additional ones.

Before you report me for animal cruelty, did you paint a mental image of me or the cat in pajamas? How do you know I wasn’t referring to the phrase used in the 1920’s to describe a person at the top of their game, Cat’s Pajamas? Would your opinion of me change if you had implicit knowledge that I was a professional photographer specializing in novelty pet shoots? How about if you knew I photographed vintage sports while wearing bed clothes or made analogies as if cars were dressed? Maybe you implicitly know I am a caretaker that lives at a zoo who carries a tranquilizer gun for safety or that I am a guide for a big-game safari hunting club? Do I need to go on? A simple factual statement like this is common in tabloid press because without proper context or additional implicit information, it is easy to reach invalid conclusions.

Computers are good at many things, but unless they are programmed to be learning machines, computers are not good at inferring context.  Moreover, computers don’t need to infer context if system designers and data owners understand how ambiguity affects their MDM and Data Governance effectiveness.

Do your business users have all the information they need to absolutely reach valid conclusions in every situation? If you said ‘Yes’ and truly understand what the term ‘implicit values’ means, you don’t need to continue reading.

Looks like all of you are still here. For the record, I was not the one that was wearing pajamas.

In Data Architecture terms, an implicit value is one that is conveyed indirectly by applying information found elsewhere. The antonym of an implicit value is an explicit one, which is a value with a self-contained purpose that exists in a single domain (which means that all values are of the same type and have the same business rules applied to them). These topics will be further discussed in this article. In practice, explicit definitions are desired over implicit ones, but there are exceptions.

This article will present the various scenarios, reasons, risks, and alternatives to having certain types of implicit values in your design and why there is literally no reason to use certain types of implicit values in MDM or BI architectures. Three classes of implicit values will be presented: Coded Values, Overloading, and Null/Default values.

Using coded values is a widely accepted and valuable relational modeling practice used to classify a value within a single domain as defined by a separate code value. For example, a GL dollar amount can be assigned to one of many GL Line Types. Two columns consisting of the GL dollar amount and the GL Line Type Code are implicitly linked together because each has no context without the other. This is an acceptable design practice because each column exists in one and only one domain: GL dollar amounts or GL Line Type Codes.

Overloaded columns or records, on the other hand, exist when one of the columns can be of a different domain based on the value of another. If the GL amount from the previous example represented a dollar amount for one GL line type and an item count for a different GL line type, the GL amount column would be considered overloaded.

This practice was done quite often in the past using COBOL Copybooks. Copybooks exist under the premise that a variable record type was an efficient way to model information within a 3GL coding environment. With the advent and advances of relational databases (and normalization standards), the copybook approach does not translate well into database tables (thank goodness).

One disadvantage of using overloaded columns is that the characteristics of a column are dictated by the superset of all the domains the column represents. This removes one of the benefits of defining a domain to explicitly enforce data quality, integrity, and definition.  For example, if an overloaded column implicitly stores either the nine characters of a Social Security Number or an account holder’s alpha-numeric 14 character Member ID, the column must be at least 14 characters in length and allow for numbers and characters. This makes it more difficult to explicitly enforce SSN formatting rules and display options because it needs some outside code or test to put the value into context.

Overloading inherently restricts a record into referencing only one type of value, which on the surface may seem like a noble goal because it guarantees mutual exclusivity. In some business cases this may never change, but in others, the intent may be short-sighted when business rules change. For instance, an overloaded column of division code and line of business code created under the premise that a record would align to only one of these classifications breaks if products realign to span multiple LOBs.

Whether the reason for using this approach was to upgrade older systems cheaply, or because a designer believed at the time that it was an innovative solution to a problem, the results are the same. Overloading makes data management more difficult, data quality harder to enforce, adds risk of incorrect use of data, and longer-term data changes become more expensive. Despite the brow-beating (or possibly because of the lack of it), designers and developers still overload columns in ERP, CRM, and custom-developed systems. Their existence in legacy systems may not be undoable without costly rework, but they have no place in good MDM or BI design (more on this later).

In the next installment of this series, we’ll discuss the use of NULLs and default values.

Convergence Clarifies Benefits and Value

In a recent Gartner report covering predictions for data integration and MDM:

Through 2015, 66% of organizations that initiate an MDM program will struggle to demonstrate the business value of it.

It’s probably not a stretch to extend this “struggle for value” to BPM and BI / analytics. But through the convergence of MDM with BI / analytics and BPM, an analyst like Sandy Kemsley sees increased business value, in this Loraine Lawson interview:

Lawson: It’s become more important with MDM to identify pain points and a real business case. Yet MDM is still pretty IT-centered. Does connecting it to business process management (BPM) allow it to be more business-focused as a project?

Kemsley: Absolutely – connecting it to BPM, and also connecting it to business intelligence and analytics, because that’s one of the things that many business users are interacting directly with (analytics), whether it’s just simple reporting or dashboards or a more complex drill-down. You can get better analytics if you have consistent data models and those consistent data models are going to be helped by MDM, that’s one of the key business benefits. When you want to have a report that gathers data from a number of different systems, it’s not going to be some huge, big, long project because somebody has to figure out what data maps onto what other data. It’s going to be a much more straightforward thing because while the data may not all be in one place, at least it will be in a consistent format so that you can easily bring it together.

Individually these solutions can achieve some value and success for an enterprise, but at the cost of much duplicated effort and resources.

In convergence, with initiatives for business improvement and better decision-making, an integration of BI/analytics, BPM, data governance and MDM has definite synergistic outcomes that can greatly increase business value and reduce wasted effort.

Integrating business insights into process execution will significantly improve the quality of decisions and lead to continuous process optimization. And process events kicking off BI and analytics for real-time decision-making increases beneficial outcomes.

All of these solutions should be about solving frequently complex business problems and supporting the work to be done in the enterprise. Each solution brings a significant piece of the “big picture”: better decisions for the business with reliable data feeding both intelligence and process. Ultimately the biggest payoff is how this convergence feeds directly into business agility and continuous change to constantly fine tune sustainable competitiveness.

About the author: Julie Hunt is an accomplished software industry analyst, providing strategic market and competitive insights. Her 20+ years as a software professional range from the technical side to customer-centric work in solutions consulting, sales and marketing. Julie shares her take on the software industry via her blog Highly Competitive and on Twitter: @juliebhunt. For more information: Julie Hunt Consulting – Strategic Product & Market Intelligence Services.

Master data management (MDM) is a good reflection of how an enterprise uses data, information – and content – for business purposes. The creation and management of master data touches more than the information itself. By creating data repositories and processes that reflect business functions, an enterprise should develop access to the information that is so crucial to effectively and efficiently achieving its business goals. It’s extremely important to analyze, manage and provide access to all forms of information – structured and semi-structured data, as well as “unstructured” content.

For BI and analytics solutions to provide real intelligence, they must be based on accurate and timely data. BI outputs are based on data aggregations, until recently, from structured data in data warehouses, with delivery in the form of reports or dashboards to enterprise users. Analytics add the dimension of mathematics and formulas, with variants addressing forecasting and prediction.

Neil Raden responds to the ebizQ question: How does master data management change BI?:

…to describe how organizations collect data as part of a process, but manage to make it infinitely more valuable by using it for other purposes.

What does this have to do with BI and MDM? In our research, we have found that most knowledge workers shun BI for two reasons (not performance or ease-of-use): relevance and understanding. MDM adds nothing to address these concerns because its representational framework, a relational schema, is inadequate. It’s a representation of a model. An ontology is a model. Until MDM rejects the relational model as its underlying schema, it will be unable to add the rich meaning, relationships and even reasoning that an ontology can do.

So, the point is, if you’re going to go to the massive effort and expense of an MDM solution, take some advice from 21 years ago… Make the data useful for people, not just governors and black belts.

One newer area of interest for BI and analytic solutions is the inclusion of collaborative activities to add contextual and qualitative layers to the output of BI processes. To achieve authentic intelligence, contextual / qualitative layers can provide a strong basis to test, fine tune and filter the artifacts of analytics.

Analytics can benefit greatly from human filters that bring experience, knowledge and creative thinking. Context has a big role here: context for sources, context for outcomes, context for usage with other data points, to achieve the optimal intelligence for “making better business decisions”.

The possibilities for new applications of analytics increase with collaboration. Inviting in many-to-many interactions also opens up processes to new ideas from participants. Gartner found that social venues and collaboration help to track and capture outcomes of the decisions made based on BI / analytics:

Gartner’s user surveys show that improved decision making is the key driver of BI purchases. However, most BI deployments emphasize information delivery and analysis to support fact-based decision making, but fail to link BI content with the decision itself, the decision outcome, or with the related collaboration and other decision inputs. This makes it impossible to capture decision-making best practices. Solutions are emerging that tie BI with social software and collaborative tools for higher-quality, more transparent decisions that will increase the value derived from BI applications.

With convergence, employees in the enterprise should operate more effectively, where improved data governance/MDM lead to better BI, where collaborative processes also enhance and validate BI, where a collaboration setting for BPM works to deliver more of the information that the enterprise needs.

A possible approach to marrying collaboration, data and intelligence to business processes, and, more importantly, to the way people work, can be seen in Tibco’s re-working of tibbr. Dennis Howlett provides this description of tibbr:

It intelligently marries people, process and context, delivering information the way people want to consume

Tibco connects tibbr to business processes and event-triggering that are then exposed in tibbr for taking action. While tibbr is built more for real-time information streams than archives of content and information, tibbr and Tibco have created a platform with a lot of potential for improving overall information findability that adheres to context and worker roles.

It connects to process, people/workers, collaboration venues, data and information streams, centralizing all event streams into one dashboard. Information can be organized by subject or topic, rather than by people. tibbr enables users to create, contribute to, and subscribe to the real-time event streams that matter most to them.

About the author: Julie Hunt is an accomplished software industry analyst, providing strategic market and competitive insights. Her 20+ years as a software professional range from the technical side to customer-centric work in solutions consulting, sales and marketing. Julie shares her take on the software industry via her blog Highly Competitive and on Twitter: @juliebhunt. For more information: Julie Hunt Consulting – Strategic Product & Market Intelligence Services.

Most business intelligence architects are well versed in the value of the time dimension.

With query performance and the need to support complex analyses being the two most important considerations in BI, a flattened set of time dimensions provides a multitude of options to represent and standardize time with limited overhead.

It’s easy to see the value of having a flexible, consistent, and integrated representation of time when thinking of business activities. Aspects such as when a transaction or activity occurs in relationship to other transactions, activities, or even pre-defined thresholds form the basis of Business Process Management activities. And accounting departments group transactions into time periods every financial reporting period.

So, how valuable can this same time dimensions be to a Master Data Management solution? If you are well versed in MDM at this point, you’re probably saying “What you’ve talked about so far is useful for relating transactions but it doesn’t tie back to mastering business objects like customers, products, or locations”.

But remember that mastering those objects does require standardization during information acquisition and publishing and that the various inputs and outputs to an MDM system are often diverse. Also, don’t underestimate the value of mastering “Time Tables” themselves as a component in your MDM universe.

First, let’s define just what we mean by a set of time tables before we apply them to MDM. A typical implementation would have two distinct groups of tables to represent time: day, and time-of-day. At the lowest level of the day group is a day-level table with every imaginable way the business can identify a day, such as: by its day of year, week, month, quarter, advertising week (for retail), same day last year (in some special context), or special tags like holiday, weekend, season, positional sunrise/sunset times, or even astrological sign and full moon cycles. And that just covers the calendar view of the business. There is an equally important and extensive set of calendar hierarchies and attributes associated with the business fiscal reporting needs. Add to that every way you want to represent attributes like day of the week or month of the year (number, 3-letter abbreviation, full name) and ending up with over 100 attributes in the day-level table is not uncommon.

Related to the day-level table are hierarchy tables at levels such as: month, quarter, year (and their fiscal counterparts). Each of the hierarchy tables contains all the attributes that define that level and higher levels. For example, the calendar month table would contain attributes defining month of year, month of quarter, and month overall, in addition to quarter and year and all the ways to call the month. Primary keys for the higher level hierarchy tables, like month, would have child entries in the lower level tables, like day, for every entry that rolls into the higher level.

The same holds true for time of day, with hierarchies like hour, minute of hour, shift, peak time, off-peak time, and others.

Because all the higher-level attributes are repeated in the lower-levels, there is typically not a compelling need to join the two tables. The relationships are there for flexibility. Having the various hierarchy tables as stand-alone entities allows you to attach them to business tables at all of the levels you collect or report time values. These tables and hierarchy relationships allow you to easily merge data of different time grains.

The best thing about time is that time is constant. There are always sixty seconds to the minute, sixty minutes to the hour, twenty-four hours to the day (excluding Daylight Savings Time adjustments), seven days to the week, the number of days to the month is fixed, the number of days in a year is predictable. Except for adjustments to fiscal calendars and special events, most of the information related to time hierarchies is static.

BI uses these techniques to conform information allowing it to readily apply to many views of the business… which sounds a lot like the same business issues we try to solve when integrating data within an MDM solution.

Introducing a robust set of Master Time dimensions into an MDM architecture opens up flexibility in how you consolidate information and also how you can apply it to many business purposes. It’s a natural expansion of MDM to include a master version of the corporate calendar (particularly the fiscal calendar) using a common set of time-related identifiers complete with any time references relevant to business operations.

Please let us know what you think of mastering the Time dimension or other types of corporate reference data in the MDM hub by leaving a comment here.

Using a fictional company with lots of systems and applications issues, Thomas walked everyone through how Oracle would solve a lot of those problems.

There were some great customer cameos from companies like Ingersoll-Rand and Office Depot. It was a little on the sales-y side, as Oracle keynotes can sometimes be, but it was well done and wasn’t over the top.

This session was a good reminder of the breadth and depth of Oracle’s offerings in the technology and applications space, and frankly it made my head hurt. I’m glad that Hub Designs specializes in master data management – the Oracle universe has gotten so big, it’s a little overwhelming for most people.

I’ll write more later today on the MDM track sessions.

Editor’s Note: Another in the series of “MDM and …” guest posts by Joan Lawson, an enterprise architect who I’ve known since 2003.

For more details on Joan, please see her LinkedIn profile — Dan Power

There’s been a resurgence lately of writing about Operational Business Intelligence.

It’s a valuable concept. Operational BI gives people in the enterprise an up-to-date view of performance against the key metrics that drive the success of the organization, so they’re better informed and can more readily determine corrective actions when needed.

All the vendors and analysts identify success criteria to include Business Activity Monitoring (BAM) engines, business rules, and high end presentation capabilities.

But they’re missing the #1 criteria for success… high quality master data.

In Operational BI, the real time transactional data will most likely be sourced from two or more business applications.

The historical source of data, for comparison’s sake, can be the data warehouse.

But for the master data, where is the “source of truth”? If you’re going to fast track your business monitoring, be sure to include an architecture for real-time master data management to provide top quality dimensional data.

Please let us know your thoughts by commenting here or on the MDM Community on your experiences in using MDM in concert with Operational Business Intelligence.

The Oracle Business Intelligence Special Interest Group, which is part of the Oracle Applications User Group, is hosting Desktop Conference 2008, its annual online conference, in mid-November.  

Here’s a brief description: 

“Join the Oracle Business Intelligence community in the only global, online business intelligence conference that addresses business intelligence and data warehousing topics related to the Oracle technology stack.”

The SIG president, Faun deHenry of FMT Systems, asked me to do one of the keynote sessions. 

It’s titled “Master Data Management 101″ and will be covering: 

• what is Master Data Management (MDM)? 
• some useful MDM and Data Governance best practices
• what works and what doesn’t
• importance of a holistic approach to MDM
• how to get the political aspects right
• the relationship between MDM and Business Intelligence

The session will be held online on Wed. November 12th at 2:45 pm Eastern, 11:45 am Pacific. Click here to see the agenda and here to register.

If not Master Data Management, what? 

Enterprise Resource Planning (ERP) – the “back office” – has been around forever, and the “customer master” function in most ERPs is adequate, but due to acquisitions, many companies have more than one ERP system, and some companies let major business units build their own separate technology architecture. 

Customer Relationship Management (CRM) – the “front office” – was supposed to be a “silver bullet”, bringing businesses closer to their customers, delivering 1-to-1 marketing, and increasing sales. 

And data warehousing and business intelligence were supposed to deliver performance management and analytics, enabling better decision-making and deep analyses, but have sometimes proven to be difficult to deliver and extend. 

But to varying extents, all of the technologies failed to deliver on all of their promises. 

So circa 2004, along came Customer Data Integration (CDI) and Master Data Management (MDM). I call it the “hole in the donut”.  MDM takes information from source systems like CRM and ERP, and eventually passes it on to downstream applications like data warehousing and business intelligence. But a lot of magic happens in that “hole in the donut”. 

Information is consolidated into an MDM hub, usually using service-oriented architecture based integration technology. It’s cleansed using data quality software and completed or enriched with third party information.  And it’s managed by a data governance organization. For more details on the end-to-end MDM process, see our earlier post on the “Five Essential Elements of MDM“. 

So that would give you the Single View of the Customer (or Product, or Supplier, or whatever data domain you were mastering). 

And from there, most companies would, in fact, flow the consolidated / cleansed / completed information into a data warehouse or business intelligence application. 

But if your MDM hub is missing, and you don’t have the data governance organization or processes, all of the above is going to be much more difficult, if not impossible. 

Organizations are waking up to this, realizing that they’ve got “the donut” i.e. key pieces of the puzzle (plenty of source systems, decent integration technology, tons of third party data) but no data quality tools and no central MDM hub. 

If you want the Single View (the “whole donut”), you need to invest in those missing pieces.

I’m really looking forward to speaking at next week’s Decisions, Information and Governance conference in Las Vegas, sponsored by The Palladium Group.

And I spoke earlier this week at the New England Oracle SOA Users Group, talking about Master Data Management as a foundation for Service-Oriented Architecture.

MDM initiatives seem to be getting linked to Service-Oriented Architecture or to advanced analytics and business intelligence programs.

I think there can be a problem (but also an opportunity) for MDM in inserting itself between two things that used to talk directly from one to the other (an ERP system to a data warehouse) or (b) asserting itself as a predecessor task to ensure a better outcome (for example, when MDM is used to consolidate and improve the quality of enterprise data before people try to use it in analytics or business intelligence).

While I think it’s true that MDM is in fact needed at most large organizations, having to coordinate with an already-underway SOA initiative, or step back from a planned BI initiative and first tackle MDM, does complicate things a bit. So that’s the “problem” part.

The “opportunity” part is that, for organizations that have the foresight or the luck to tackle MDM first, it makes implementing SOA or achieving business intelligence success that much easier. There’s already a centralized repository of information on customers or products (or whatever domains have been mastered), and that information is proactively managed so that it’s trusted to be accurate, complete, timely and consistent.

Whichever situation your organization is in (tackling MDM first or building it into something else like SOA or advanced analytics), spend the time to develop a workable MDM strategy, using a holistic approach that addresses people, process, technology and information. By all means include an MDM hub in your planning, but make sure you also plan for business process management or sophisticated integration, as well as built-in or bolted-on data quality and enrichment capabilities. And be sure to build a data governance framework around your MDM initiative.

I’ll write a trip report after next week’s DIG conference, to let you know what I thought of the conference itself and whether I got lucky at the tables!