Page 130 -

94 Enterprise Data Governance

specific hard-coded developments required for the
management of the states; business users are unaware of the
existence of these states. The business objects’ states are
buried in opaque software;

– this MDM system is unable to detect certain update
errors due to the fact that it fails to take business objects’
states into account for validation purposes at the moment of
data updates. This gives rise to poor data quality, with
serious risk of distributing that bad data to the heart of the
systems using them.

These risks are not taken into account by the maturity
level of the static MDM. It does not see business objects’
states as master data itself. It is a weakness that can prove
fatal. A static MDM is only valid if the system can ignore the
states of the business objects. This can be acceptable for rare
types of data which have simple structures and are outside
the core of business objects, such as, for example, lookup
tables for codes and labels.

IT specialists can be deceived by this form of MDM
system. At the beginning of the process they may be
convinced that static management of the data is suitable.
However, at the time of user acceptance testing, and under
pressure from their business users, they might be forced to
add, in a way that is both rushed and insufficiently analyzed,
data integrity rules and validation on the edge of the MDM
system, i.e. by hard coding software developments outside
the data repository. At that stage, it is too late to carry out a
formal analysis of the states of the objects. In this kind of
scenario the failure of the MDM system in the medium term
is a risk: complex processing, added on the periphery of the
data model, renders any real administration of the data by
business users impossible.

Knowing the data also means understanding and
mastering the data validation rules, and these often take