Читать книгу Data Management: a gentle introduction - Bas van Gils - Страница 21

As you will see in part I of this book, the field of DM covers many subjects, called functional areas. Because of this, people tend to call DM a complex field. In this section, I will discuss whether this claim is justified. I will use the Cynefin framework⁴ as a theoretical foundation [SB07]. In this framework, five “problem solving modes”, or “problem types” are distinguished, as shown in figure 4.3.

Figure 4.3 The Cynefin framework, based on [SB07]

■ Obvious - For problems in this domain, a best practice is immediately clear. In this domain, as soon as you recognize the problem (“it is one of those”), then you’ll know what to do. Here, the relationship between cause and effect is evident. A good example is the situation where you want to ensure that data is available for review later: you store it and make sure that there is a backup available.

■ Complicated - In this domain, there is no immediate apparent solution to the problem at hand. How- ever, it is possible to discover the solution through careful analysis. More formally, the relationship between cause and effect can be found through analysis by someone with the required expertise, thus uncovering a good practice. A good example is building/ debugging a software system. There are many interlinked parts in a software system but you know that, given enough time for analysis, you will eventually discover how to fix the system and make it do what it is supposed to do.

■ Complex - This domain is characterized by the fact that the relationship between cause and effect can only be discovered in hindsight. In other words, no matter how strong your analysis capability is, the very nature of problems in this domain is such that no best/ good practice can be determined a priori. In this mode, you develop a hypothesis of what could work and only by trying out this hypothesis can you discover what works. In this domain, we speak of emergent practices. A good example is a merger of two organizations: no matter how careful you plan, you cannot predict the final outcome. All you can do is hope that the interventions that you designed (hypothesis) work out for the best.

■ Chaotic - This domain, is characterized by chaos and panic. There is so much going on and at such a high pace, that time for analysis and rational planning is lacking. What is required is decisive leadership and action to return to a more stable (simple/ complicated/ complex) state. In this domain we speak of novel practices. A good example is the situation where the systems of a company are breached, customer data has been leaked at a massive scale and, as a consequence, investors are dumping their stock – threatening the future of the organization. This is bound to lead to a panic. One of the first things that is needed here is decisive leadership to help “cool off” the situation. Only then can more rational, analysis-based methods kick into place.

■ Disorder - This domain represents situations where it is unclear which of the other four domains are relevant. Usually this is because the decision maker/ analyst is still trying to get a sense for a specific situation and needs more evidence to come to a meaningful conclusion.

This framework can be used to analyze the implementation of DM in practice. In other words, it can be used in the context of part II where I present use cases around building or improving a DM capability. In my view, the obvious domain is not relevant for this discussion: aspects which are so simple that the solution is immediately obvious have no place in this book. Similarly, the chaotic domain also has no place in this book: when the existence of the organization is at stake, then DM practices are unlikely to save the day. This means that only the complicated and complex domains are relevant for this discussion.

Many tasks in the DM realm fall into the complicated domain. For example, documenting which data is in which system, or how data is combined to form new data might be much work, but with careful analysis and enough time and resources, it can be done. Key to success for these tasks is to have enough skilled professionals with the right tools and an incentive to “make it work”.

A large part of the work, however, is in the complex domain. As soon as people, their work, and their behavior are involved, you enter the complex domain. Human behavior, especially when considered in the social context of an organization, can’t be analyzed to the extent that the ultimate solution to a problem can be found. Borrowing from the work of Morgan, I would argue that a machine or engineering perspective of the organization is likely to lead to disastrous results when used to implement the DM capability [MGR97].

A more “human” perspective (the organization as a social system or the organization as an organism) – is likely to yield far better results. These perspectives do more justice to the fact that DM tools and techniques should be fitted to what is already present in the organization and should take the culture, beliefs, concerns, and social setting of the organization into account.

Considered as a whole, I believe that building/ improving the DM capability in an organization is definitely in the complex domain and that the only way to succeed is to adopt a people-first approach to this task. This will be a major theme in part II of this book.

The ultimate goal is to build an effective DM capability. In my 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.