MDM in LED

Good article initiated by Henrik Liliendahl completed by the very good comment of John Owens. I decided to re-blog it in order to continue and complete it.                                                                                                                                                                                                                                                              As John Owens mentioned, “QUACKs (Quack Alternative Codes & Keys, also called Structured Codes) are a very useful way in business of referring to a frequently used entities, such as products, locations, etc.                                                                                                                                                                    The problems start when data analysts confuse them with Unique Identifiers and then system designers further compound this error by implementing these QUACKs as Primary Keys in tables. This embeds a flawed data structure into every single record that is created in which these flawed primary keys are used foreign keys, for example, in tables linking a flights to St Petersburg airport.                                                                                                                                                                                                                                                      Now, had the designers used an unstructured Primary Key and shown “LED” simply as a QUACK referencing the Leningrad/St Petersburg airport, the code “LED” could at any time have been very simply changed without in any negative impact on referential integrity in the data sets involved. All past and future flights would automatically reflect the change in the airport code.                                                                                                                       The reason the code LED is hard coded in this way is not an innate part of MDM, it is the result of bad data analysis and worse systems design. A major part of current MDM is to move the knowledge, practices and skills into enterprises to enable them to avoid to making these totally avoidable and hugely costly errors.”                                                                                                                                                                                                                                                                           All of us have faced this kind of problems, consciously or not. This can be a very big issue especially when having very tightly connected legacies. Such original mistakes can lead to decades of re-engineering, trying to decouple legacies in order to be able, later on to bring more flexibility. As you may notice, this is a 2 steps approach that does not bring any business value first – while decoupling – and might bring a Return Of Investment 3 or 5 years after the initiative has been started…                                                                                                                                This is the main reason why, most of these initiatives are never started!!                                                                                                                                                                                                                                                                                              Actually, the only cases I’ve seen such projects initiated – to try to correct the initial error – was due to an unique phenomenon called: “hit the roof”. “Hit the roof” is a side effect of mainframe developers usage, who most of the time were the same ones who did the initial error: “using the QUACKS as primary key”. “Hit the roof” is quite simple as well, after several decades of usage, some QUACKS table value reach the end of the range. We could take the previous example – the airport code based on 3 letters, with one assumption: only letters, no numbers. It gives you a total of: 13,824 possible airports, which might sounds reasonable if we think about the main airport, but which will be quickly reached as soon as you include the small aerodromes into the same table… I guess you saw me coming!! 🙂 I am not an airport specialist, but I am quite sure that some politicians will have this brilliant idea, one day or another – if it is not already done – to have a common repository (Table) for all airport and aerodrome of the world… Then, we will hit the roof!                                                                                                                                                                                                                                          Ok, very good that we “hit the roof” you should tell me, finally, it gives us the opportunity to correct the initial mistake… Well… I won’t be so optimistic if I were you, even though if I agree with the reasoning: having a golden opportunity to put things back into order… Most of the time, the “solution” that wins is the following: let’s introduce numbers in the 3 digits code that we got! Wouhou! Jackpot! We increase from 13,824 values to 39,304… And that will cost only 8 to 10 millions $ to the company!!! You think I’m joking, unfortunately I am not.                                                                                                                                                                                                                                                                 So, what to do then? To start with, the less silly solution is to create “Alias” to smoothly (can take years of continuous efforts, depending on how much your systems are “connected” to each others) move from the “QUACKS ID” that was initially set to a real (dummy) object ID (primary key). It is not the silver bullet that some might look for.. but it’s the only reasonable way forward I know about.                                                                                                                                                                                         Any experience to share on this topic?

Liliendahl on Data Quality

All airports have a tree letter code usually being a mnemonic of the city name or airport name. The airport at Saint Petersburg in Russia thus has the code LED because the code was assigned when the city was called LEningraD. That’s how it is with master data: Names may change but the code of an entity must be kept as it was. And that’s why you usually shouldn’t put meaning into codes.

First sight of Europe 2014.

The Russian MDM (Master Data Management) market has been well described by Dmitry Kovalchuk in a post on the Hub Design Magazine.

This year I had the pleasure of celebrating New Year in Saint Petersburg, a city with great palaces from the time of the czars and czarinas and a growing awareness of Master Data Management including some very interesting start-ups around MDM, where I had the chance to visit TaskData

View original post 19 more words

#InfoArch – Post 2. The starting point

As often, we needed to start somewhere. The main idea here was about “marking the starting point” and formalize it, in order to be able to come back and measure what has been achieved later on during the journey. So, as a starting point, we performed a survey, involving stakeholders across every different main organizations (or functions) of the enterprise. Here is an extract of the main outputs of this survey (snapshot taken at the beginning of the initiative).

 The diagnosis

As a general comment, up to now, no corporate structure existed for a business driven approach to manage Core information of the group (so called Master Data, see our definition) and their life-cycle cross different organisations, processes or functions.

Here is an extract of this survey, giving a rough picture of the perceived situation. Diagnosis of the starting point situation (2011):

• Some organizations (within the enterprise) did make impressive Master Data efforts within their area of responsibility, but, so far, nothing has been coordinated (across these organizations).
• Master Data are handled inside organizations, to be more specific, inside each and any IT applications. This practice leads to high complexity, redundancy and inconsistency. At the end of the day, such practice (let’s call it “silo practice”) has, of course, high IT cost impact.
• Information Management / MDM is not in focus as a discipline
• The existing IT Governance organization has a strong focus on solutions & infrastructure – NOT on MD Governance as discipline.
• No pro-active and commanding Portfolio Management (e.g.: Project Portfolio Management, Application Portfolio Management) taken a MD view in existing scope and approach.
• Lack of KPI´s and measures for Master Data discipline.
• Lack of Management focus on Master Data.
• Transformation’s roadblocks, due to problem with information harmonization, transparency & availability, exists to achieve the wishing Business Model.
• No enterprise standard is appointed (nor used) to document / communicate regarding the Master Data (e.g.:information models, class diagrams…).
• No organization exists to escalate MD issues and pain-points – who to call?
• Master Data issues are today a problem in many projects, and organizations across the enterprise.

Recommendations

• Master Data must be governed and managed through-out their entire life-cycles with joint responsibility by Business and IT – as a core asset.
• Governance of core Master Data entities used cross the whole enterprise must be established.
• The enterprise CIO is responsible to make it happen.
• Management of Master Data is to be established and treated as a discipline.
• Management of Common Master Data should focus on core business information entities that have highest degree of reuse and commonality across the enterprise and be based on demands from an end-to-end process view.
• Information Management/MDM must be addressed to Top Management as a core and strategic area for business & IT improvements
• Management of enterprise common information Entities must be considered as one key area of the Process & IT portfolio Management accross the whole enterprise.

Next post of the serie

Break the conventional thinking… coming soon. Stay tuned.

#InfoArch – Master Data – Short definition

Master Data is the core information, that is needed, to Manage and Operate the Company businesses. Master Data is a Core asset for Enterprise/Company. As such, it has to be Governed and Managed properly. Customer, Product, Supplier and Financial information entities are typical examples of some very essential Master Data. They need to have a common information structure & definitions, the right level of quality, accuracy and availability to enable the Enterprise/Company to achieve its strategic objectives such as Customer Satisfaction, Profitability and Operational excellence.

Considering Master Data should not avoid you to think about the real important topic: Information Management. Master data is only “the top of the iceberg”… but don’t we say:

To be able to succeed, one needs to start somewhere…

So why not starting by the core information? 😉 That was/is our choice from the beginning of this journey.