Well, there's been some interesting responses to my "MDM tarpit" blog and I have to admit that I was stating a slightly one sided case—but lots of people are explaining how MDM is just wonderful so there's no point in my doing so too.

The point I will accept (and I always have) is that few companies have the luxury of starting from scratch these days—a point also made by Neil Ward-Dutton in "The need for MDM and the role of architecture"—a commentary on my piece made on his blog on this site.

Neil says at one point, "most of the most powerful forces are business forces, and in 99.99% of organisations, their power, when something really big and important happens, will trump any righteous splutterings emanating from IT departments" and at the end of his piece he says: "...have I missed the point?".

Well, yes, I think he has, because he seems to take the old-fashioned view that there is an IT silo and and a Business silo, almost in opposition (and the business gets some sort of divine dispensation for doing it wrong). His piece seems rooted in this old-fashioned siloisation of entirely separate IT and business concerns. Which is one of the routes into the MDM tarpit—like many antipatterns, it is a superficially attractive place to be, until you try to change things and need to get out of it.

In a world where everything runs on software, I don't think this sort of siloisation can be tolerated. IT isn't important in itself, it's a means to a (business) end—and it must be integrated into the business, not merely aligned with it. This isn't just my view: ITIL v3 with its focus on automated business service delivery, not just on IT automation, carries the same message (see, for example, here).

Luckily, the next generation of businesspeople have usually been educated in IT on their way up and have probably decided that pursuing a business career is more fun or more profitable than a career in IT. So the siloisation-based issue (from back from when I was a young DBA) of the IT technicians having to understand the business because the business can't or won't understand IT may be going away. And perhaps the business will now take ownership of the architect's activities as a whole—because they deliver a benefit to the business and the business is (or should be) a major stakeholder in what people think of as "IT architecture".

In other words. when the architects emit "righteous splutterings" these should be coming from within the business, not from a separate "IT group" silo. And if these "splutterings" are ignored, bad consequences will happen—not for the IT people but for the business. And, note, that I'm certainly not suggesting that anybody should pursue aspects of data analysis or architecture that can't be shown to deliver a benefit to the business, although if you work in abstractions, rather than in the physical world, and refrain from instantiating anything that isn't actually useful, the overheads of data analysis and architecture aren't exactly great.

To illustrate this siloisation issue in non-technical terms, using a rather different scenario, think of a business which wants two financial events (balancing payments perhaps) absolutely synchronised on the opposite sides of the world. This is impossible today; in the limit because of latency introduced by the speed of light (which is a lot slower in a fibre network than you might expect). No-one expects business people to understand relativity (although I suspect that a lot of them do these days) any more than they'll understand data analysis, but no matter how much people like Neil think that the business requirement should take precedence over the laws of physics, one of our two financial events will take place before the other—and the business process must take account of this. Sometimes, what the technicians tell you is correct (although it often assumes a whole-lifecycle, rather than a short-term, viewpoint) and the business has to take account of this.

So back to MDM. Yes, I agree that we can't assume that we are starting from a green-field situation, and I was rather amused that Neil used the same merger-and-acquisition situation to justify falling into the tarpit that I did in my blog. However, no matter what compromises are forced upon us, it is always better to work towards "where we want to be" rather than away from it—and this is possible if we can keep both the normative, abstracted model and the physical reality in our heads at one time. I'm not suggesting doing data analysis when it isn't useful and I'm certainly not suggesting that you leave it to the IT group alone—but the disadvantage of ignoring data analysis and making expedient short-term decisions today may be that you find yourself in the tarpit tomorrow, and getting out of it may be even more expensive than investing a little bit in avoiding it.

In other words, although a balance between theory and expediency is needed, I think that (for example) Neil's advice that "functional and business process fit should be the overriding concerns when considering buying packaged applications—it would be foolish to consider the nature of an underlying data model as a purchasing criterion" could turn out to be very bad advice indeed. However, you may only find this out when you try to integrate your packaged solution and its data into your evolving and holistic business processes at some time in the future and find that the data model your package makes you use simply doesn't fit the actual needs of your business as a whole.