Courtesy of Screen Africa

MD at Master Data Management Gary Allemann has written the following opinion piece about data management and data cleansing. He writes: We meet with many IT teams that are trying to establish a data quality culture within their organisations. 

In most cases they share a common concern with us: "The business people aren't interested in solving data problems!" "We don't get buy in from senior management for data governance!" 

The axiom 'You can't see the wood for the trees' is apt when considering their approach to data management and data cleansing. They see so many issues caused by poor data that they assume that these will be obvious to everyone. So the problem that they are trying to address becomes 'poor data quality' - rather than the business issue (or issues) that the data is affecting.

This common mistake has resulted in business people questioning the business value of data management projects, with sometimes a lot of money being spent but ultimately they do not yield any results and are perceived to be pointless. This is more than often due to data management projects that are frequently driven by technologists who do not speak the 'business language'.

After all, data management is not about the data. It's about addressing the business issues caused by data and improving the business outcome. 

It is therefore vital to partner with a data management professional that understands the business language and how the technology can deliver results that can be linked back to business issues.

For example, a data person may ask for budget to 'improve address data quality', assuming that this is the business driver. After all, address inaccuracies are the cause of many business issues - ranging from returned mail, to the inability to trace and collect bad debts, to the increased risk associated with non-compliance. 

In each of these cases, the business driver is not better address data quality. A project that asks for budget to 'reduce overall debtor's days by x%', or to 'cut the volume of returned mail by y%", is far more likely to get attention, and budget, from business than a project intended to 'improve the accuracy of addresses'. 

This approach also focuses the attention of any implementation on the specific end goal, or goals, ensuring that unnecessary effort and money is not expended cleansing data for the sake of it. 

Of course, this approach can lead to duplication of effort. Do we need multiple projects, each with a different end goal all working on the same data? 

Pragmatic data governance assists to ensure that overlapping business goals are addressed by the same project, rather than having many tactical projects that may impact negatively on each other, or waste resources repeating a task that has been delivered by another project. 

Experience can help to link the business and IT goals creating that all important business buy in and support. 

Courtesy of Information Week

IT pros in infrastructure and security roles must craft a mobile device management plan that can change quickly along with technology. Forrester Research shares its advice on working together effectively.

Unlike the Windows-dominated PC market, the mobile device market has a cast of operators, manufacturers, and OEMs that are all part of the mobile ecosystem. There is also no shortage of mobile device management (MDM) vendors and solutions. As these MDM solutions swing from on-premises to cloud and managed services, we could see a shift in the relationship between mobile operators and enterprise IT.

Significant technological advances by any of the players in the mobile ecosystem can change your mobile strategy considerably. Your responsibility is to lay out an agile strategy while remaining mindful of ongoing upheaval. With this in mind, Forrester recommends that IT professionals in both infrastructure and operations (I&O) and security and risk (S&R) roles work together toward the following goals:

1. Develop mobile device management capabilities. Many I&O professionals have already invested in an MDM solution. This essential technology allows I&O professionals to support multiple platforms and form factors, extend management and security policies to both corporate-liable and employee-owned devices, and automate service desk support. This is especially important as I&O develops a  BYOD program to support the business needs and high expectations of an empowered workforce.

However, avoid investing in any monolithic infrastructure for the sole purpose of mobile operation and management. As much as possible, leverage services and technologies that are native to the platform and don't require a big footprint in your infrastructure. Also, avoid technologies that focus heavily on device management but provide little application- and data-level control.

2. Create a BYOD program and introduce a phased rollout for empowered workers. Unless you have extremely strict security and privacy requirements, it's more than likely you will need to support employee-owned devices in your organization. To do this, you will need to adopt the necessary MDM and mobile security tools, but you will also need to define a strong mobile policy that clearly outlines eligibility and access requirements, support options, and of course, who pays for what. In addition, any successful BYOD strategy must include self-service options for employees. Portals that allow employees to quickly onboard devices and download available corporate applications can remove significant amounts of support time for IT professionals.

However, the devices in your BYOD program shouldn't stop at mobile devices. Bring-your-own-PC, for instance, is just a small mental leap from bring-your-own-smartphone. For this reason, IT professionals should craft a strategy that focuses on the fundamental capabilities that enable bring-your-own-device, rather than the nuances of supporting  iOS and Android, for instance. Examples of fundamental technology choices and processes include universal NAC, an enterprise PKI (to enable certificate-based authentication for any device), virtual application delivery, and self-service.

