Technology again
MRD management turns quickly into an overengineered cottage industry. You cannot imagine the number of components that make up a good MRD service - here to name a few: a data store supporting flexible data models that can keep track of every change in every attribute (and maintain their history), message-based integration to any other data store subscribing the with MRD content, workflow for the MRD maintenance, roll-back capability if something goes wrong in the process, attribute level security, ... etc etc etc. All great, but do we really need it, or is this becoming architecture for architecture sake? Personally I think this is MRD in the hands of technology-people and not MRD for the sake of better integration & quality. So my advice would be to start from the ground up and see what the requirements are one by one. Addressing them is usually possible in the existing systems. When the requirements for the services grow, then migrating to a generic MRD service may become an opportunity, but not as a start!
Labels: master reference data
Types of Master reference data
I have been pulled into some detailed discussions on Master reference data management and through this it occurred to me that there are different types of data that need a different treatment. Here are a few examples:
- The first type I would like to call 'external standard lists' - this is the reference data for which we already have (international) standards (like ISO). Examples are Countries, Post codes, Units of Measure, Language codes. Characteristics: Standard is defined, source is outside the company, no debate necessary. Approach: Just identify the data type and agree to use the standard from now on. Even better is to make it centrally available as a service.
- The second type is similar - but I would call them the 'internal standard lists' - things inside the company for which you like to have an agreed enumerated list - i.e. a fixed domain. Think about standard lists for security levels, status codes, ... Characteristics are: Standard is usually a lot harder to define due to debate from different stakeholders, while this debate is not really adding a lot of value. Approach: Identify the data type, propose a standard after analysis. Challenge the parties to make a case if they don't think they can comply to this standard. Make the standard lists available as a service.
- Third is a type you should skip and this is the set of items that people think as common attributes, but which are actually not manageable. Think about document types (everybody has a different opinion), keywords, names of project teams (too many!), etc. It is hard to define this category, but it is usually about lists that change constantly, that do not have a clear source or owner and where there are no clear definitions (or where it is just over the top to manage it as reference data!). I see a folksonomy as a good alternative for this category.
- Finally the fourth is the most important category - and that is for objects / things / people shared across the company the 'master reference objects' - this data you probably already maintain in one place or another and the trick here is to get agreement where you have the master etc. (stuff I covered before). Note that these objects can be organised in hierarchies - which in themselves can be seen as reference data (but lets leave that for now!)
Labels: folksonomy, master reference data
