Information Technology Reference
In-Depth Information
Data Replication and Master Data Management
One of the common mistakes possible when implementing an IAM system is
to duplicate information across more than one repository, with an excessive
reliance on product-based replication mechanisms to keep them in sync. This
is highly error-prone in practice and will be a perennial source of
maintenance headaches.
Our recommendation is to stick to well-understood principles of Master Data
Management (MDM):
Identify the application or system that is the “source of truth” for each
data item. This system should be the only one that creates, updates or
deletes this data item.
Try and store each data item in only one place. The most natural place
to store it is local to the system that is its “source of truth”.
Try to avoid replicas of any data item. If possible, let other systems that
need access to this data item query it directly from the source of truth.
If it is too cumbersome or it creates unnecessary dependencies to force
such queries back to the source of truth, then consider storing a read-
only replica of the data item locally with some strict rules around its
management.
Needless to say, read-only copies of data items must never be updated
locally. They can only be periodically refreshed from the source of truth.
In an ideal world, all systems that store user data will maintain a “User
UUID” candidate key into each user record. This will be used as a reference
key whenever a source of truth for any user attribute wants to propagate
updates to that attribute to all other systems that may maintain a copy of
it
39
. When we talk about User Provisioning as part of the Identity
Management capability of IAM, we will describe how this can be made to
work elegantly.
39
For systems that cannot hold a UUID reference, the IAM Associated System table
will provide the local user ID as the key to be used by that associated system for
performing these updates.
