Chief Data Officers Are A Good Idea -- But How Is That Going To Work?

It seems to be popular these days amongst industry pundits to recommend that organizations add a new Cxx role: the Chief Data Officer (CDO). The arguments in favor of this move are exactly what you'd think: the rapidly accelerating importance of information in the enterprise, and, as important, the heightened perception of the importance of information by business executives. The attention on information comes from all the rich new data that simply didn't exist before: sensor data from the Internet Of Things, social media, process data -- really just the enormous volume of data resulting from the digitization of everything. Add to all that: new technology to handle big data in a reasonable time frame, user-friendly mobile computing in the form of tablets, data virtualization software and data warehouse appliances that significantly accelerate the process of getting at the information for analysis, and the promise of predictive analytics, and there's plenty of cause for an information management rennaisance out there. With a little luck, the activity it catalyzes will also improve enterprises' ability to manage the data and content that's not so new but also very important that we've been struggling with for the last decade or so. 

The only argument against creating this role that I've run across is that if CIOs and CTOs did their jobs right, we wouldn't need this new role. That's pretty feeble since we're not just talking about IT's history of relative ineffectiveness in managing information outside of application silos (and don't get me started about content management) -- we're adding to that a significant increase in the value of information and a significant increase in the amount of available information. And then there's the fact that the data could be in the cloud and not managed by IT, and there's also a changing picture regarding risk that suggests a new approach.

So it's easy to look at the historical information management immaturity of most enterprises and conclude we need a new model. And, since organizational changes often highlight that something new is being viewed as important to the enterprise,  it's also pretty straightforward to envision a new CDO role as a focal point of all this new value. But I've read maybe a dozen posts and articles by various advisory types, including one in the prestigious Harvard Business Review,  and I have yet to see anyone walk through the implications. Specifically, what would be the charter of this new role (and the organizational unit that would report to it), where would it report, and what roles would report into it?

For the charter, it's easy to see that the CDO would take on planning a strategy for taking advantage of all the opportunity out there. But would they focus on new stuff or also assume responsibility for all the existing information management functionality currently in the enterprise? Would they build data labs, hire data scientists, and pursue R&D for new business value? Would they wave a big stick and insist that business units appoint data stewards to work with IT information architects to define the information architecture? Would they manage information governance processes? Would they take over planning of the information management technology roadmap or coordinate with the existing architects or technical SMEs?

As for where the position would report, I expect a lot of people would look to a business reporting relationship to reflect the new awareness of the importance to the business. But then the charter and who reports into this position becomes quite interesting -- are we talking about moving all current information management staff out of IT and into the business? If so, what's the mechanism for coordinating with all the application, middleware, OS, etc. SMEs who work constantly with the information management staff? And if it doesn't make sense to move a significant chunk of IT functionality out of IT, what's the mechanism for coordinating any cool new things coming out of the CDO's labs into the mainstream architecture? Where do information architects live in this new world, and what's the relationship between the EA practice and the CDO's domain?

If the CDO were to become a role that stayed in IT and reported to the CIO, there are still plenty of questions. Does that create a sufficiently powerful role to influence business activity? Again, do all existing information management staff move into the new CDO organization? If so, how will that work within the general trend of more federated organizations that we're seeing? If we're not talking about moving all those staff, how does the new CDO influence all the information management practices in existence, mature or otherwise? What really changes?

I firmly believe that the definition of a CDO role is a good idea and collectively we'll figure out one or more good models. There's plenty to be worked out to make this effective, and there are no easy answers as far as I can see. We will see different models emerge and not all will succeed. But I get inquiries about every other day from someone rethinking their organizational approach to information management, so things are moving. 

This is a subject I'd really love to hear from you on. Do you think a CDO role is a good idea? What would that role do? As importantly, what would they NOT do? Where should they report, and who should report to them? 

Comments

Look to the CFO to guide CDO role definition

Hi Gene
Thanks for opening up such a great discussion - I agree that the CDO role is going to be an important leadership role in the future, but it's going through some early growing pains. I've met with a number of individuals who have the title of Chief Data Officer and their responsibilities, biz vs. IT reporting structure and scope varies significantly from one another - little to no standardization exists.

I'm of the opinion that we should think of a CDO similar to that of a Chief Financial Officer (CFO) or Chief People Officer (CPO). The CFO and CPO are responsible for protecting and optimizing the value delivered from financial and people (employee/contractor) assets, respectively. Arguably, isn't the Chief Data Officer responsible for protecting and optimizing the value derived from your data/information assets?