3. Tier mobile device management based on applications and security risk. Instead of using a one-size-fits-all approach, tier device management based on applications and security risk. In a tiered model, employees eligible for company-owned devices might get a choice of  BlackBerry or iPhone devices running a full suite of business apps and intranet access, while employees in the BYOD tier can use approved iPhone and Android devices but might get access only to email, a VPN-enabled browser, and virtualized applications.

4. Plan for an enterprise app store. Forrester anticipates mobile application management and provisioning to emerge as a new technology category over the next 12 to 18 months. Adjacent to MDM, this area will support asset and software management, chargeback, service desk, and request fulfillment capabilities in addition to offering a multiplatform application catalog, mobile experience monitoring, and a billing engine.

While nascent offerings native within some MDM solutions--such as AirWatch, MobileIron, and  Zenprise--have begun to emerge over the past year, it will take another two to three years before IT professionals perceive this as mainstream "must-have" technology. This new management experience will push IT to adopt more self-service capabilities, move faster to embrace new technologies, and in essence deliver a more consumer-like experience to corporate users.

5. Anticipate the convergence of mobile device and PC management.  I&O professionals are still at least three to four years away from being able to effectively manage all endpoint form factors--including smartphones, desktops, laptops, tablets, ultrabooks, and netbooks--through a single pane of glass. Acquisitions and strategic partnerships and an eventual convergence of roles within I&O will drive more firms to explore this possibility.

We're also still years away from deep product convergence, although some MDM solutions technically support PCs and some PC/client management solutions support some mobile platforms. Which vendors will take ownership of this convergence remains to be seen. Your five-year IT roadmap might call for an investment in MDM today, but you might need to shift your investment to a PC management, a carrier-based managed service, or some combination of the two tomorrow.

6. Support a user-centric approach to mobility. As devices such as cameras, cars, home electronics, and even musical instruments come equipped with microprocessors, we will see devices increasingly become conduits for businesses to deliver services and engage customers. While the one constant in this increasingly diverse world is the user, the notion of a user is not one-dimensional, as typified by identities in a corporate directory. Rather, users will be contextual--IT systems will consider the access rights of a user dynamically, along with the device state, geographic location, and even which apps the user is accessing at a given moment.

To stay relevant, your enterprise must pursue a steadfast user-centric approach to mobile device management and security while embracing new peripherals and meeting new business use scenarios. This means you must shift your attention from devices to the user. As a result, your strategy will dictate technologies that exert control within the greater user context--at the app and data level--rather than on the underlying device.

Courtesy of IT Business Edge

It's a bit ironic, really. Master data management's biggest potential and biggest pitfall is the same thing: governance.

MDM involves integrating the data and ensuring it's right. To do that requires a certain amount of governance - finding out, for instance, which version is the "correct" version of data and who is "responsible for it."

But sadly, sometimes the governance work ends there, as if master data would somehow magically remain pristine and unchanged - a veritable "golden" copy of the record, locked in time and space.

That's why governance is quickly becoming a major focus for MDM projects and practitioners.

Or, as Aaron Zornes, a veteran IT consultant and the so-called godfather of MDM, put it during an interview with TechTarget:

You've got to do governance … Without governance, MDM is just data integration.

OK, fair enough. The problem, however, is getting someone to actually be responsible for governance. As far as I can tell, in this day and age, no one really wants to be responsible for anything, particularly if it will get them fired or sued. But beyond that, there's a more basic problem with governance, as a recent Information Management piece points out, and that's this: Who really owns the data?

It's a core governance question, and it tends to be interpreted in one of two ways:

1. The data owner is the person responsible for the data.
2. The data owner is the person who can give IT requirements so IT can do its job.

Both of these are flawed approaches to data governance, the piece points out.

In the first scenario, it's ridiculous to think the so-called data owner is always in possession of the data and will always know if it's right or wrong.

Take customer data, for instance: Your sales team may be the front line for receiving that data, but perhaps a call to customer service meant an update to a customer's address. Who owns that data? "How can such an 'owner' of customer data always be expected to know if the data is right or wrong?" the article asks.

The second is just a misappropriation of the term, substituting for "business sponsor," the piece contends.

All of which leaves the core question unanswered: Who owns the data?

There's only one person who truly owns the data and always knows if it's right or wrong, the piece argues, and that's the customer. It's so obvious, and yet it's a point that's nearly universally overlooked when we talk about data governance.

