Breaking news: As I was writing the article below on MDM Best Practice #8, I realized I should discuss the acquisition of Data Foundations, Inc. by Software AG. I was surprised by how long it took for the announcement to come out, because I first heard about this transaction in June. It seems to be a good acquisition for Software AG, which had previously acquired webMethods for its B2B integration technology. I’ve been talking and writing for a while now about the need to meld SOA, business process management and MDM. Some other analysts have said that this acquisition is no big deal, that the mega-vendors are probably not worried about it. But I think it’s a great sign for the MDM market that a larger player like Software AG, with revenues of $1.17 billion, which already has strong integration, SOA and BPM products, sees MDM as a compelling market to enter through acquiring a best-of-breed player like Data Foundations.
MDM Best Practice #8 – Resist the Urge to Customize
As the various MDM hubs mature, it’s getting easier to resist the temptation to customize. When I first started working with Customer Data Integration (CDI) hubs in 2004, they were a little “rough around the edges”, and sometimes customization was unavoidable.
But we’re six years further into this now, and the major vendors’ platforms are light years ahead of where they were in 2004. At this point, working with the vendor to improve their product in future releases is a better strategy than customization.
And most products allow you to modify the underlying data model – and the various flavors of the user interface – without touching the source code. This is a big improvement, because most of the times, the changes needed by the business are relatively minor – a few new fields here and there, some new reports of course.
One important thing to include in your evaluation of vendors’ platforms is how easy it is to “settle into” the platform – to make those minor changes and to adapt the platform to the way your organization does business. If the platform seems like it would difficult to adapt in this way, consider that a warning sign.
If you do have to customize, do it carefully; make sure your changes will survive an upgrade gracefully and are well documented.
One of the biggest risks is getting “rev locked”. The MDM vendors are still revving their products once or twice a year, so you don’t want to get stuck on an older version. I had one client that was told by their vendor that their technical problems were fixed in the latest release. Unfortunately, they were told by their internal team that the earliest they’d be able to upgrade to that release would be in about 18 months!
One way to avoid this is to build what I call “upgrade competency” into your project and your team during your initial implementation – so you already have one upgrade under your belt during your implementation life cycle. That way, the upgrade process isn’t quite so daunting.
The next article in the series is: MDM Best Practice #9 – Don’t Underestimate the Complexity