In this quarter’s column for TDAN.com, I would like to share an excerpt from a book that just recently released: Data Strategy and the Enterprise Data Executive by Peter Aiken and Todd Harbour.
I found the book comprehensive yet easy to digest. Below is a subset from a chapter on “The Data Doctrine”.
The Data Strategy
Today, more organizations consider strategic planning to be a task for top management. Despite great personal commitment of those in charge, results have often been unsatisfactory. Such strategies are not sufficiently based on realities and true environmental complexities to create success in a competitive environment.
The following comments address some of these common impediments to developing an effective and successful data strategy.
- No Existing Data Governance. Organizations suffer from excessive compartmentalization, which leads to narrowly-focused governance and parochial definitions that represent only a selected organizational population. The problem only worsens with the advent of big data, cloud deployment models, mobility, and social data (Buytendijk, 2015).
- Too Many Strategic Documents. There’s too much strategy documentation, and it’s generally poorly-coordinated—and often contradicting. This happens especially in larger organizations where different organizational units at different strata produce different strategic documentation at different times (Grunig, 2015).
- Overdependence on Technology. Traditional IT leaders tend to be project-focused rather than data-focused. This typically means that conflicting data definitions are created during each project, as per the traditional way that projects operate.
- Vague Authority and Accountability. Responsibility, answerability—and thus justification—are essential to successful execution. Because of this, organizations must ensure that roles, responsibilities and reporting lines are determined, designed, documented and delivered to staff using more “pictures” and fewer “words” to all stakeholders (Latif, 2013).
- Lack of Planning. In many organizations, leadership is more focused on performing day-to-day activities than planning for the future.
- Lack of Commitment. Leaders must be committed and remain engaged throughout the entire data strategy development process. When management fails to take interest in the formulation and iteration of strategy, other problems will quickly follow.
- Inflated Expectations. Managers fail to adequately estimate the training for employees to implement the strategy. Not only does this cost more and take longer, it also creates organizational tension if end users become frustrated with the pursuit of assigned objectives designed to achieve strategic goals.
- Lack of Decision-Making Protocols. To ensure that employees take part in the planning process, introduce and implement change management methodologies so that engaged employees can both offer and receive feedback about expected outcomes.
- Inconsistent Vocabulary. Few organizations use a common language to describe business information or the semantics and syntax surrounding it. Instead, different, divergent and sometimes conflicting words are used throughout the organization to describe the same relevant, real-world phenomena. This situation poses significant obstacles for information technology
- A cogent, crisp, and concisely-written summary of the data strategy lays the foundation for correctly positioning groups, individuals and processes across organizations.
- Lack of Perceived Value. Each organization inherently develops a value system that generally is reflected in its mission and the goals and objectives established to achieve it. Only when the value assigned to data reflects its significant importance will leaders avoid the risk of encountering conflict with IT efforts. (Carnegie Mellon University, 2014).
- Lack of Effective Communications. Promulgation is the act of formally proclaiming or declaring a new policy after its enactment. Published policies, standards, and other guidelines should be readily available to members of the organization. Often this is accomplished through a centralized electronic library (Carnegie Mellon University, 2014). For example, the organization’s foundational business glossary can be made available electronically to employees who, though sharing data, often use different terms or phrases to refer to the data values being shared. Centralization of this information permits one-stop-shopping for the latest version of both terms and adopted definitions.
Organizations need to ensure their data strategy is aligned to the organizational strategy before considering any software acquisition or development efforts. Moreover, well-engineered data structures are needed to support organizational strategies. Because data structure changes, it is important to carefully manage software, its code, and physical definitions. As a best practice, then, organizations need to ensure that data architecture is flexible and adaptable, and that projects include consideration of explicit data costs as part of their operations and maintenance estimates. And finally, organizations should focus on reducing data ROT, improving quality, increasing security, and expanding data reuse.
The Data Doctrine
If you recognized your organization somewhere in the previous lists, you will be happy to learn that there is hope. In this section, because improving software development aspects of systems development is a good and necessary step, we present a necessary supplement to the Manifesto as it is insufficient by itself. More is needed. Embracing the Data Doctrine (Aiken & Harbour, 2017) will result in more concrete, improved and important systems components resulting in enhanced Agile efforts.
As a class of assets, data has not been leveraged anywhere close to its full potential to support organizational strategy because:
- data management and software development have not been separated and sequenced;
- data structures have not been stabilized before software is given access to them;
- shared data structures lack programmatic development and evaluation; and
- reusable software has been valued more than reusable data.
Most organizations have been unsuccessful at implementing an effective data strategy for one of these reasons. Moreover, data leveraging efforts have suffered because organizations do not employ data-centric thinking. Part of the challenge is the fact that we have had trouble correctly conceptualizing the challenge. Figure 6.1 illustrates a common description of system components which normally includes people, processes, hardware, software and data. This representation is misleading, however, in that it shows all components as being equal. This is especially not true for the relationship between software and data. Because of the increasing Vs (see again, Chapter 2), data fundamentally requires engineering-based, and increasingly science-based processing.
Figure 6.1 Primary system components
Google the term data-centric thinking, and a variety of different responses appear in your browser. As of this writing, no standard or consensus-based definition has appeared in academic or other popular literature. Therefore, we offer the following for others to review and improve.
Everyone needs to possess an objective, baseline understanding of data-centric thinking to have a standard against which to compare observed practice. Because the educational system has been disconnected from real-world data practice, data and its management have progressed slowly from an academic perspective. Resulting vagueness has led to misunderstanding both data and its role relative to projects, information technology, organizations, and society in general.
Note: We commend the “data first” approach to software development as a step in the right direction. See, for example, the discussion at http://bit.ly/2mEpHbW.
Figure 6.2 Foundational Value Assertions of The Data Doctrine
We offer The Data Doctrine as a plan for data-centric development of business and IT systems. We intend to maintain this discussion online with dialog dedicated to improving the overall articulation of the Doctrine. Figure 6.2 presents the primal assertions of the Doctrine.
