This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Entity Services & Master Data Management ��� Good intentions lead where?
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
The other day I ran into a blog post titled ���Master Data Management ��� just another load of inaccurate data?��� and got this feeling of deja-vu. This idea of having a single location where the authoritative definition of an entity lived is not new. Enterprises have been going back and forth on the continuum of centralization-distribution for years. The whole SOA and BPM fads that have taken the world of IT by storm appear to have stirred up this topic yet again, this time incarnated as ���Entity Services���.
For those of us who went down the path of centralization, and failed, I probably won���t be bringing any words of wisdom. But for those who haven���t, maybe this warning will save you some grief ��� I only wish I knew where to look back when I was doing this.
In the example shown in the blog post, the problems that occur when customer data is duplicated in multiple back-end systems are discussed, as are those of employee data. The source of my failure rested in the belief that there is such a thing as a coherent entity. Only later did I find out that for sales different data was important than for billing. It was not so much the issue of data that got us in trouble, we just created a super structure for all the data, but that the business rules were so different ��� at times appearing inconsistent and contradictory. We finally had to ditch the centralization effort ��� there were too many worlds colliding that couldn���t be reconciled. Entity services appear to be directing us down that same logical, yet misleading path.
The author quotes some popular beliefs about SOA that appear to make matters worse:
���The problem is that I don't see how MDM helps SOA. SOA needs to work with disparate backend systems largely intact, benefiting from the logic they already provide. It should not be trying to replicate or rebuild the business logic in underlying systems, since if you are going to do that you might as well rip and replace those systems, not duplicate the logic in the integration layer.���
This view of SOA being bound to reuse at the expense of quality and effectiveness is misguided. Proponents of SOA tout reuse as a benefit that will occur in the future, but never is reuse introduced as a constraint in designing an appropriate architecture. This view of SOA is understandable given the EAI history so many bestow up SOA. Personally, I do not view SOA as an integration technique. Rather, I look to the principles of SOA to help in finding the inherent fracture points in the business domain so that services can be designed to handle each section of the domain. Services designed in such a way will be as loosely coupled as is possible.
I would suggest that we as an industry focus more on learning from lessons of the past than jumping on the latest bandwagon and betting the future of our projects and companies on unproven, vendor-driven acronyms. Maybe then, we���ll be able to codify those lessons in such a way that we���ll have repeatable successes worthy of acronyms.
Previous Topic
