The Rise of the Chief AI Officer: A Strategic Imperative for Data-Driven Leadership

 

As we stand on the precipice of a new digital dawn, the role of the Chief AI Officer (CAIO) emerges as a beacon of innovation. This role is not just another title in the executive suite; it is a clarion call for a transformative approach to leadership in the age of artificial intelligence. The CAIO is envisioned not as an isolated figure but as a unifying force, seamlessly integrating into the very core of an organisation’s strategy.

 

Hold on there! I didn’t write that, AI did. Sounds compelling though, doesn’t it? Either that or it sounds like the first paragraph of a novel in which our hero, CAIO, saves the day.

Image generated with AI, August 25 2024 at 6.19pm

I came across this article (The Changing C-Suite: Chief AI Officer In, Chief Diversity Officer Out (itprotoday.com)) which put forward different points of view about the potential for the emergence of a Chief AI Officer and where the role might fit within the broader C-Suite. It got me thinking and I dropped a few quick thoughts on LinkedIn.  Now that I’ve mulled some more and my friendly Co-Pilot has grabbed your attention with his (its?) prose, here’s a little more reflection…. (This bit actually written by a human!)

 

The corporate world is abuzz right now with the potential of artificial intelligence and the lure of its promise to redefine the boundaries of innovation and efficiency. But the success of AI, to my way of thinking at least, in many cases can’t be separated from the quality of the data that fuels it. Well-managed, accurate, trusted and understood data is the cornerstone upon which AI systems should be built. Without this critical foundation, AI projects are at risk of underperforming, leaving a chasm between the expected value and what’s actually delivered.

 

Beyond the Silo: The Collaborative Paradigm for Sustainable AI Integration

I’d suggest that if Chief AI Officers do appear as a mainstream role, the successful amongst them will be those who embraced (and were allowed to embrace) the multifaceted nature of the role. A leader who is solely focused on AI and what it can do for the organisation isn’t setup for success. He or she is potentially isolated from key enablers. At best, isolated in their own process, they lack the influence to attract the necessary consideration and support from others. At worst, they’re blind to the things that could erode the value AI brings or cause serious organisational harm springing from an unseen implication or missed consideration.  Without an holistic view of the organisation’s data and all its nuances, they may well find themselves at a disadvantage. This narrow focus can lead to a short-sighted approach chasing quick perceived value, but potentially overlooking the broader implications on risk and governance.

A siloed Chief AI Officer may find themselves navigating a labyrinthine path, fraught with challenges, short-lived victories, not to mention their own short tenure!

The sustainable integration of AI into business practices needs a leader who is not only doggedly chasing the value from AI but also has a deep understanding of the business landscape. The Chief AI Officer must not just be a collaborative master personally, but also build a culture of collaboration, working hand-in-hand with both line of business leaders and data leaders.  Anything else may well fail to ensure that AI initiatives are more than a momentary shining star.

 

Chief Data Officer: Sidekick or hero in this story?

The Chief Data Officer, already attuned to the intricacies of managing both defensive and offensive with regard to data assets, provides a complementary perspective to the Chief AI Officer. By joining forces, either as a single role or a collaborative partnership, the CAIO and CDO can create a synergistic relationship that uses AI for its transformative power and new ways to deliver value while also building upon and strengthening pre-existing data imperatives.

My view is that early integration is a good thing. Sure, find the box canyons and the gotchas the hard way. Innovate and potentially fail before trying again. But, wouldn’t things be easier with an ally to help point out the pitfalls ahead of time?

Balancing offensive gains with a defensive awareness and building from a solid base, gives our hero half a chance to move from just starring in a quickly forgotten short story to become the feature act across a box set of novels.

---

 

Data as an Asset – Walk the Talk

Establishing data governance programs, data quality initiatives or other projects aimed at looking after or enhancing the well being of a company’s data can be difficult to get underway and sometimes even more challenging to keep alive.  Such initiatives (especially if your company’s funding approach forces you to tackle them as a series of individual projects) cannot always deliver the concrete and tangible “things” that you might get from a more traditional IT project. More often than not there is no new asset created, no new system to implement and enable across a go-live weekend, nor are benefits always obtained and measurable in the short term. Unless your business is facing real pain (and honestly attributes that pain to not just problems with the data itself, but also with how the data came to be in the state it is) then you may well struggle building support for, and keeping data initiatives running.