So optimally I would see the CDO role defined in a similar fashion. The CFO is a business leadership role (most often reporting directly to the CEO) that defines the processes and policies that dictate how to manage financial assets - and is responsible for complying with external regulations in this regard - and is ultimately accountable to ensure the organization complies. But compliance with these policies aren't limited to just employees who report into the CFO organization. For example, insider trading laws apply to all employees no matter where they report.

In a similar way, the CDO must also be a business leadership role that defines the processes and policies to ensure critical data is trusted and secure throughout its life cycle - and be held equally accountable for compliance. So I certainly think a CDO would own the data governance strategy for the organization. And since policy and standards compliance should not require a direct reporting relationship, I don’t believe all information management staff would need to be moved out of IT and report through to the CDO. Only information management subject matter experts responsible for driving, coordinating or operationalizing cross-functional data standards would likely need to have a solid-line reporting relationship to the CDO.

Obviously the CFO is an extremely well-defined and standardized executive role, but I think the ongoing evolution of the CDO role can learn a lot from how a CFO influences behavioral change, corporate strategy and investment prioritization.

CDO Role Contributes To A Move To A More Federated EA Model?

Thanks for the thoughtful comments, Rob The comparison to the CFO role is apt and thought-provoking -- we IT types are too likely to leap to a comparison to the CIO.

I have been thinking about the idea that you stated as "Only information management subject matter experts responsible for driving, coordinating or operationalizing cross-functional data standards would likely need to have a solid-line reporting relationship to the CDO," which essentially says it would make sense for information architects to report to the CDO. This makes me immediately think of a parallel issue occurring in the business architecture domain. That is, as business architecture as a practice becomes effective, some orgs formally move business architects into the business areas (or put them there in the first place when they create the role rather than on the EA team over in IT). So as the EA practice matures and works on things that matter directly to the business, as opposed to the past focus on just IT architecture, the organization moves these newly minted architecture roles into the business, leaving EA to cover...just IT architecture?

I believe the net of this is further momentum for the federated model. Enterprise architects, wherever they report, need to coordinate the planning being done by business, information, and technical architects, wherever THEY report. And governance processes have to be similarly cross-silo, as you point out in your comparison to the more visible compliance issues every enterprise contends with.

Too many officers

Gene,

CDO reminds me of CKO more than CIO -- and also suffers some of the same challenges as head of BI in the blog by Boris in the job description. Most of the arguments are valid until we take the entire organization into view and that's where I see problems.

Anytime this discussion on a new officer comes up it tends to rise from the desires, need to have more influence in the org, and aspirations of the specialist (and their ecosystem) rather than the need of the organization. Similar to a strong EA for example, what typically matters is whether the CEO (and board) is competent or not, paying attention to how the organization functions or not, and whether the culture and relationships are collaborative, combative, or even apathetic.

Unfortunately, one impact we have observed with the CIO and a few CKOs was confusion over the title officer by the entire organization, including those holding the title, when they suddenly became obsessed with their own power rather than service to others. Whether BI, EA, or CKO, in some cases we observed quite strong individuals who were driving critical value to the organization, but reporting to an infrastructure CIO who didn't understand much at all about business or organizations, or worse in a few cases simply concerned with protecting their own turf rather than the mission of the organization and customers.

Generally speaking I think it's wise to allow the brand of the individual rise up in the organization based on functionality, knowledge, and contributions to the organization--rather than yet another title ending with officer. Indeed, often has been the case when a person with a more humble title has had more impact, even in aggressive and highly competitive cultures, particularly when they are wicked smart and wise.

One problem rarely discussed is that corporate officer in many companies has real meaning in terms of authority, responsibility and legal accountability whereas in most cases the job description title of officer does not, creating confusion internally and externally (I am thinking now of one giant tech company in particular where titles have been a disaster to everyone but the CEO who hands them out).

I personally prefer scientist over officer and I'm not terribly fond of scientist (except when used properly to describe a true scientist) due to the disconnect in meaning and culture between science and business that is too often manifest in organizational dysfunction. I see functional roles more of a master craft person who may lead a small team, but is more interested in the value of their work than career aspirations to one day become a CEO, or even to lead large numbers of people where internal and external politics tend to rule. In fact it's been my experience that the strongest functional people do not have any desire to hold the title of officer.

