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?
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.
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
So, you’re busy working away at your models. The team is busy discussing the nitty, gritty things around taxonomies and ontologies. Others are creating detailed elaborations of different aspects of one of the dimensions of your enterprise architecture. You look at the work and say, “Damn this is good stuff!”
So now what?
The art of Enterprise Architecture is about influencing the stakeholders inside and outside of our organization that an EA will help them be more successful. How will they find out if we don’t tell them?
On the surface, this is really pretty 101 stuff. It really boils down to really answering the Who, What, When, Where, Why and How questions. I always start with Who.
Who do I want to communicate with and Why should they care anything about what the EA team has to say? That means that you need to take the time to know and…
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).
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.
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.
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.
Within all major industries — including automotive, banking, healthcare, energy, telecommunications, insurance, and government— organizations from around the world are beginning to understand the importance and tremendous value associated with ensuring the accuracy, consistency, and timeliness of their own information.
To this end, companies are gaining a better appreciation for Enterprise Information Management and its related Governance. Hence, the need to adopt information governance principles and rules across the enterprise became mandatory.
As a matter of fact, Information as an asset has to be governed and managed as any other enterprise asset is. Until information is not properly governed and managed, Information has no chance to fulfill its potential added value across the whole enterprise’s organization. In other words: there can be billions more spent on “exploiting” data, buying Business Intelligence tools, doing “Big Data” extraction and statistics, replicating data many times in many places. All these effort and spending are wasted money unless you know what you want to achieve, what you want to exploit, where is the trustable source, and what is value will it bring for you and your company.
The MDM – Master Data Management – apparatus (it’s a lot more than just technologies) is a fundamental component to guarantee that an enterprise architecture is translated to an efficient IT system. Moreover, without valid Master Data vision set and implemented, an enterprise architecture may be a complete failure and a total waste of money. The Information Governance Framework aims to establish the foundations for a company to govern and operate Information produced and transformed across the full extended enterprise.
Enterprise Information Management (EIM)
Enterprise Information Management (EIM) is an integrative discipline for structuring, describing and governing information assets to:
enable business insight
improve operational efficiency
Information may be structured or unstructured. Master Data and Master Reference Data are structured information, which is in the heart of transactional processes and operations as well as analytics.
Enterprise: Information Management (EIM):
The discipline that governs manages and operates IAM. EIM manages enterprise information asset to support the business and improve value. EIM manages the plans, policies, principles, frameworks, technologies, organizations, people and processes in an enterprise toward the goal of maximizing the investment in data and content.
Information Asset Management (IAM): the philosophy of managing enterprise data, information and content as an asset in the business accounting sense. IAM describes philosophies to ensure that data, information and content are all treated as assets in the true business and accounting sense, avoiding increased risk and cost due to data and content misuse, poor handling or exposure to regulatory scrutiny.
Einstein is quoted as having said that if he had one hour to save the world he would spend fifty-five minutes defining the problem and only five minutes finding the solution.
This quote does illustrate an important point: before jumping right into solving a problem, we should step back and invest time and effort to improve our understanding of it. Here are 10 strategies you can use to see problems from many different perspectives and master what is the most important step in problem solving: clearly defining the problem in the first place!
The Problem Is To Know What the Problem Is
The definition of the problem will be the focal point of all your problem-solving efforts. As such, it makes sense to devote as much attention and dedication to problem definition as possible. What usually happens is that as soon as we have a problem to work on we’re so eager to get to solutions that we neglect spending any time refining it.
What most of us don’t realize — and what supposedly Einstein might have been alluding to — is that the quality of the solutions we come up with will be in direct proportion to the quality of the description of the problem we’re trying to solve. Not only will your solutions be more abundant and of higher quality, but they’ll be achieved much, much more easily. Most importantly, you’ll have the confidence to be tackling a worthwhile problem.
Problem Definition Tools and Strategies
The good news is that getting different perspectives and angles in order to clearly define a problem is a skill that can be learned and developed. As such, there are many strategies you can use to perfect it. Here are the most effective ones I know.
1. Rephrase the Problem
When a Toyota executive asked employees to brainstorm “ways to increase their productivity”, all he got back were blank stares. When he rephrased his request as “ways to make their jobs easier”, he could barely keep up with the amount of suggestions.
Words carry strong implicit meaning and, as such, play a major role in how we perceive a problem. In the example above, “be productive” might seem like a sacrifice you’re doing for the company, while “make your job easier” may be more like something you’re doing for your own benefit, but from which the company also benefits. In the end, the problem is still the same, but the feelings — and the points of view — associated with each of them are vastly different.
Play freely with the problem statement, rewording it several times. For a methodical approach, take single words and substitute variations. ‘Increase sales’? Try replacing ‘increase’ with ‘attract’, ‘develop’, ‘extend’, ‘repeat’ and see how your perception of the problem changes. A rich vocabulary plays an important role here, so you may want to use a thesaurus or develop your vocabulary.
2. Expose and Challenge Assumptions
Every problem — no matter how apparently simple it may be — comes with a long list of assumptions attached. Many of these assumptions may be inaccurate and could make your problem statement inadequate or even misguided.
The first step to get rid of bad assumptions is to make them explicit. Write a list and expose as many assumptions as you can — especially those that may seem the most obvious and ‘untouchable’.
That, in itself, brings more clarity to the problem at hand. But go further and test each assumption for validity: think in ways that they might not be valid and what could happen if that was the case. What you will find may surprise you: that many of those bad assumptions are self-imposed — with just a bit of scrutiny you are able to safely drop them.
For example, suppose you’re about to enter the restaurant business. One of your assumptions might be ‘restaurants have a menu’. While such an assumption may seem true at first, try challenging it and maybe you’ll find some very interesting business models (such as one restaurant in which customers bring dish ideas for the chef to cook, for example).
3.1 Chunk Up
Each problem is a small piece of a greater problem. In the same way that you can explore a problem laterally — such as by playing with words or challenging assumptions — you can also explore it at different “altitudes”.
If you feel you’re overwhelmed with details or looking at a problem too narrowly, look at it from a more general perspective. In order to make your problem more general, ask questions such as: “What’s this a part of?”, “What’s this an example of?” or “What’s the intention behind this?”.
Another approach that helps a lot in getting a more general view of a problem is replacing words in the problem statement with hypernyms. Hypernyms are words that have a broader meaning than the given word. (For example, a hypernym of ‘car’ is ‘vehicle’). A great, free tool for finding hypernyms for a given word is WordNet (just search for a word and click on the ‘S:’ label before the word definitions).
3.2 Chunk Down
If each problem is part of a greater problem, it also means that each problem is composed of many smaller problems. It turns out that decomposing a problem in many smaller problems — each of them more specific than the original — can also provide greater insights about it.
“Chunking the problem down” (making it more specific) is especially useful if you find the problem overwhelming or daunting.
Some of the typical questions you can ask to make a problem more specific are: “What are parts of this?” or “What are examples of this?”.
Just as in “chunking up”, word substitution can also come to great use here. The class of words that are useful here are hyponyms: words that are stricter in meaning than the given one. (E.g. two hyponyms of ‘car’ are ‘minivan’ and ‘limousine’). WordNet can also help you finding hyponyms.
4. Find Multiple Perspectives
Before rushing to solve a problem, always make sure you look at it from different perspectives. Looking at it with different eyes is a great way to have instant insight on new, overlooked directions.
For example, if you own a business and are trying to ‘increase sales’, try to view this problem from the point of view of, say, a customer. For example, from the customer’s viewpoint, this may be a matter of adding features to your product that one would be willing to pay more for.
Rewrite your problem statement many times, each time using one of these different perspectives. How would your competition see this problem? Your employees? Your mom?
Also, imagine how people in various roles would frame the problem. How would a politician see it? A college professor? A nun? Try to find the differences and similarities on how the different roles would deal with your problem.
5. Use Effective Language Constructs
There isn’t a one-size-fits-all formula for properly crafting the perfect problem statement, but there are some language constructs that always help making it more effective:
Assume a myriad of solutions. An excellent way to start a problem statement is: “In what ways might I…”. This expression is much superior to “How can I…” as it hints that there’s a multitude of solutions, and not just one — or maybe none. As simple as this sounds, the feeling of expectancy helps your brain find solutions.
Make it positive. Negative sentences require a lot more cognitive power to process and may slow you down — or even derail your train of thought. Positive statements also help you find the real goal behind the problem and, as such, are much more motivating. For example: instead of finding ways to ‘quit smoking’, you may find that ‘increase your energy’, ‘live longer’ and others are much more worthwhile goals.
Frame your problem in the form of a question. Our brain loves questions. If the question is powerful and engaging, our brains will do everything within their reach to answer it. We just can’t help it: Our brains will start working on the problem immediately and keep working in the background, even when we’re not aware of it.
If you’re still stuck, consider using the following formula for phrasing your problem statement: “In what ways (action) (object) (qualifier) (end result)?”
Example: In what ways might I package (action) my book (object) more attractively (qualifier) so people will buy more of it (end result)?
6. Make It Engaging
In addition to using effective language constructs, it’s important to come up with a problem statement that truly excites you so you’re in the best frame of mind for creatively tackling the problem. If the problem looks too dull for you, invest the time adding vigor to it while still keeping it genuine. Make it enticing. Your brain will thank (and reward) you later.
One thing is to ‘increase sales’ (boring), another one is ‘wow your customers’. One thing is ‘to create a personal development blog’, another completely different is to ‘empower readers to live fully’.
7. Reverse the Problem
One trick that usually helps when you’re stuck with a problem is turning it on its head.
If you want to win, find out what would make you lose. If you are struggling finding ways to ‘increase sales’, find ways to decrease them instead. Then, all you need to do is reverse your answers. ‘Make more sales calls’ may seem an evident way of increasing sales, but sometimes we only see these ‘obvious’ answers when we look at the problem from an opposite direction.
This seemingly convoluted method may not seem intuitive at first, but turning a problem on its head can uncover rather obvious solutions to the original problem.
8. Gather Facts
Investigate causes and circumstances of the problem. Probe details about it — such as its origins and causes. Especially if you have a problem that’s too vague, investigating facts is usually more productive than trying to solve it right away.
If, for example, the problem stated by your spouse is “You never listen to me”, the solution is not obvious. However, if the statement is “You don’t make enough eye contact when I’m talking to you,” then the solution is obvious and you can skip brainstorming altogether. (You’ll still need to work on the implementation, though!)
Ask yourself questions about the problem. What is not known about it? Can you draw a diagram of the problem? What are the problem boundaries? Be curious. Ask questions and gather facts. It is said that a well-defined problem is halfway to being solved: I would add that a perfectly-defined problem is not a problem anymore.
9. Problem-Solve Your Problem Statement
I know I risk getting into an infinite loop here, but as you may have noticed, getting the right perspective of a problem is, well, a problem in itself. As such, feel free to use any creative thinking technique you know to help. There are plenty to choose from:
You may want to give yourself an Idea Quota – committing to have a predetermined number of ideas – of problem statements. Or write a List of 100 problems to solve. SCAMPER your problem definition. These are just some of dozen techniques you can try.
As a conclusion (for today)…
Of course, how much effort you invest in defining the problem in contrast to how much effort you invest in solving your actual problem is a hard balance to achieve, though one which is attainable with practice.
Personally, I don’t think that 55 minutes of defining a problem versus 5 minutes acting on it, is usually a good proportion. The point is that we must be aware of how important problem defining is and correct our tendency to spend too little time on it.
In fact, when you start paying more attention to how you define your problems, you’ll probably find that it is usually much harder than solving them. But you’ll also find that the payoff is well worth the effort.