Often this seems surprising to data folks. It seems that this isn’t logical. The business says all of the right things about valuing data quality, about wanting a single source of truth from which to make better, faster and more cost effective decisions and maybe someone has even sprouted the “data as an asset” phrase, but this hasn’t resulted in them beating down the door with bags of money to fund data improvement initiatives. At first glance it seems key business stakeholders are showing moral support for the concepts but no commitment to the actions required to really solve the problems in the longer term.  They are the chicken to the data team’s pig.

But perhaps it’s not all that surprising. Are you, as a data leader, walking the walk or simply talking the talk? Do you treat your company’s data as an asset yourself? And does your data strategy reflect that? Do you even have a data strategy or are you one of the many, described by Joyce Norris-Montanari in her recent blog post  (http://www.dataroundtable.com/?p=12661), who fall into the group lacking a vision for their data and a strategy to help them get there?

If you’re not walking the talk then chances are that you’ll need some work up front to sell a congruent picture to the business, and particularly to those stakeholders holding the purse strings.   Make sure that you can show the basics around the company’s data that you would have around any other asset.

• Knowing what you have – an inventory of your data;
• Knowing where this data is – which systems house which data and (ideally) how it moves around between them;

• Knowing which stakeholders care about which data (you don’t need to get to business data ownership just yet, but at least you should know which data helps achieve, or threaten, which stakeholder’s bonus package);
• Knowing what preventive maintenance is required to keep your assets running at the required level and optimize the investment in them- some idea (and documentation) of where the problem areas lie. The big data quality issues (and importantly their real impact on the business);
• An understanding of how you can protect your asset – which may include classifications for data along with associated handling rules and other security aspects; and
• A vision for continuous improvement and a better future state of asset management – thought out and documented ideas for better use of your asset (which might include identifying and reducing redundancy, identifying inventory gaps or working better at the extreme ends of the asset life cycle).

With enough of the above in place you have your house in order and can say that you are indeed making efforts to treat data as you would any other asset. Now that you have a congruous story to present to the business you may find your next funding request is met more favourably. Even better, chances are you may well have identified a number of projects to deliver some concrete shorter-term benefits along the way as well.   

Why Data Quality is Like Shaving

Maintaining data quality is like shaving. That thought hit me early yesterday morning whilst I was doing it - shaving, that is, not maintaining data quality! Here's why.

A few things that most of us know about shaving and probably also know about data quality:

1. It's not much use if you just do it once. You've got to keep at it every day.
2. If you don't do it for a while you can still get back to a good state, it just might take a bit longer and be a bit uncomfortable for a while.
3. Sometimes there's blood!
4. Convincing someone who's never thought of data quality as important that they should do something about it is as hard as convincing someone who has had a beard for 20 years that they should shave it off.

And here are a few things that might not be quite so obvious about shaving (and about data quality undertakings):

1. If you don't do it most people won't notice nor care. But a few people who are really important to you might treat you differently and not give you what you want. Just ask my wife!
2. A little is good. Do a bit more and many people around you might look at you strangely but chances are the extra you did will pay you back many times over one day when you least expect it. Just ask a cyclist who has had to apply sticky bandages to his legs after a fall if it's easier with or without hair on his legs!
3. Doing it everywhere you possibly can is probably a wasted effort (and just a little bit creepy!) And if you must do it everywhere, then some areas will definitely need more caution during the exercise (refer to item 3 in the first list!)
4. The longer you've been around the more places you'll have to pay attention to. At 25 we all laughed at people with ear and nose hair, but it comes to us all in time. That data you've got hanging around from the time it was "faster" to work in spreadsheets will start showing eventually!
5. Shaving gives you the chance to take a good look at yourself in the mirror everyday, often without any of your imperfections covered up. Maintaining data quality calls for the same regular scrutiny and openness.

And here's the biggest thing most people will immediately accept about shaving and should accept about data quality too:

Chances are you're not going to ask someone from your internal hairdressing department to keep you clean-shaven. It will work far better if you take care of that yourself. Data quality's no different. It's your beard and it's your data!

Data Governance and the Not So Thirsty Horse

What's that old joke? The one about the deeply religious man caught in his house as flood waters rise around him.  Early in the piece as the waters are only a few feet deep a dingy arrives to take him to safety and he refuses, saying "I'll be fine, the Lord will look after me". Later, as the water rises and forces him to the house's upper story, a bigger boat arrives and those on board implore him to leave his house and come with them. Once again he answers "I'll be fine the Lord will look after me". Some hours later as he is perched dangerously on his roof with water lapping at his feet a helicopter descends and those on board urge him to leave before it is too late. But the man is insistent - "The Lord will look after me, I don't need you to save me". Not long later the waters rise again and the man is swept away to his death. Arriving in Heaven he is confused and, on being granted an audience with God, asks Him "Lord, I put my faith in you. I trusted you. Why didn't you save me?". God looks at him somewhat incredulously and asks "what more did you want? I sent you a dingy, a boat and a helicopter!"

On more than one occasion in my career I've marvelled at how much that joke paralleled what was going on around me. You may have even experienced this yourself at some time - demands coming from all sides, requests for clarity around data meanings, master data rulings, demanding to know why you don't know the ins and outs and business rules of obscure pieces of data that is about to be touched by some project or rather, and complaining because there's not enough documentation and other collateral in place - forcing them to have to spend more effort and dollars inside their project.  If this was indeed all missing then I could understand the consternation, but when a data governance framework exists and the business users understand and acknowledge that they (and not the IT group) steward the data and are the ones with the true knowledge of that data, then I start to bristle a bit. Maybe not the first time, or even the second or third time you walk people through what's available and how to make best use of, and leverage it, but sometime thereafter it's sure to come. I've noticed similar behaviour in other industries across my career, but it does seem to be remarkably pronounced amongst those working in IT.

Often I've put this down to some form of Not Invented Here Syndrome and accepted that some individuals will just not use what is put before them, be it through lack of acceptance, understanding or whatever. I'm sure that the phrase "you can lead a horse to water, but you can't make him drink" has passed my lips on numerous occasions. But lately I've started to think that perhaps this is not the answer. The horse really needs a drink, he just doesn't know the water is good yet! I've written before  about the need for persistence and tenacity when implementing data governance programs. Perhaps this situation offers an opportunity to create greater acceptance of data governance, data stewardship and the like. Meeting those IT folks placing demands on you half way may well work - give them a little of what they are asking for, do a bit of "their" work for them.  Sure, it's re-inventing the wheel to some degree, but nudge them toward what's already in place, shepherd them into the data governance framework and show them (via a few small wins) how they can leverage the data stewards working within it. My initial findings suggest that where those people begin to see that it can make their jobs easier they start to be more accepting of it and begin to use it to augment their other activity and in some cases make it first port of call. Given enough time I'm convinced we can make data governance advocates and champions of at least  some of these people.

I'm keen to hear from you if you've experienced (and leveraged) similar issues as I'm sure I'll encounter many stables full of horses who don't know they're thirsty across the rest of my working life!

Data Governance and the Self Licking Ice Cream

A friend and colleague regularly uses the self licking ice cream phrase to illustrate to the project management team he mentors that projects need to provide value to the enterprise and not just operate in a vacuum. No matter how well those in the project build a system, or how well that project is managed, it's unlikely to be perceived as a useful and successful exercise unless the various stakeholder groups agree that the work was needed and worthwhile. From their point of view all that the project will have achieved is keeping those on the project busy and employed for its duration.

But that can't be said for data governance, can it? Every organization has at least some data quality problems, conflicts around data ownership, data silos preventing leveraging the data asset across the business, so therefore every organization could benefit from a data governance program.

That may be true, but I'd still like to bet that many, if not most, data governance programs are seen by many in the organization as self licking ice creams. Ask an exec or senior manager from one of those firms and chances are they'll not see the value of the data governance initiative. If you're heading a data governance program and your execs don't recognise the need for it then, even if you think what you're doing is worthwhile, I've got bad news for you - to others you're licking your own ice cream! It won't matter if you've been making great advances in improving data quality, finally getting the data stewards to work together to understand master data issues, or building understanding across your data landscape and producing mountains of documentation along the way. From the outside you'll just be seen as doing little more than using scarce funds and making a call on their peoples' time for no other reason than to keep yourself in a job.

Of course securing an executive sponsor for the program and working to win wider executive awareness and buy-in will help avoid this scenario. However, this will be difficult to achieve and retain unless you continue to find ways to make your data governance work relevant and demonstrate value that can be seen by key stakeholders in the organization. For me, to do this it's critical to have demand placed on a data governance program. If people in the enterprise don't recognise they have data problems and aren't coming to you to help solve them, then you need to find something tangible for your program to tackle. If you're lucky enough to be facing upcoming system changes with associated data migration then that may be a great driver. If not, then try and find the areas where non trivial amounts of money can be saved due to data problems or look for the issues that keep your execs awake at night because they lack confidence in the data. If you believe that those situations can be helped through data governance then start to work on them, if not keep looking - trying to force them to be data governance issues won't do you much good.

If there's nothing in your organization that you can apply data governance to (and be seen to create value) right now then don't be afraid to let things lie for a while. Pushing ahead on things others don't perceive as valuable may actually torpedo the longer term success of a data governance program. Better to lie low and bide your time rather than have others shut the program (and perhaps your career prospects) down. But, keep your ear to the ground because there will come a time when there will be a big problem facing the organization which data governance could help solve. Be ready to seize the opportunity. If you don't and one of your execs later reads about data governance then being a self licking ice cream will be the least of your worries - you may fall victim to airline magazine syndrome!

Data Ownership and Data Responsibility Should Go Hand in Hand

Chances are that all of us who have tried to advance a Data Governance initiative will have had the data ownership discussion and socialized the idea that IT shouldn't own the data. In the earlier years of my data governance efforts getting acceptance of this concept was most often the first stumbling block. Common remarks from both the business and IT fronts reflected long established culture and practices in which data was seen as an IT focus - they managed it, wrangled it, invested and got to the root cause of data problems, and they held the responsibility of fixing data problems. This resistance, although frustrating, at least had a common theme which allowed me (and I suspect others like me) to build up a toolkit of arguments, presentations, stories and case studies to help move stakeholders toward an understanding that data is best owned by the business and not the IT function.

I've written about the need to keep working away toward implementing data governance before in my post on Thinking Like a Vogon. Having a bag of tricks built up and finessed over time is, in my opinion, key to successfully importing data governance at an organization. It allows those of us charged with championing data governance to keep working toward advancing stakeholder understanding and buy-in over weeks, months and years. Recently I've noticed a trend which has the potential to poke a hole in this bag of tricks, reducing its effectiveness and necessitating a rethink of how I engage with stakeholders. These days I encounter less push back when I propose the idea that IT doesn't own the data. The concept that the business owns the data now often seems to be easily accepted, with some business users going as far as saying "of course we own the data!"

Acceptance! It's all easy from here, right? Maybe not. While there seems to be a lot more widespread agreement that business users own the data this doesn't always translate into the best outcomes for data governance and improved data quality. Statements from stakeholders along the lines of "we own the data, but IT let us down because they can't get the data quality right and they don't understand our data" ring alarm bells for me. That one step forward may just have been followed by two quick steps back. What's missing here is responsibility. Ownership without responsibility is hollow and reflects an understanding which still has quite some way to go to reach maturity. I liken this sort of statement to a father boasting about the achievements of his children before reaching for the phone to arrange a nanny to look after them whilst they are home from boarding school. Just like we can't expect school teachers and others to take sole responsibility for shaping our childrens' lives and helping them through their problem times, business users can not claim to be data owners and then take a passive role only getting involved in data issues long enough to point the finger of blame at IT.

So how can we this new phenomenon be dealt with? Sure, a part of what needs to be done is updating the message and tailoring the tools and communication methods we use to address this new position. But, it's more than that, as data governance professionals we need to look for ways of showing those in the business with this view "what's in it for them". We should look to find success stories - show where there was demonstrable benefit gained when another business user started to take an active interest in the health and well being of their data. Even better, we should spend time with those business users who have already embraced not just data ownership but data responsibility as well, helping to make them into champions for the cause and assisting them to sell the benefits to their colleagues. The broader IT function also has a role to play here. We need to ensure that IT doesn't reinforce the existing culture, and as such there needs to be a little gentle push back when the business shows signs of pushing all data responsibility to IT. This need not mean a flat out "no", nor an abdication of any and all responsibility, but rather taking these opportunities to engage with business users, working with them as enablers rather just than in isolation as technical troubleshooters blindly trying to solve problems often without enough context or knowledge. By working together - making changes on both sides - IT will boost data context familiarity and those on the business side will get involved more often and earlier. From a management perspective, look to change IT policies if they talk about IT owning and managing the data, and think about establishing data reference groups.

No matter what approaches we take, there is one very important thing that can not be forgotten. We must help business people in their new roles as data stewards. We can not leave them to feel their way along. Build documentation and tools to help and guide them, recognise new responsibilities by modifying Position Descriptions and the way these people are measured and rewarded for performance. Not only will this signal that the organisation is serious about data governance and data quality, but it will also guide and encourage the stewards to perform better.

Why IT Can't See 2 Plus 2 Doesn't Equal 5 (And Why It's Not Their Fault)

How do a loaf of bread and a small bottle of orange juice lead to a blog post about data? Here's how. Last week I bought (or at least tried to buy) a $4 loaf of bread and a $2 orange juice. The young lady (a trainee, according to her badge) behind the counter cheerfully informed me that it would be $27.60 and seemed a little taken aback when I asked if she was sure about the price. She assured me it was right and even went so far as to turn her monitor around to show me - "See, there it is!". Risking the chance of becoming the customer from hell, I pushed my claim that the price was wrong. Another staff member (herself probably not old enough to have left school) was called to assist and tried her best to educate the problem customer - "Look, the computer says that's what it is, so that's what it costs". It took me leaving the goods on the counter and turning to walk out to have the duty manager come over and straight away see the problem and charge me the correct price.

I bet we've all had at least one similar experience and laughed about it, putting it down to "kids today" or asking "what are the schools teaching now?". But step back for a second and think - should we really be so quick to judge? Take a less critical view and ask what is really happening. The shop assistants are most likely casual employees, which means they spend only a few hours each week in that environment, they don't live and breathe the goods they sell and couldn't tell you the price of a loaf of bread without referring to a price list. While they can do their job and function largely without mistakes if enough boundaries are set and systems provided, when something goes wrong or when the pressure is on they lack the familiarity and deeper understanding which lets them sense when something (e.g. my price) is wrong. Chances are that the math skills of the two casual shop assistants were just fine, it was the lack of context of the individual prices and not yet having a confidence gained from situational familiarity which prevented them from recognizing a problem and speaking out with a different answer than that given by the system.

Is there a parallel between this example and how we work with data in our organizations? I think so! I've certainly heard (on more than one occasion) people from the business bemoaning that IT just don't get it, they don't understand the data. If the IT folks don't work with that data much, only a few hours per week, or in blocks of time many months or years apart, then that's not surprising. Even if they do work on the data more frequently they don't have the context gained from working with the data in the same way the business users do. What's apparent (at least to me) is that this gap in understanding is not the fault of the IT staff. If people don't work with a dataset closely and regularly enough to gain familiarity and understanding then even what are [to others] glaringly obvious mistakes may well go unnoticed. In the same way as the shop manager needs to find a way to better equip her staff to deal with situations like mine, we (as Business and IT Managers) need to find ways to better deal with data centric issues in our organizations. This may happen in a number of ways, for example

• embedding IT staff in the business to have them work with the data and alongside the business users 
• having business people take an active and accountable role in data migration projects and not leaving IT staff to make snap judgement calls about the data at the pointy end of a project to hit a go-live date, or 
• bringing the idea of data governance into the organisation and getting the business people involved with decisions around the data.

No matter which of these approaches you adopt I think two things should always be present. Firstly don't blame the folks at the coal face, and secondly introduce and promote the idea that data ownership belongs with the business not the IT department. Miss these opportunities and chances are that, just like me with my bread and OJ,  at some stage your company will be asked to pay a much higher price than seems reasonable.

Implementing Data Governance: Think Like A Vogon

Recently I received a note from a prior colleague. He was in the midst of trying to implement data governance at an organization but was getting severe pushback, basically he saw he was headed for project failure. I had a couple of pieces of advice for him which I'll share here as I'm certain he's not the only person struggling to get data governance off the ground.

Establishing data governance at an organization is not easy, it will take time and chances are that the first approach you try may not work. In my opinion if you're working on something with a name along the lines of "Data Governance Project" then you've got a problem. For me, establishing data governance isn't a project. It's not something that can be up and running in a few short weeks or months, but rather I think of it as an initiative - something to be worked on over time, building toward an objective with the flexibility to change tack or even retreat, regroup and try again depending upon the appetite of the organization and the receptiveness of the executive and key stakeholders.

Which brings me to my first piece of advice: Think Like A Vogon. If you weren't lucky enough to be a teenager in the 1970s and 1980s then you may not know what a Vogon is so a little back story may be in order. The Vogons appeared in Douglas Adams' book / radio play / TV series The Hitchhikers' Guide to the Galaxy. Their battle cry was "resistance is useless!". If you're going to embark on a data governance initiative then you need to adopt this as your mantra. You need to keep telling yourself not to give up, you will strike resistance, but you can't stop at the first hurdle (or the second or third for that matter) . Keep telling yourself that resistance is useless because you will establish data governance in the end!

The Vogons used their battle cry as the answer to any dissenting argument or position. Their common approach was to simply keep shouting "RESISTANCE IS USELESS!" at whomever didn't agree with them.

This brings me to my second piece of advice: Think Like a Vogon, Don't Act Like a Vogon. Use the mantra as a means to keep you going when you face pushback or you struggle to get buy in for your ideas, not as something to beat people over the head with. If your only trick is the compliance line, e.g. telling / forcing people to comply with data governance rules because they are the rules then chances are you've missed the value pitch for data governance and you're going about it for all of the wrong reasons anyway. Stop telling people they have to comply and start telling them what's in it for them if they do come along for the ride. Show what past problems might have been avoided had some data governance been in place or find how some small form of data governance will drive some demonstrable short term savings and go and implement that small piece. Sell the value!

The Vogons were not just a race of bureaucrats, they also wrote poetry . Unfortunately this poetry was commonly thought to be the third worst in the universe. Essentially their poetry was  nonsense verse and decidedly unpleasant to be subjected to.

Which brings me to my third piece of advice: Make Your Artifacts More Appealing Than Vogon Poetry. If you have a ponderous Charter, a rambling Terms of Reference or information that the Data Stewards will find it hard to make sense of, then invest some time in making it more useful. Make your communications with your stakeholders clear and consistent, make your value pitch concise and tangible and construct the material for your stewards so that it's functional and easy to use.  My final piece of advice is to make the data governance initiative visible. Let people know about it and what it can do for them. Spend some time and effort raising the profile. If you can get others excited by its potential then you may get support, and even pull, for data governance from within the business. Don't be afraid to let others know about your data governance initiative. Believe me, it's not something to be hidden away in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard."

I'll leave you to your Vogon Googling. I'm off to find a Dentrassi to make me a nice cup of tea!

Pragmatic Data Governance - It's a Matter of Trust.

This post had its genesis in a comment I wrote in response to a great piece about data governance written by Jim Harris (Twitter: @ocdqblog) over at Obsessive Compulsive Data Quality (http://www.ocdqblog.com/home/aristotle-data-governance-and-lead-rulers.html). I hope Jim won’t mind if I expand on those comments here. This post has grown organically and I'm not totally sure it captures all of the key issues bouncing around in my head, but getting it our there might help my thoughts develop and gel. So look out for a follow up post in the not too distant future.

Among other things Jim talks about the need for data governance to be applied with a degree of flexibility rather than following a set of rigid rules. This is a great perspective which exposes one of the key reasons why data governance initiatives often fail. In my opinion too often it seems that those involved (or those sponsoring) expect that hard and fast rules are what's needed.

I wonder how much of this stems from organisational cultures where staff time is closely budgeted and monitored. A common pushback I've struck in the past is managers of potential data stewards (almost) insisting on an exact breakdown of what data governance activities their people will be working on and how long each activity will take. Add to that the desire to help out new data stewards by providing them with tools to use as they learn what their new role involves and a situation where the rules and their strict application come to the fore can quickly emerge! The problem is compounded if the stewards feel that they may be blamed in some way if others are not happy with their choices or the downstream effects of them.

In my opinion, when setting up data governance programs we need to make sure that data stewards have top coverage – that is senior management endorsement and support when it matters- to give them time to act and the freedom to make considered and pragmatic choices that might involve bending or extending data governance “rules”. We must trust and allow the stewards to interpret rules according to the circumstances at hand whilst still being mindful of past precedent and any negative impacts their choices might have.

Without this support I’d question the value that a data governance program is going to deliver. Sure, maybe some cosmetic short-term data quality wins might occur, but chances are they’re the low hanging fruit and would probably have happened eventually anyway.  In the longer term all that is likely to happen is that the data stewards will come to be seen as blockers to progress - the holders and enforcers of a set of petty rules, putting up hoops for others to jump through. The hard issues (the ones likely to be standing in the way of unlocking real value) may never get tackled, the program will slowly wither and die as complaints mount against it and future data governance efforts will have a much harder time gaining any traction.

When a steward feels the need to build in a degree of butt covering into what he or she does there is a problem. If he or she can claim to have exactly followed the rules as a means of avoiding any blame storming about a bad situation that may have manifested from a data governance decision chances are the best outcome for the business isn’t going to manifest. We need to give data stewards the room to think, reason, weigh up the contributing points of view and then make the appropriate choice in the circumstances. A little trust in human nature and faith that people will want to do the right thing is required. If the organizational culture doesn’t support this then a successful data governance initiative might be possible, but it may mean that the data stewards need to sit higher in the food chain. But, ideally you can seek out and find stewards who already have the trust and respect of senior management and then will have the flexibility to act pragmatically when needed. 

So How Does This Blogging Thing Work Again?

OK, I’ll admit it. Things have been a little quite on my blog recently. Eighteen months is quite a time between posts. Surprisingly, my lack of writing is not due to a lack of time – although my second child did enter the world not long after my last blog entry. It’s more a reflection of a change in circumstances for me, a move from hands on designing and building business intelligence solutions to a role which involves strategizing, positioning, promoting concepts and attempting to envision future ways of working with information.

It’s amazing how not having specific, tangible and concrete problems to solve, issues to deal with or systems to build seems at first to rob you of anything worthy of sharing with the community. But now I’m hoping that some of the concepts I’m working with and the bigger issues that I’m chipping away at over time will carry interest for at least some of you. I doubt I’m the only person facing these challenges and a little sharing and exchange of opinions might be helpful.

Among other things, in the coming months I expect to be trying to establish and build traction around data governance, shape several data migration activities and find ways of better using metadata in our business. If all goes well I’ll also get the opportunity to kick around some data mining based R&D. I’ll endeavor to share what I can where I think it might be of interest. Hopefully there’ll be a bit of two way communication so please do drop me a line if you’ve tackled the problems I’m writing about or have a view on the concepts I’m discussing. I’m a big believer in leveraging multiple points of view where I can!

The first cab off the rank will be a blog entry that combines the concept of a single source of truth, the band Nirvana and my morning run. Keep an eye out for that post in the next day or so.