Analyst Days 14: Don't Paint the Grass — Data Risk in a BANI World

In May 2022, I presented “Don’t paint the grass or the truth about the value and risks of data in the BANI world” at Analyst Days 14. The conference took place on 27–28 May in Moscow.

This is a reconstruction of the talk, revised on 21 October 2026 and supplemented by later professional experience. The original publication date of the text has not been established. Examples are generalised, and internal measurements and system scale are deliberately omitted.

What “painting the grass” means

The metaphor describes a gap between reporting an activity and operating a control. A data-governance policy may be approved and a catalogue launched, yet nobody can name the owner of a critical measure. The initiative exists; the risk remains.

The alternative is not a perfect dashboard or a large toolset. It is a small set of practical properties:

• critical data has an owner;
• the meaning of a measure is agreed;
• quality is measured;
• sources and transformations can be traced;
• an error is detected before a user complains;
• a quality breach triggers a defined action.

When those properties work, documentation becomes a useful consequence of governance rather than a substitute for it.

BANI as a set of questions

BANI is Jamais Cascio’s framework for discussing a complex environment, described in his 2020 essay Facing the Age of Chaos. I used it not as proof or a replacement for analysis, but as four groups of questions.

Property	Question for the data environment
Brittle	Which dependency can create a cascading failure?
Anxious	Which missing evidence prevents a confident decision?
Non-linear	Where can a small error materially change the outcome?
Incomprehensible	Can we explain how the result was produced?

The model is useful while it leads to a specific check. Saying that “the world is BANI” does not improve a control.

An illustrative error chain

Consider an organisation where employees record customer visits and those records feed a demand forecast.

If the system accepts invalid location data or copied visit notes without verification, the error moves downstream: activity is overstated, the forecast changes, and procurement uses a distorted picture. No component needs to crash. Each one can successfully execute the wrong scenario.

This is a composite teaching example, not a claim about a particular company or workforce. Its purpose is to demonstrate the GIGO chain: Garbage In, Garbage Out becomes a management issue when later decisions amplify the error.

Controls belong at several points: event validation, duplicate detection, distribution checks, ownership of the business rule, and feedback from the actual outcome.

The banking context and Mirion

From 2021 to 2023, I worked with the Mirion graph platform and Big Data application services. One class of problems involved matching entities across several attributes and developing the idea of a golden record.

The underlying problem is common in large organisations. One customer or counterparty can appear across systems with different names, addresses, and identifiers. Matching only on exact strings can leave records of the same entity unlinked; an overly permissive rule can merge different entities.

A graph model and a set of attributes support the investigation, but management decisions remain essential:

• who defines the match criterion;
• which system owns each attribute;
• how disputed pairs are reviewed;
• how false matches and missed matches are measured;
• who approves a rule change for production.

This case belongs to Mirion and the data work of that period. It is not a description of either the early real-time product or the new Decision Engine.

DAMA and ISO are frames, not finished processes

DAMA-DMBOK maps areas of data management including governance, architecture, modelling, quality, master data, metadata, integration, storage, and security. An organisation does not have to implement everything at once. A better starting point is critical data and a risk already affecting decisions.

The ISO/IEC 27000 family concerns information-security management. It helps structure confidentiality, integrity, availability, access, and risk. It does not replace data governance or define the business meaning of a measure.

I use these frames as maps of questions, not evidence of maturity. A policy or certificate alone does not prove that a report value can be traced to its source.

A minimum data-governance review

1. Critical objects and owners

Which data affects customers, money, regulatory reporting, or a key decision? Who owns its definition, quality, and rule changes?

2. Measurable quality

Critical datasets need appropriate dimensions such as completeness, freshness, accuracy, consistency, and uniqueness. Not every measure belongs everywhere; each should connect to a use risk.

3. Provenance and transformation

Can a measure be followed back to its source, formula, filters, joins, and update time? If lineage is absent, begin with a few of the most important reports.

4. Flow observability

A technically successful job does not prove data quality. Check volume, distributions, delay, and the share of default values.

5. Change management

Who learns about a schema or rule change? How is the effect on consumers tested? Can the calculation be repeated and compared before release?

6. Response to a breach

A metric needs an action as well as a threshold: stop publication, mark the data, switch a source, recalculate a period, or notify the decision owner.

Where to begin

A first practical step need not wait for a multi-year programme to finish. Choose one measure that genuinely influences a decision and follow it through the chain:

1. agree its definition;
2. name the owner;
3. identify sources and transformations;
4. define a quality check;
5. design the response to a deviation;
6. record the result so it can be maintained.

That turns “don’t paint the grass” from a metaphor into operational work. Data governance begins not with the number of documents but with the ability to explain who owns a data decision and how the team knows when it has stopped working.

---

Based on the talk about data value and risk at Analyst Days 14 in May 2022. Revised on 21 October 2026; this text is not a transcript. The organiser’s entry includes the recording.

Yours, DPUPP