The post doesn't offer any real options for how that translates into fixing master data or data governance but that doesn't make the point any less true or avoidable.

Who knows - perhaps this is where social master data management will find its use case. But I think it's an honest observation that makes a very real point about why governance is so gosh-darn hard.

Courtesy of Information Management

In a keynote at our  MDM & Data Governance conference in Toronto a few days ago, an executive from a large analytical software company said something interesting that stuck with me. I am paraphrasing from memory, but it was very much to the effect of, "Sometimes it's better to have everyone agreeing on numbers that aren't entirely accurate than having everyone off doing their own numbers."

Let that sink in for a moment.

After I did, the very idea of this comment struck me at a few levels. It might have the same effect on you.

In one sense, admitting there is an acceptable level of shared inaccuracy is anathema to the way we like to describe data governance. It was especially so at a MDM-centric conference where people are pretty single-minded about what constitutes "truth."

As a decision support philosophy, it wouldn't fly at a health care conference.

The flip side is that this statement also happens to be a pretty honest admission of the way people get things done collaboratively - and the downside that might come from a metric defined elsewhere that can affect broad parts of an organization.

It's acknowledging in part what Boris Evelson was  saying last week about IT reconsidering its control philosophy, and also about what's been said about the boundaries of governance.

It's not necessarily an attribute of data to be right or wrong; often, data just is what it is. But how do we live with decisions formed from conclusions where the numbers we use are not numbers we've agreed to?

I couldn't wait to bring the topic up later that day in a panel I was hosting on data governance where I had a couple of real veterans,  Ed Unrau from Canadian Tire and Chai Lam from Bank of Montreal to help me lay out the problem.

Ed said the question is a challenge of true enterprise data management, but he bisected what we were talking about, correctly I think.

"I distinguish data from information so we can talk on one hand about masterdata management, but you can also think of the reporting that comes from that data and call that information and information governance," he said. "Let's say we want to be more customer centric, we've created this repository of data and really smart people analyze it, but if we have three different customer segmentations and different versions of how many customers we have going up or down in a region, that is going to be a big problem for the entire customer centric strategy."

That implies guardrails, the rights and ownership at the heart of governance - and governance is something Ed said should be about enabling and not restricting widespread data use. What you want, I figured, is optimum use of the data and you probably do that by summoning the least inconsistency you can muster.

Ed picked up on that, preferring the word "inconsistency" to "incorrect," and reminding us that you don't want to restrict data in absolute terms for the sake of either word. In a compromised world where things are always going to be damaged overall, "in some cases you can react to consistently incorrect information, you know where to steer and what to do. If you instead have inconsistent information all over the place, VPs throwing different numbers back and forth about whose fault something is, that is a big problem."

It was a little bit liberating to hear this in a crowd of people who, in their role of advocating governance, are usually out to think in terms of things that are either acceptable or unacceptable.

Chai Lam from Bank of Montreal  picked up on the small versus enterprise theme. "If your organization believes in governing a set of data in a line of business and that is where executive sponsorship is going, there is no mandate to make it enterprise. You know IT is there to enable them, but you have to make sure you have a sponsor in your line who mandates the scope."

His larger point was about stewardship as well as governance and that they are not the same thing. "Governance is all about policy and standards. Stewardship is the operationalizing of all these policies and standards on a day to day basis. Somebody has to look at the data and say, 'I have two duplicate profiles, who makes the decision to collapse them?  What are the right business rules to apply and clean it up?.'"

At one point, the discussion took a technical turn into data extensions, and Ed replied to a comment to say, "That is such an IT answer!" 

And that's the point, Chai said. "You have to have the business processes and the organization and the people to do stewardship work and it's not IT work, it's up to business to operationalize this. You can't have governance without stewardship."

There it was. We'd accepted the frailty of a single version of truth at, of all places, an MDM conference.

People have to have confidence in foundational data, even if we're not defining it as right or wrong. Different consumers of data will have different ideas about rules. They will suffer or benefit more or less based on the consistency of the data because we all live with imperfect and inconsistent data and don't usually get to define all of it.

An audience member had the last word: "Ideally you want to get it right, but if everybody is held to a single source and they don't feel it's right, they are going to walk away and do whatever they think needs to be done."

As one of our 2012 25 Top Information Managers  reminded me recently, humility really does qualify as a leadership skill.

Courtesy of Information Management