So my fear based on previous experience and observations is that in the rare highly functional organization the role and title will also function well--regardless of what we call it, but in the norm it may do more harm than good, in which case the stronger professional will likely either avoid the organization to begin with or move on at the earliest opportunity. .02- MM

The Needed Cynical View

Thanks for the comments, Mark. You raise important issues. I've been querying other Forrester analysts about the CDO role and hopefully I'm not oversimplifying by saying there are 3 basic responses: 1) No immediate embrace/reject response, which can be paraphrased as "Hmmm, we need to define it in detail and then think through the ramifications -- what changes, will it work better, etc.?" 2) Immediate positive response, often from individuals working in information management areas. The rapid positive response indicates past frustrations with the adoption of EIM best practices. 3) Immediate negative response, with arguments similar to yours about jumping to a Cxx role as a solution to a complex problem. One analyst went as far as to suggest the creation of the CDO role in a particular org was essentially proof that they have failed to do information management right to date. However, this same analyst also posited that it may be a positive development for organizations to at least temporarily put a high-powered individual in that role to kick-start a strategy and get the organization moving in the right direction. The activities, org structures, and processes resulting from focused high-level attention may eventually become part of business as usual, executed in an integrated / federated fashion and making the CDO role less necessary in time.

Clearly, the simple creation of a CDO guarantees nothing. Org changes in general can't actually make something happen -- all they can really do is remove organization-based obstacles. If the main organization-based obstacle for advancing an information strategy is that there is no owner for defining and pushing the strategy, then making a CDO -- or a CIO, lead information architect, enterprise architect, etc. etc. -- the owner of the strategy and empowering them to pursue its implementation may be very beneficial. But there are seldom simple comprehensive solutions to complex problems.

Thanks- couple additional thoughts

Thanks Gene- good to see more detail on internal deliberation- can appreciate each of the responses you describe.

I certainly agree that it's probably a good idea to investigate the CDO for a firm like Forrester on behalf of a large number of clients as it would be a challenge for most to focus deeply individually, and any going this route would no doubt benefit from a disciplined approach, feedback loops from many others, etc.

I guess my pushback would be that if the simple creation of a CDO guarantees nothing, then I would be hesitant to do it--and I am a fan of experimenting - less with organization-wide functionality (business models, etc.) than technology, however.

The problem I've experienced with ownership in especially large disbursed orgs is that ownership is popular when things go right and quite unpopular when they don't.... in my experience in dealing with corp officers who have been told by boards that they own a functional area of responsibility--even backed up by contract--they often don't when push comes to shove. I've had to enforce this myself a few times with CEO and COO temp contracts in turn arounds earlier in my career--most have no problem nodding authority until it disagrees with them--or worse, when that authority investigates and reveals that they are part of the problem.

Which is reportedly why (in private of course) so many functional experts who are motivated by getting things done, overcoming problems, etc. shy away from corp politics. Good luck with CDO - MM

Gene, I really like your

Gene,

I really like your article and have been a proponent for the CDO. In my view this position is about leading the strategy for the information assets within an enterprise. I feel the CIO or CTO functions should evolve to maintaining and implementing the tools and infrastructure of an organization. Thus the CDO role is to develop the strategy and work with the business units to understand their information needs. The CDO the works with the CTO to deliver on the strategy. The CDO would have people such as the Information Strategist reporting to him which is a role that I believe is evolving from the Governance structures organizations have created. In regards to Information Governance this would also report to the CDO as well.

To say it more simply the CDO position is all about helping an enterprise leverage their existing information assets to drive revenue and cost savings as well as defining and then leading the long term strategy of their information assets. It is not about building the applications or buying the hardware, etc that IT would continue to own.

Looking forward to others ideas and comments.

Data + Context =

Data + Context = Information
Information + Experience = Knowledge
Knowledge + Reasoning = Intelligence

There should be ONE officer that manages that entire stack. It doesn't matter what it's called, but no organization should have a CIO and a CDO or CKO unless they are in full alignment.

No sane organization would create a Chief Budgeting Officer that's independent of the CFO. The same alignment is needed with data, information, records, and knowledge.

CIO's need to stop focusing on the desktop and network services business. Outsource it or give it to a CTO, and change your focus to actually managing the organization's information.

CDO's main role to ensure data sharing

This concept was just floated at our Regulatory Data Workshop: several Federal agencies are pursing the CDO idea. But to me the primary purpose of a CDO would be to establish inter-agency and intra-agency data and information sharing: the barriers to this kind of thing dwarf the technical aspect.