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
posted by Evert Ruijs @ 10:34 AM
0 Comments:
Post a Comment
<< Home