The article below is excerpted from the book, The Case for the Chief Data Officer (Morgan Kaufmann, 2013) with permission from the publisher. The book’s authors argue that the c-level management of many of today’s organizations needs to be more data savvy, and that someone on the executive team needs to own the data strategy.
Someone should be charged by the organization with the task of leveraging data assets in support of strategy. If we had to do it all over again, we would assign the CIO responsibility as the top data chief. CIOs should consider:
Am I going to dedicate my career to the management of this increasingly critical organizational asset? That is, become more data-focused.
Will I keep my current portfolio of IT concerns (technology focused) and help my organization obtain a dedicated resource to manage its data?
If the latter is chosen, welcome the evolution of your title towards CTO, IT Director, Director of IT, or something more accurately describing your challenging role now resolved of the primary responsibility for organizational data.
While some temporary discomfort may come during the decision-making portion, only by dealing with the issue directly can an intelligent decision be made. Is data receiving the care and feeding required to leverage it? If data is important to the future of your organization, you must establish a CDO function and then decide who should run it.
Regardless of your specific choice, where should the CDO be located, organizationally, and what should they be doing? This requires implementation of a rigorous regimen that touches all facets of the organization. The CDO should:
- Focus on solely on data asset leveraging these activities are outside of and more importantly both upstream and independent of any application system development lifecycle (SDLC) activities.
- Report to the same organizational structure that the CFO and other top asset management jobs report into; reporting outside of IT and the current CIO/CTO structure altogether.
- Report directly to the business and concentrate on a crawl, walk, and run strategy regularly and measurably improving the maturity of organizational data management practices.
Where Should CDOs Report?
The CDO is a business function and should not report to IT. As organizations are embracing the CDO concept, 80 percent of them have this individual report to IT. We strongly disagree with this concept. Appointing a CDO subordinate to the CIO (or any IT leader) forces data to be managed as part of the IT portfolio. The CDO cannot accomplish data leveraging while subject to the structured deadlines of IT projects. Further, if they report through someone who is not data-knowledgeable, it will be impossible to improve the data decision-making process.
While transformation may require some organizational discomfort, this move will achieve improved organizational IT performance faster and cheaper than ERPs, Six Sigma, or any other silver bullet attempted to date.
The CDO should parallel the reporting structure of other asset chiefs. The CDO should be the senior organizational official most expert in, and responsible for, organizational use of data-based organizational assets in support of strategy–the Data Chief. CDOs must implement a demanding regimen that touches all facets of the organization with a renewed emphasis on quality, decision-making, improving product/service, and a data management system that extends to organizational components.
The CDO should report with the top organizational management team for two reasons. First, the historical low priority given to this function requires, at least for the next round, a corresponding bias towards data-centric development practices. Second, it is also clear that data management expertise is not widely available–organizations will need time to determine what works best for them and it will be while before generalized guidance is forthcoming. Actual implementation will require practiced coordination among IT, operations, a specific domain (such as marketing), and data–with project-specific domain rotation.
There are at least six arguments for not having the CDO subordinate to IT.
1. IT does not feel the true impact of poor data management practices. Data problems can and often do delay IT projects. This causes the organization to pay more for IT than it should. The impact to the organization is greater than IT. The organization is more likely to suffer publicly from data problems while the impact of IT-related data failures is less likely to become known to the outside.
2. IT does not know organizational business rules that govern data and its use. IT’s focus on technical knowledge leaves little resources and few cycles to devote to understanding how data is used by the business for various decisions.
3. IT does not own or control access to the subject matter expertise ultimately needed to implement data-centric development practices. The technological focus keeps IT fully occupied with “how” concerns. There is very little capacity for understanding business oriented, “what” problems.
4. Only the business can competently assign values on various data uses. Defining what are “good enough” data management practices cannot be done from an IT perspective.
5. Reporting to IT has been expected because IT owned the method. Because IT specializes in methods, IT was assumed to manage the data. Most non-IT knowledge workers have no idea that methods can be used to develop flexible, adaptable, and reusable data.
6. CIOs are already slammed.
There are at least four arguments for CDO to be independent of IT.
1. It appropriately apportions labor. Because IT is already overloaded and has its hands full with the technology “hows” focus of the organization’s application systems, as well as all the other hardware, networks, and systems software it is appropriate that the CDO take ownership of defining the business “what” focus.
2. It reduces project-centric application system requirements. The traditional IT life-cycle is highly focused on project-centric work products, implementations, and evolutions that foster and grow silos. In contrast, the CDO’s efforts are organization-centric work products that are often project independent and that tend to eliminate IT silos. Again, these are essential, not accidental differences that result in fundamental impedance mismatches.
3. It encourages business to learn appropriate IT-derived methods. Maintaining the requirements (the “whats”) in the business will reduce translations and encourage broadly based, data-centric, systems thinking. Business engineering is less rigorous than information systems engineering.
4. It encourages organization-wide data and architectural component reuse. The longer-term focus of data is at odds with IT development cycle—data management is a program not a project. Nurtured data architectures grow in value and use over time.
On this point, we find growing agreement from the business as well as from the CIOs–they readily acknowledge they haven’t the time or resources to focus on data management and they are happy for someone to assume these responsibilities. They understand that asking IT to excel at the CDO’s data mandate, in addition to all the other IT tasks, may be difficult. There are fundamental philosophical and operational mismatches between IT and data management. Organizational patience and discipline required to leverage data assets are at odds with the innovation-driven, technology focus prevalent in IT.
What Should They Do? Primary CDO Challenges
Assuming you are able to successfully argue for the business accepting the CDO role, what should this individual focus on? The answer is, in three parts:
- Make data management independent from business information system development
- Remain data focused
- Improve your organization’s data management maturity
As part of the organization’s senior leadership, the CDO is the head of organization-wide data governance ensuring that the right things are done in the right way. The data scope of the CDO is not just business-centric “real” data, but also all the metadata across the entire organization. The CDO is responsible for improving the organization’s data and data structures, culling the 80 percent data ROT suffered by most organizations (reducing data volume), and enriching the remainder (data quality). What remains, is the unique authoritative, and identifiable data and definitions desired by the organization the master definitions managed.
All current data management functions as defined by Data Management International [http://dama.org/i4a/pages/index.cfm?pageid=3733] except for two (Data Development and Database Operations Management) should move out of IT. Two data management functions (Metadata Management and Data Security Management) are explicitly shared with IT operations. This is a major shift; these functions are used to reporting to IT.
Make Data Management Independent from IT Development
A key difference exists between application systems and data architectures. Application systems either exist or they don’t. The focus of application systems development is to create something where nothing existed prior and to do it in a repeatable, standardized manner to minimize development costs. In contrast, data architectures are not created. Rather, they evolve. While all organizations have data architectures, the question is whether organizations are able to use their data architectures to support strategy. As such, the data architecture processes improve whatever data assets currently exist. Data architecture processes are more like maintenance, re-engineering, and evolution processes while system development is focused on replacement.
The data architecture evolutionary approach is often foreign in strategy and execution when presented to typical IT professionals. It conflicts with the nature of application systems development. The results of a data architecture development effort provide a context for its subsequent IT application systems development projects. It can take years to evolve a data architecture from its current state to its desired state. This evolutionary effort can only be accomplished outside of the traditional application systems, project-centric development process.
A number of SDLCs must properly occur in order for the data management activities to reach a critical mass past the tipping point and achieve the ability to usefully contribute in support of organizational strategy.
Over time, the number of requests for information architecture components increases as developers increase their understanding of data architecture methods and resources, and learn how to work these evolved understandings into their application system development plans. Similarly, as data architectures increase in scope, the breadth and usefulness of its available data increases to system developers. Because of this data architecture discipline, each subsequent application system contributes enhanced data assets.
Evidence indicates that this back and forth interaction between IT application systems development and data architecture and evolution is simply not being performed in most organizations. Under the application system’s development paradigm, data architectures are created entirely within application system’s boundaries and are thus unusable by other parts of the organization. Data leveraging is prevented.
Remain Data Focused
As part of a study, IT professions specializing in articulating system requirements were asked “What is the most difficult part of analysis?” The surprising answer that came back was a resounding “Not doing design!” That is, IT professionals focused on specifying “what” have a hard time not automatically following the “what” with solution design. That wouldn’t be such a challenge if time was not a factor. However, requirements phases are time-boxed. Any time spent doing design work directly robs time and attention from requirements. This is particularly damaging to organizational development efforts because it costs significantly more to identify and correct errors as an application system project progresses through the SDLC.
The CDO is a full-time job. As a senior leader within the organization, the CDO officer must maintain a sole focus on understanding, marshaling, and applying organizational data resources in support of strategy. The basic argument is that any time the CDO is paying attention to anything other than data support for strategy, they are diluting their own effectiveness.
Improve General Data Management Practice Maturity
Data management is a young discipline when compared to the relatively mature accounting profession, which has existed for thousands of years. As the figure below shows, data management consists of five interrelated and coordinated practices. The figure supports the definition: “Organization-wide management of data is understanding the current and future data needs of an organization and making that data effective and efficient in supporting business activities.”
The figure illustrates how strategy guides other data management practices. Two of these practices, Data Program Coordination and Organizational Data Integration, provide direction to the implementation practices Data Development and Data Support Operations. The Data Stewardship practices straddle the line between Direction and Implementation. All practices exchange feedback designed to improve and fine-tune overall data management. Each practice is assessed according to the CMM five stages of maturity for process improvement. Process maturity assessment on the CMM scale yields both a baseline and direction, which, in turn, permits organizations to understand the nature of their organizational challenge to achieve greater maturity. Increased maturity leads to increased data leveraging opportunities.
The Perhaps Temporary Nature of the CDO
The need for certain chief officers has occasionally been temporary. The title Chief Electrification Officer isn’t in as widespread use today as it was during the when organizations were scrambling to learn how they could use electricity to support their business objectives. It is good and appropriate that these positions evolve in response to conditions and organizational needs. To be safe, we would suggest that for the first year the CDO focus 100 percent on organizational data issues.
Our 2013 research indicates that 53 percent of organizations recognize the need for a CDO but have not yet started the process of establishing the position. Five percent indicate their CIO is covering these responsibilities and 8 percent indicate someone besides the CIO is accomplishing data asset leveraging. Seven percent were in the process of establishing or hiring their CDO. One percent believes that data plays a role small enough to not warrant a CDO.
For the other 99 percent we believe CDO should examine your data operating environments with an eye toward improvement.
Peter Aiken has been a member of the Information Systems Department at Virginia Commonwealth University’s School of Business since 1993 and jointly owns with the university, Data Blueprint, a data management and IT consulting firm. Michael Gorman, a longtime IT professional, is the secretary of the ANSI/InterNational Committee for Information Technology Standards on Database Languages.