view, effective means that it is both fit for purpose in the current situation but also in the future. This is closely related to the notion of antifragility as introduced by Taleb in [Tal12]:
Some things benefit from shocks; they thrive and grow when exposed to volatility, random- ness, disorder, and stressors and love adventure, risk, and uncertainty. Yet, in spite of the ubiquity of the phenomenon, there is no word for the exact opposite of fragile. Let us call it antifragile. Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better.
Antifragility is not an easy-to-understand concept and is easily confused with robustness. A characteristic of robustness is that it is capable of handling a certain level of stress. Or, more aptly formulated, it is designed and built to handle a certain level of stress. An antifragile system, by contrast, only gets better when more stress is experienced, as illustrated by example 9.
Example 9. Antifragility
A first example of antifragility comes from children at play. Children will very quickly learn how to deal with unfairness, uncertainty and failure. For many children, experiencing these things a few times will help them build coping mechanisms, which makes them better prepared for the future.
Similarly, in business as in other situations, professionals who experience failure (defined as: not reaching a predefined goal in the allotted time with the allotted resources) repeatedly will build resilience and character, and this will give them the experience to do better next time.
When building/ improving a data management capability, I believe that antifragility is a good quality to strive for. In my mind it captures the essence of what you want to achieve: a DM capability that gets better and better as a result of it being “used” and “tested” in practice. This is a guiding principle for the good practices in part II of this book.
■ 4.8 VISUAL SUMMARY
1 It is often argued that it is impossible to be fully objective when observing or researching a domain. For example, [McG83] claims that the only things humans can do objectively is counting, and even that is open to debate. The point that I am trying to make is that I will attempt to give an overview of what the theory says about each of the functional fields without going into practical recommendations.
2 In [Dat12], C. J. Date explains that tables are not the same as mathematical relations but people have come to think of them like this. If you are interested in database design, I highly recommend this book.
3 An “enterprise” or “organization” is seen as a system.
4 Cynefin is a conceptual framework for sense-making and decision-making, developed in the 1990s.
In the upcoming chapters, I will discuss the theory of data management by giving an overview of the relevant terminology and a discussion of key data management topics. Each chapter discusses a single data management capability. The chapters are based on theory (the DMBOK and other sources), as well as my experiences in the field. Throughout these chapters, I have included many examples to illustrate key points, as well as brief interviews with people from the field. In this way, you will get a good overview of the field.
I have used the following principles for structuring part I of this book:
■ Each chapter is kept as short and to the point as possible, as I am trying to convey the main points rather that give a complete coverage of a specific topic.
■ There is no single best way to implement data management in an organization. Each organization is different. This implies that processes, roles, and responsibilities will be different in each organization. Therefore, I focus on the key concepts and shy away from guidance/ definitive statements on “who does what”. This is partially covered in chapter 33 in part II of this book.
■ Data management is not an “isolated capability”, meaning that its processes, roles, responsibilities, and tools are highly connected to others. I have included brief discussions to key topics related to data management in several chapters. For example, the chapter on data governance has a link to IT governance. These discussions are kept deliberately short in order not to over-emphasize their importance.
Before diving in, I would like to stress that these chapters are very much connected and equally important. I have strived to give each topic equal attention. The discussion is deliberately neutral and avoids implementation recommendations. These are left for part II of this book.
Synopsis - Professionals in the field of DM/ IT use a specific lingo. Unfortunately, the terminology is not as standardized as I would like. In this chapter, I will give an overview of the most important terms as they are used in this book.
■ 6.1 INTRODUCTION
Professionals in the DM/ IT field have a reputation for being precise and consistent. Since this is the case, you would expect that terminology used would also be highly standardized and precisely defined. A careful study of several International Organization for Standardization (ISO)/ International Electrotechnical Commission (IEC) standards such as [ISO07, ISO12, ISO15] and comparison with the DMBOK and TOGAF [Hen17, The11] shows that this is far from the truth: the terminology is vaguely the same but precisely different.
In my view, this is a bad thing: how can we successfully engage people who are not so data-literate when we cannot agree on basic terminology? At the same time, I am very much aware that changing how people use language is far from easy. The purpose of this chapter is to introduce the terminology that is used in this book. The guiding principle is to align as much as possible with the aforementioned standards.
A small warning: defining terminology is both an art and a science. The text that follows is a little more academic in nature than in the rest of this book.
■ 6.2 DATA CODIFIES WHAT WE KNOW ABOUT
