Friday, 22 August 2014
Tuesday, 19 August 2014
When is "good enough" good enough in Information Management?
A recent article from Image and Data Magazine offered some ideas on achieving "best practice" Information Management. The advice offered in the article is well given and it raises some important points, through the lens of a Records Management/compliance-based agenda.
What the article didn't ask was whether "best practice" is actually required in the first place, or whether "good enough" is good enough. What does "fit for purpose Information Management" really mean?
And of course, that got me thinking...
First off, I'd offer that unless you understand what "best practice" really looks like, then you're not really in a position to assess how to deliver "fit for purpose!" Conscious competence is what we're generally aiming for, and the route to achieve that will depend upon the starting competency levels within the business community (as I discussed in my post from the very start of this year.)
Another challenge is that best-practice Information Management is a complex and inter-disciplined set of capabilities that many struggle to fully comprehend. It therefore becomes difficult to engage with the business community (and indeed IT teams), because they typically want immediate results, whereas IM requires a holistic change to develop a range on foundational competencies (see my Information Management Tube Map for a view on how these competencies inter-relate.).
Bottom-up, localised initiatives CAN deliver value, however. Indeed sometimes, they're the only way to achieve any progress at all. This will often depend on cultural and societal conditions within the organisation and in some cases, it can actually be counter-productive to embark upon a major, centralised initiative. (See my discussion paper on Distributed Data Quality for more on this.)
Finally, I'm not convinced at all that a Records/compliance-based approach is going to pay dividends either. Quite frankly, it's boring and most business people aren't interested in discussing risks! Seeking out new value opportunities and delivering a real business outcome will stimulate interest and engage a business community. Once there is momentum, then you can choose which practices you want to develop, as well as establishing a level of robustness into the overall process.
Whenever he'd finish an odd-job around the house, my grandad regularly used to say, "Neat but not gaudy, as the monkey said when it painted the piano green."* When I was a child, I had not the faintest idea what the bloody hell he was on about.
Thirty five years later, I understand that he was making perfect sense all along...
*Other sources offer a slightly different usage of the phrase, amounting to the same thing. And yes, I know that's an ape, not a monkey. So sue me!
Monday, 11 August 2014
A few posts back, I called out Forrester Research for propagating a technology-centric approach to Master Data Management (MDM). Today, it's Gartner's turn to be on the receiving end of my irascibility.
This video segment titled "Information Governance, buy now or pay later", was posted to BitPipe.com by storage vendor CommVault, and features commentary by Gartner analyst Alan Dayley, who starts out by broadly describing his view of what "Information Governance" is. (I might quibble with small elements of what he says, but I'll let that go). However, he then immediately goes on to describe the issues and rationale for better and more disciplined data storage.
Now it's bad enough that as an industry, we're guilty of having multiple terminologies for the same thing. This leads to confusion at best, obfuscation at worst. It's the Information Management equivalent of struggling about whether to to call something a spade or a shovel. And it's even worse that we see vendor companies actively inventing (ugly) new language to try and give the impression that what they're doing is fresh, innovative and exciting. (I'm accusing both product vendors and systems integrator/consulting services business here!) Whereas more often that not, they're just re-badging existing ideas to fit with the latest round of Bullshit Bingo hype. "Manually operated excavation device", anyone?
It's this sort of thing that's given us Decision Support System (DSS), Management Information System (MIS), Business Performance Measurement (BPM), Business Performance Management (BPM), Business Intelligence (BI), Operational Intelligence (OI), Online Analytical Processing (OLAP), Business Optimisation and Analytics (BOA), "Big Data" etc. All, effectively, describing the same damned thing.
But to my mind, what is going on in this Gartner/CommVault commentary is something even more pernicious and potentially disingenuous. This is a classic example of "bait and switch" language use that is all too prevalent within our industry; the new, exciting capability (in this case "Information Governance") becomes a bandwagon used to to re-badge products from a completely different domain (such as CommVault's backup & storage tools).
Gartner/CommVault have started out describing a spade/shovel, and then gone on to try and sell you a skip.
If the segment had been called "Data Storage Management, buy now or pay later," then I wouldn't have an issue (although data storage isn't at all exciting or vibrant, is it?!) And in any event, I can see why a product vendor like CommVault might want to do this - buyer beware, says I.
But for a Gartner analyst to not only buy into, but propagate such muddle-headed thinking just isn't good enough in my view. We all look to the "Big-A" Analyst and Market Research firms like Garter, Forrester and IDC to provide guidance which clarifies and helps navigate this mess, not add to it. (I'm being generous and allowing that this is merely poor form, rather than something altogether more clandestine...) That requires more rigour, more care, more thought. Fast-and-loose with language doesn't do anyone any favours and vendors, integrators, IT departments and end-users all end up losing out.
It's an uphill task, I have no doubt!
Friday, 8 August 2014
Thursday, 7 August 2014
I recently happened upon this post by Stibo Systems, offering five 'C's of Master Data Management: “Case”, “Content”, “Connecting”, “Cleansing”, “Controlling”.
In some respects I can't really fault any of the issues highlighted by Stibo - they certainly all need to be addressed as part of any successful MDM implementation. But yet again, we have a product vendor offering a very technology-centric point of view. Maybe not surprising, but still disappointing and frustrating in equal measure.
As I suggested in an earlier, post, it almost entirely ignores the human and societal factors of organisation, culture, process and human skills that will either make or break an MDM programme. One could possibly argue that these challenges are the prerogative of Data Governance, rather than MDM per se, so while I’d normally counter that the two are so inextricably linked as to make the distinction moot, I’ll go with it….
In the spirit of working together, and to complement Stibo’s suggested list, I’d like to propose my own "five 'C's for Data Governance”, which I think underpin the behavioural transformations that we’re aiming for with evidence-based decision-making:
Communicate: A common lexicon is foundational. People need to talk to each other and understand each other. We all achieve more if we understand what others are doing, if they understand what we’re doing, and how our own tasks fit into the wider organizational context. It is not always necessarily for them to agree, but any differences in interpretation of data terms need to be explicitly identified and mindfully handled.
Co-operate: no man is an island. Our work and the actions that we take will have an impact on those around us. At the very least, we shouldn’t be getting in each others way – we work for the same organization, after all! If there is data being generated within one department, then it needs to be made available to any other team who also can make use of it. To paraphrase my astute colleague and friend Meghan Vesey, “the attitude of POIM* is unacceptable and is not to be tolerated”.
(* “Piss Off It’s Mine”)
Collaborate: “Better together” is the current phrase being used within the “No” campaign for the Scottish independence referendum. Now, I’m not intending to get into the whys-and-wherefores of the Scottish independence debate. (As a Scot in exile, I don’t get to vote in the referendum anyway! For the sake of balance, here is the link to the "Yes" Campaign.) But I think the phrase neatly summarises a mindset where we go beyond simple co-existent tolerance and start proactively working together for shared benefit. Group-think can be a powerful enabler (as long as it doesn’t become just a gab-fest). Focus on action, target an outcome.
Cajole: This could also have been “Coach”, but I went for cajole a) because it’s an under-used word and b) it conveys a sense of proactive encouragement, rather than simply providing support when it is wanted. We all need a catalyst every now and again to get us away from complacency and towards creativity (More 'C' words!). Giving each other a shake up every now and again can be helpful – innovation comes from being pushed. Do this for each other on a regular basis, and the benefit is mutual.
Coerce: Yes, I’m going there. I am advocating that on occasion, you will need to manipulate people and bend them to your will. It’s a tool of last resort, but a carefully applied element of compulsion can break a deadlock, whether it’s in the form of a new policy, an applied standard, a new mandate or just simply an instruction to act in a particular way. Threats can be handy too, as long as you’re prepared to follow through! Force the issue, change the behaviour, drive the action, get a result.
Are there any other “C” words that I’ve missed? (Keep it clean please...!)
Wednesday, 30 July 2014
A recent thread on LinkedIn raised the issue of implementing a business glossary (in particular relation to using IBM’s Business Glossary tool).
I generally try to avoid commenting on any particular vendor’s products in this blog – as regular readers will know, I’m much more concerned with all the joys and frustration of the human aspects of Information Management! However, the LinkedIn discussion raised some interesting questions on the topic of “business glossaries” and metadata management more generally, and I think these are worth exploring and summarising.
The first thing to note is that the key issues of successful business glossary implementation aren't related to the technical deployment of the tool anyway. As with all Information Management capabilities, they are cultural, societal, behavioural, process - i.e. human challenges (that is true whether you are dealing with data quality, master data management, Information Asset Management etc.). The overall approach to Data Management and Governance needs to be given due consideration - who is responsible for data definitions and business rules, who has the decision rights, how do the definitions get maintained, management and published etc.)
The key purpose of a “business glossary” is that of human communication and collaboration – to exchange business-level understanding and interpretation of informational terms. A business glossary (sometimes referred to as "business dictionary", “business metadata”, “business vocabulary” or “business lexicon”) collects terminology that expresses business concepts in the language of the end-user, with the aim of collating one consistent set of terms that are commonly understood by the user community. That’s hard enough!)
Getting people to agree on words & definitions is difficult. Unfortunately life isn't that clean cut. Even just collecting as many words/terms/phrases/acronyms as you can grab and examining the different uses/definitions/conflicts can be time consuming.
When I was at UNSW we ended up collecting over 1500 terms, which one way or other resolved to about 400 groupable items (e.g. there were six different ways of establishing whether or not we counted someone as a "student").
Resolving all of those contentions, discrepancies and ambiguities in one go was way too hard for most people to get their head around, let alone show any interest!) So we focussed on one subject area - in this case, Staff/HR data definitions - which was a high priority as we were in the process of re-implementing our HR admin system.
One common question that was asked very often was “How many staff do we have?” This invariably led to much wailing and gnashing of teeth as people scurried around, frantically trying to answer the question, only to come up with multiple different answers, none of which corresponded with any other answer.
Of course, the challenge was that there was no agreed understanding of what anyone meant by “How many”, “staff” and “have”!
At UNSW, we had a working party of 5 full-time team members, supported by a part-time stakeholder group of approximately 30 nominated business representatives. (For some comments about the "consultation culture" at the university, see my interview for DataQualityPro.)
We settled upon approximately 80 agreeable terms, which also included some significant re-thinking of business concepts in some cases e.g. we had to split the generic and idea of someone having "contract" into the concepts of "employment status" (permanent vs temporary), "employment type" (fully employed vs fixed term vs contract vs casual), "payment arrangement" (paid vs emeritus vs conjoint/volunteer) etc.
Just for the "Staff/HR" subject area, it took over six months to get the definition of terms resolved. We than had to start on the process of cleaning the actual data, ready for migration to the new system... Whatever you're doing, patience is a virtue!
It’s also worth noting that the issues of identifying, validating and communicating this common business language are very different from (though related to) the more detailed questions of data modelling, integration, traceability, integrity and auditability enforcement which might be considered the realm “technical metadata” (and I’m using the word “technical” very advisedly here to mean any aspect of metadata management that isn’t immediately end-user facing!)
By the way, I’m not suggesting that “business metadata” and “technical metadata” are separate – indeed, it’s vital that they integrate and correlate to/down and bottom/up. Together, these will form the core body of knowledge that defines the existence of the organization. However, in order to make things manageable, it is useful to think of them as different views of the same thing, dependent upon role and purpose.
In my experience, if you want to be successful in implementing an Information Management environment, it is absolutely vital to address the human, cultural and societal factors that make for a successful outcome. Build organisational capability and resilience for Information Management as a set of foundational disciplines. Think about the accountabilities, responsibilities and process controls that are required.
Hint - Enter into a project naively, and you will fail. don't buy the tools unless you are prepared to deal with the human factors.