Last week, when I wrote about Microsoft's foray into master data management, I admit I wasn't impressed - and I didn't think the analyst reports were either. After all, this is Microsoft, so it's hard not to expect big things, but the MDM tool, called Microsoft Data Services, sounds a bit bare bones.
But then again, this is Microsoft, and in many ways, bare bones is what Microsoft does best. Excel is hardly a full-blown business intelligence tool, and yet, it's the default BI tool for many organizations. And as someone who's used specialized design software, I don't even want to think about how many businesses daily use Microsoft Word as their primary graphic design tool.
Sometimes, the basic tools are actually the most flexible. I was reminded of that recently by Akiva Mark's response to my post on MDS, which is bundled with SQL Server Enterprise edition and Datacenter edition.
Marks has been in IT for some time now-25 years, according to his bio. He's worked in both Israel and the United States on various IT initiatives, including running an integration competency center and working with SOA. In other words, he's got a lot of experience.
Marks took exception to my post, in which I reiterated Andy Hayler's point that MDS's exposed API allows ISVs to build add-ons for the tool.
True, it will do that, Marks points out. And that's a good thing. But it's not all the exposed API will allow, and to suggest otherwise, he says, is to engage in "some old school thinking."
I know. It's kind of the ultimate techie insult, isn't it?
But he makes an excellent point. Where I saw a weak entry into MDM, Marks sees an incredibly flexible tool that reflects a natural evolution from Microsoft's history of component-based development toward SOA. He points out it fits in nicely with the rest of Microsoft's solutions, but more significantly, he discusses how that exposed functionality can give architects more options:
So when Microsoft says their MDM tool is exposing its functionality via an API layer (SOA based I hope), my thought is how I'll be able to orchestrate that functionality into business solutions I'm architecting, and how well they'll fit various BPM processes being created. Extending the application is nice, decomposing the application into function modules (with an easy to access open standards SOAP API) is Service Oriented Architecture. In this area Microsoft's thinking is way ahead of the competition.
That's the thing about Microsoft, it o ften seems to be following, but end up leading, or leading the majority. So check out Mark's arguments for MDS, particularly if you're already invested in other Microsoft solutions. While you're there, skim the rest of his excellent and very readable blog.