The problems of master data management sometimes seem to be intractable.

It is difficult to keep master data synchronized with business reality, deduplication of records that exist for the same entity instance is a perennial issue, and the quality of non-key data attributes often cannot be determined with certainty. The traditional MDM paradigm has been to take data produced in transaction applications and try to automate its integration and cleansing.  Such "transaction adaptation hubs" have brought the promise of  clever algorithms that could do all the work to arrive at a single golden record for master data.

Alas, this has not turned out to be so. The algorithms in traditional MDM hubs have done well, but in many cases, they have not done well enough.  One response has been to add functionality to these hubs that permits data stewards to detect and correct data.  However, this creates additional issues, such as when data is not corrected synchronously in the corresponding upstream transaction applications.

Another approach has been to separate the production of master data from its distribution.  Central hubs remain for distribution purposes, but master data is created in specialized environments. The specialized environments are like farms where crops of master data are grown, and the hubs akin to markets, where the master data is taken after it is production-ready.  This pattern works reasonably well when the master data is about specialized, high value entities, such as institutional clients in brokerage businesses.  However, there can still be problems, such as failing to detect changes in attribute values. This approach is also very difficult to scale when there many entity instances to be mastered, such as in retail banking.

Who Owns the Data?

Once we recognize the problems in the traditional approaches to MDM, what can we do about them?  First of all, we have to ensure that data quality is high when it is first captured by the enterprise. However, are we taking this idea far enough?

Let us ask a question about customer data: Who owns it?  If I ask an IT person, he or she will likely identify one or more business users. But this is a problem.  To the IT mindset, "data owner" typically means one or both of two things:

(a) A data owner is someone who has some form of governance responsibility for the data.  It is almost never explicitly stated what such responsibility involves.  "Owner" is an analogy; the "owner" is expected to look after the data as if he or she was in possession of it.  However, such an expectation is often unrealistic. How can such an "owner" of customer data always be expected to know if the data is right or wrong?

(b) A data owner is somebody who can give IT requirements so that IT can do their job. In other words, in data-centric development projects, "data owner" is a mere substitution for the "business sponsor" in the old systems development lifecycle. 

Let us ask the question again: Who really owns customer data?  We propose that, in reality, each customer owns it - not any one person in the enterprise. If we truly subscribe to this viewpoint, it has profound implications for MDM.

Data Owner Driven Architecture and Governance

Many data managers might think this is fairly obvious, and it is.  Who knows the customer's basic information better than the customer themselves?  Who finds out earlier about changes to this information than the customer involved in said changes? Yet, if it is so obvious, why do our MDM architecture and governance processes seem to be based off of different paradigms? MDM hubs that capture data from transaction applications are not capturing data directly from the customer. By definition, these hubs cannot be updated with customer data unless the customer is involved in the transaction.

More importantly, especially in light of evolving laws about data management, who "owns" the information about a customer, if not the customer themselves? Surely, Malcolm Chisholm owns the information about Malcolm Chisholm and Fabio Corzo owns the information about Fabio Corzo.  And if it is true that a customer owns his or her own information, what does this mean, in terms of how an enterprise should treat a customer?   Furthermore, with ownership, comes responsibility.  What are the individual customer's responsibilities when it comes to their own information?

Clearly some of these issues will take many years to sort out.  In the meantime, enterprises can begin to consider what it might mean to their MDM architecture and governance processes, if they were to take seriously the idea that customers are the true owners of their own data.

If this were an accepted idea, it is difficult to see how the implementation of a transaction adaptation hub would apply this principle.  An enterprise would want to find ways to get as close to the customer as possible, in terms of customer data management.  If a customer was able to directly manage their data, there would be no need for probabilistic trust and survivorship rules.  Why should users not be able to provide demographic information about themselves, or update life events directly?

Current State and Looking Forward

Many enterprises reason that traditional architecture and governance approaches are the best approach, given the decades of organic growth in data architecture. But why?  The growth of the Internet and the rise of social media have brought people into direct contact with enterprises, in terms of data, and have shown that individuals are quite willing to maintain their own profiles.  Of course, there are issues to be worked out; people are not always accurate in describing themselves and may be sloppy in the way they maintain their personal data. However, this overall approach is superior to what we have today.

We have focused on the example of customer data here, but this concept can be applied to other master data subjects. Find the true owner of the data, rather than the owner of a data store, let them manage the master data and adjust architecture and governance to fit this approach.