We recently bought a new washing machine, made by a respected European manufacturer with a reputation for quality. Nevertheless, we decided to go for the extended warranty, as it was a (surprisingly) good deal. The process for obtaining the warranty was straightforward, and the certificate we needed arrived in the post.
We actually received an envelope containing two separate letters. The first letter thanked us for buying the extended warranty, and was accompanied by the receipt. The second letter also thanked us for buying the extended warranty, and was accompanied by a certificate.
So, where’s the confusion? The two letters both told us what to show to the engineer if we ever made a claim under the warranty; unfortunately, they tell different stories. The ‘receipt’ letter tells us to present the warranty certificate and the original proof of purchase, whereas the ‘certificate’ letter tells us to present just the certificate. I expect the latter rule is the correct one, as we had to supply proof of purchase to get the warranty in the first place.
How could such a confusion arise? The two letters were probably produced by different systems, each working with its own set of data and rules, managed via some form of integration architecture – the data on the letters was consistent, so that part worked OK. It’s possible that neither of these two systems plays any part in managing warranty claims, so there must be another system (and associated procedures) that actually implements the ‘Make Claim on Warranty’ business process. The issue here is that part of the procedures for that business process has been described in the two letters we received. Perhaps the procedure changed at some time in the past, the impact of the change was assessed, and only one of the two letters was output from that impact analysis, so only one letter was amended? If that’s the case, then the appliance manufacturer needs to re-assess their metadata management capabilities. They might also need to change the way they manage their business rules, but that’s not the target of this particular blog post.
I’m not really surprised at the scenario I’ve just described, as very few organizations have solved the problems of metadata management to this extent. You can’t prevent issues like this easily; in a complex business, you would probably need to integrate two or more disparate metadata management tools, business rules management tools, business process management tools, and modelling tools. By the way, I’m not restricting myself to ‘data about data’ when I say ‘metadata,’ I’m thinking much wider than that.
Perhaps Terry Pratchett was right, and this is the Century of the Fruitbat?