MDM Architecture (or FAD)

I've been away from the blogsphere for a while as I currently working on a new book on the subject of Master Data Management. One of the ideas I've been developing is around what are the key principles that underpin an MDM solution? I believe that these principles can be summaries within four words; Flexibility, Authority, Decoupling and Secure or FADS for short. The word FADS is used because it reminds us that unless we adhere to the underlying principles of the MDM architecture the MDM component will become an out dated concept (or a fad).

Flexibility

The MDM architecture should have flexibility built into it. By this I mean the following:

·         The design of the solution should be able to handle change to master data, master data definitions, business needs and legal changes.

·         It should make use of industry standards to ensure that the use of multiple technology (and changes in technology) can be accommodated. This will also ensure that the rollout is easier as less pain will be felt integrating with variety of vendor software packages that can typically be found across most organisations. Standards don’t need to be technology based they may represent coding standards from standards bodies such as ISO.

·         It should be based on the concept of re-use. This means that sub components should be designed to be re-useable and also existing systems should be re-used within the MDM architecture if they can add value.

·         It should be possible to incrementally develop the MDM solution rather than have to embark on a big bang approach. This allows business value to be realised quickly whilst building towards the final end state.

·         It should be based upon consistency in the architecture. By this I mean that the architecture should be based upon the whole end state at least from a logical and conceptual level resulting in a reducing design conflicts.

Authority

For our MDM solution to be valuable to the organisation and treated as the single source, or golden source of truth, it needs to have authority. By this I mean:

·         That not only should it handle the dissemination of master data across the organisation. But it should disseminate data that everyone believes/knows is correct and has known providence.

·         The master data should also have identifiable business value. There is no point in building an MDM system as a pure IT initiative as the value of master data is in its business usage.

·         Ownership of data needs to be clear and managed through the system.

Decoupled

Master data is used throughout an organisation therefore it becomes important to create an architecture that can handle to variety of technologies and changes of technology both within the MDM environment and within the wider enterprise. A decoupled architecture gives us a framework that allows components to remain completely autonomous and unaware of each other. By decoupling the MDM solution we make it available as a data asset that can be used by any part of the organisation.

Secure

Under secure we have a number of areas to consider:

·         System security so that the users (and interacting systems) are only allowed to access data that they have authority to access in the mode they have authority to work in.

·         Data privacy issues need to be identified and managed. Legal/ ie data protection act.