is related to building a DM capability that is “just right” for the needs of the organization. In many cases we see that this capability is over-engineered or too focused on implementing tools that will act like a silver bullet and make all the problems go away. The purpose of part II of this book is to show how specific topics in this category can be solved by building the DM capability one step at a time.
■ 3.4 VISUAL SUMMARY
1 The phrase “boil the ocean” is a colloquialism that refers to taking on an overly large and potentially impossible task given the reality of your resource.
Synopsis - This book is about data management, so I will position data management as the center of the universe, at least as far as this book is concerned. In this chapter, I will clarify the role of data management, by relating it to other (management) capabilities such as business process management (BPM), enterprise architecture, and IT management. I will also briefly discuss the philosophical considerations related to the challenge of building an effective data management capability. I will base this discussion on the Cynefin framework and the concept of antifragility [SB07, Tal12].
■ 4.1 THE CENTER OF THE UNIVERSE
In the introduction of chapter 2, I presented an analogy between processes as the value creation engine of the organization, and data as the fuel for this engine. The point of this analogy is that it is hard to meaningfully separate the two, as “data” and “process” are so intertwined. Yet, this book is about data management (DM) so this topic will be front and center in most of this book. More specifically, in part I, I will discuss DM and its functional areas from a theoretical perspective. I will attempt to do so in an objective manner1. In part II, I will offer good practices for building an effective data management capability.
While DM is important, it can hardly be discussed without considering its context. For understanding DM from a theoretical perspective, as well as for designing a program to build or improve a DM capability, it is recommended to take a systems perspective of the organization, meaning that (1) we should consider the organization as a system that operates in a specific context, (2) we should consider all relevant perspectives on this system as determined by key stakeholders, and (3) we should consider both structural properties of the system (i.e. how is it organized? Which “parts” can we distinguish?) as well as how it behaves (i.e. what happens in the organization? How does it behave in relation to its environment?).
With this in mind, I will position DM in relation to other (management) capabilities in the upcoming sections, keeping in mind the “golden triangle” in our field: data (DM), processes (business process management -BPM), and systems (IT management). I will also discuss two topics that are closely related to, or even part of, data management, but that did not get chapters of their own: information/data analysis, and database management. The section on enterprise architecture management will tie these three perspectives together. Figure 4.1 clarifies this further. I will also offer a philosophical consideration on the complexity of building or improving a DM capability as a backdrop for the chapters in part II of this book.
Figure 4.1 Positioning data management
■ 4.2 DM AND BUSINESS PROCESS MANAGEMENT
Business processes form the value creation engine of the organization. Many definitions have been proposed in literature and common characteristics of these definitions are: (1) processes consist of a series of steps, (2) processes are executed by (human/ computer/ machine) actors, (3) processes are executed to achieve a goal, (4) processes may or may not be designed (i.e., some processes are ad-hoc, others are executed along the lines of a pre-design “script”), and (5) processes may or may not be described in a process model. Business process management originated in and became popular in the 1980s and 1990s and encompasses techniques such as Lean and Six Sigma. An abundance of literature is available on (successful) business process management (e.g. [Wes07, SqE08, Kir09]).
The premise behind business process management (BPM) is that the activities of the organization should be coordinated in such a way that strategic outcomes are achieved and that resources (people, time, money, materials) are used as effectively as possible in achieving those outcomes. Processes transform inputs (e.g. a frame, wheels, saddle, etc.) to outputs (e.g. a bike). Increasingly these inputs and outputs are also “informational”: data about which parts are used, who did the assembly of a (physical) product and when, are common examples. For many organizations the inputs are solely informational in nature: for example, banks and insurance companies do not have a physical/ tangible product that is created. Instead, they offer services to their customers, and data (about customers, products, financial positions, market conditions, etc.) are the “fuel” for the processes.
This is also where the worlds of DM and BPM meet. From a BPM perspective you could argue that the inputs and outputs of processes are data, and since these are key to the successful execution of these processes, they should be managed accordingly. This means that we want to know what data is used where, which systems we can find it in, what the quality is, etc. Turning this argument around, you could also say that data is the key asset of the organization (chapter 2). Processes manipulate the data, and should be managed as such. This means that we want to know which processes manipulate the data, what the intended use of data is, who is responsible for these processes, etc.
It is safe to conclude that, in practice, both capabilities are important and tightly linked.
■ 4.3 DM AND IT MANAGEMENT
It appears that the distinction between data and system is difficult to grasp for many stakeholders. The stakeholders in example 8 conflated data and systems and had formed the mental image that “data cannot be to blame”: any error in the data must be caused by poor systems design, so that is where the problem must lie. There is something to be said for this line of reasoning. It makes sense from a systems perspective but not so much from a DM perspective.
Example 8. Data and systems
In the early days of a recent project, I ran into the following situation. We were trying to get an answer to the question “do our business stakeholders believe there is a data quality management problem in the organization?”
We held a series of interviews with groups of stakeholders to explore this topic. In one of the meetings, a stakeholder commented as follows: “Data quality problems? No, I don’t think we have those. We do have a lot of system problems though. People fill
