Creating the Right Conditions for CDO Success
5.2.1 The CDO Should Parallel the Reporting Structure of Other Asset Chiefs
5.2.2 Arguments for not Reporting to IT
5.2.3 Arguments for the CDO being Independent of IT
5.3 What Should they do? Primary CDO Challenges
5.3.2 Make DM Independent from IT Development
5.3.3 Remaining Data Focused – this is a Full Time Effort (FTE)
5.3.4 Improve General DM Practice Maturity
5.3.5 CDO Position Description
5.1 Chapter Overview
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 are certain we would assign the CIO responsibility as the top data Chief. CIOs reading this book should consider:
Am I going to dedicate my career to the management of this increasingly critical organizational asset? That is, become more data-focused.
Or
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 later alternative 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. The question is: 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? The where section of this chapter describes the conditions required to achieve success and the what portion lists the top CDO priorities. This requires implementation of a rigorous regimen that touches all facets of the organization. In order to be successful CDO function requires three specific changes in most organizations – specifically the CDO should:
1. 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.
2. 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;
3. Report directly to the business and concentrate on a crawl, walk, and run strategy – regularly and measurably improving the maturity of organizational DM practices.
5.2 Where Should they Report?
The CDO is a business function and should not report to IT.
As organizations are embracing the CDO concept, 80% of them have this individual report to IT.1 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.
5.2.1 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 DM system that extends to organizational components.
There are two reasons why the CDO should report with the top organizational management team (see Figure 5.1). 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 DM 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 (i.e. Marketing), and Data – with project specific domain rotation.
5.2.2 Arguments for not Reporting to IT
There are at least six arguments for not having the CDO subordinate to IT.
1. IT does not feel the true impact of poor DM 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 know 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’ DM 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.
5.2.3 Arguments for the CDO being Independent of IT
There are at least four arguments for CDO to be independent of IT.
1. 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. 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. 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. Encourages organization-wide data and architectural component reuse.
The longer-term focus of data is at odds with IT development cycle – DM 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 DM and they are happy for someone to assume these responsibilities.2 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 DM. Organizational patience and discipline required to leverage data assets are at odds with the innovation-driven, technology focus prevalent in IT.
5.3 What Should they do? Primary CDO Challenges
So 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:
5.3.1 CDO Scope
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% 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. Figure 5.2 shows how CDOs are marshaling a broad range of capabilities in support of data leveraging.
Figure 5.3 show all current DM functions except for two (Data Development and Database Operations Management) moving out of IT. Two DM 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.
Figure 5.3 Proposed division of DM Function between Business and IT. (adapted from http://dama.org/i4a/pages/index.cfm?pageid=3548)
Figure 5.4 shows that most CDOs are establishing control over governance/architecture and some are incorporating BI and compliance functions.
Figure 5.5 and Figure 5.6 show how complex the job of CDO is perceived to be, tallying a variety of desired capabilities and required traits, respectively.
5.3.2 Make DM 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, reengineering, 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.
Figure 5.7 illustrates an evolving data architecture that results from the step-wise refinement of different business information system development cycles. A number of SDLCs must properly occur in order for the DM 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 how to work these evolved understandings into their application system development plans. Similarly, as a 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.
5.3.3 Remaining Data Focused – this is a Full Time Effort (FTE)
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.
5.3.4 Improve General DM Practice Maturity
DM has existed in some form since the 1950s and has been recognized as a discipline since the 1970s. DM is a young discipline when compared to the relatively mature accounting profession, which has existed for thousands of years. As Figure 5.8 shows, DM 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” (Aiken, Allen et al. 2007).
Figure 5.8 Organizational DM practice areas and their Inter-relationships (Parker 1999).
The figure illustrates how strategy guides other DM 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 DM. 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 [see (Aiken, Allen et al. 2007) for more detail] to achieve greater maturity. Increased maturity leads to increased data leveraging opportunities.
5.3.5 CDO Position Description
We have included a CDO position description that has allowed a number of our clients to recruit and hire satisfactorily qualified candidates.
TITLE: CHIEF DATA OFFICER
REPORTS TO: TOP JOB
POSITION SUMMARY:
This position has the overall responsibility for team-lead definition, engineering, and execution of organizational real- and meta-data architecture strategy including the planning, funding, training, development, integration, deployment, recovery, and evolution functions that are required to effectively and efficiently deliver data architecture components that tangibly support the implementation of the organization’s strategy.
RESPONSIBILITIES:
1. The position directs program-wide coordination of organizational data architecture activities to ensure maximal support for the overriding concern – participating in the achievement of the business strategy. This includes ensuring that:
• Organizational data architecture activities are practiced in a coherent and coordinated manner – by defining, coordinating, resourcing, implementing, and monitoring organizational data architecture program strategies, policies, plans, etc. as a coherent set of activities beginning with the organizational data strategy and extending to all aspects of communication and execution including leveraging data assets to cut costs, accelerate growth, and foster innovation.
• Existing data is culled and specific subsets are selected to enhance their fitness for use.
• Data governance functions as the primary vehicle for implementing organizational data architectures. Data governance ensures that organizational data architectures remain efficient/effective and business driven. Data governance is recognized internally as the source of organizational expertise and best practices in governing the organization’s information assets (such as use of standards). The data governance organization approves the data governance strategy, secures funding, and determines budgets/priorities for organizational information architecture.
• Organizational data architecture integrates itself into the existing architecture enhancement and application systems development processes in a manner that allows for synergistic growth with other architecture disciplines and that result in methods to continually advance organizational architectural capabilities.
2. Ensuring that the organization has an optimized, flexible/adaptable data distribution network (DDN) that is capable of delivering data in response to changing business dictates. DDN evolution is accomplished by identifying, modeling, coordinating, organizing, distributing, and architecting data shared across boundaries. The goal is to architect the improvement of organizational data exchange processes between programs, within organizational units, and between the organization and its business partners. The effectiveness of this DDN is the currency of organizational information architecture and this group must become recognized internally for its expert data delivery capabilities.
3. Ensuring that specific individuals are assigned the responsibility for the maintenance of specific data items as organizational assets, and that those individuals are provided the requisite KSAs to accomplish these goals in conjunction with other data stewards in the organization. A strong governance/stewardship program ensures the development of organizational expertise and requires all participants to have up-to-date knowledge, skills, and abilities.
4. Continuously improving the effectiveness and efficiency of data delivery systems including database technologies, virtualization, services, etc. This involves specifying and designing appropriately architected data assets that are capable of supporting organizational needs using appropriate technologies and architectural patterns (cloud, SOA, MDM, warehousing, etc.). This must be accomplished with regard to and anticipation of future technology trends.
5. Governing the architecture and integrity of all real- and meta-data assets including: the initiation, operation, tuning, maintenance, backup/recovery, archiving and disposal of data assets in support of organizational activities. Responsible for ensuring that the data assets are, and will be available for required business purposes under various evaluated risks (business continuity/disaster recovery).
REQUIREMENTS:
Must be results oriented with superior leadership skills to inspire and motivate staff.
Demonstrated critical thinking skills, excellent communication, interpersonal relations and negotiation skills are essential as well as strong administration, organizational, analytical and problem solving skills.
Supervises and is responsible for overseeing work that is highly complex and varied in nature. Develops integrated solutions to achieve highly complex technical and business objectives. Must be a subject matter expert and have a strong understanding of present and future data utilization. Must have direct experience in data architecture, modeling, integration, design, quality engineering to implement various data strategy components. Must demonstrate success in planning, development and support of data infrastructure-based support for the company strategy.
Position requires a bachelor’s degree in Computer Science, Information Technology or related field (advanced degree desired), ten to fifteen years of progressive responsibility including executive leadership ability. CDMP preferred!
5.4 The Perhaps Temporary Nature of the CDO
It should be noted that 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% on organizational data issues.
Our 2013 research indicates that 53% of organizations recognize the need for a CDO but have not yet started the process of establishing the position. 5% indicate their CIO is covering these responsibilities and 8% indicate someone besides the CIO is accomplishing data asset leveraging. 7% were in the process of establishing or hiring their CDO. 1% believes that data plays a role small enough to not warrant a CDO.
For the other 99% we believe CDO should examine your data operating environments with an eye toward improvement.
5.5 Chapter Summary
The CDO – where and what?
Where: the chief data officer must not exclusively report to IT – this content and subject matter knowledge exists outside out of IT. The CDO should report at level comparable to the chiefs of your other organizational resources.
What: Data-centric practices form the data advantage needed by the organization and can be boiled down to the top three items: