searchSOA.com recently ran a five-part series examining how master data management fits with SOA. The answer, at least for SOA, is pretty straightforward: MDM can help solve that dirty data problem that SOA initiatives inevitably run into when developers give too little thought to the data behind these services. And as it turns out, more companies are using the service-oriented architecture style when building their MDM architecture, according to the article.
The article suggests combining SOA with MDM can help you succeed with both. I can't help but wonder about the wisdom of actually trying that, however, given how expensive and risky both initiatives are separately. The ROI struggles of SOA initiatives are already well documented, but by most accounts, MDM doesn't fare much better. As Brad Wright, senior product marketing manager at data integration specialist DataDirect, says in the article:
"MDM itself courts risk. Master data projects can have pretty high failure rates. It is hard."
Theoretically, it makes sense. Of course MDM would help with SOA's data problems-that's what MDM does, assuming you can afford it and get it right. And as for the using a SOA style for MDM-well, that's an architectural judgment call. After reading the article, I have to say, I wasn't convinced that marrying the two would make MDM any easier.
But, actually, that wasn't even why I was reading this article. I was reading it because it also discusses how BPM connects with SOA and MDM. That's what I really liked about the piece. It tries to show how these "big" business tech trends can fit together-if IT and business think far enough ahead to coordinate the three.
That part hasn't changed much in the two years since I first wrote about BMP and SOA's complicated relationship. In fact, just this week, senior architect and IT columnist JP Morgenthal wrote a post titled, "Keep Your SOA and BPM Initiatives Separate," in which he warns:
"This entanglement of SOA and BPM into a single effort is fraught with problems and failure. Each initiative should be undertaken separately and with definitive goals that do not list each other as one of the outcomes."
MDM is just one more reason SOA and BPM are once again on the radar together. But a recent discussion highlighted a different, perhaps more pressing, reason why SOA and BPM may become intertwined: Vendor consolidation.
ZDNet's SOA blogger, Joe McKendrick, wrote about this panel discussion in an August blog post. Dana Gardner, who lead the panel, observed vendors are consolidating and acquiring SOA tools in an attempt to create an end-to-end SOA suite (whatever that means). When Software AG acquired IDS Scheer AG, it raised the "the possibility that vendors may start forcing business process management solutions into that end-to-end SOA mix as well," McKendrick wrote.
While McKendrick says it seems unlikely Software AG would actually do this, he does seem to think at some point, the two will come together:
"... we can conclude that it's not likely we'll be seeing a lot of BPM stuff being shoe-horned into SOA suites. But, it is inevitable that SOA will rely more on BPM; and BPM will rely more on SOA. It's inevitable."
I can't speak to inevitable, but the idea is certainly out there now, hanging in cyberspace, just waiting for someone to try it. I'm sure it will be a marketable idea. Whether or not it's a good one-well, the devil's in the details. Even Morgenthal and others who warn against trying both at once acknowledge there are times when SOA and BPM can complement each other.
But they're both big, hard, sweeping initiatives. Trying to do them together can be risky business indeed-like boiling the ocean, Morgenthal warns.
And adding MDM to the mix? Good luck with that.