Andy on Enterprise Software

SOA deja vu

August 31, 2006

SOA (service oriented architecture) is nothing if not fashionable, but it seems to me that the reality could be a struggle.  For a start, the very laudable idea, reuse of inter-operable application objects seamlessly, is not exactly new.  Those of us who are a bit long in the tooth will recall the “applets” of the early 1990s, and then there was the whole CORBA thing.  Everyone got excited about the idea of being able to mix and match application objects at will, but in practice everyone did the opposite and just bought monolithic suites from SAP, Oracle and other vendors who are mostly now owned by Oracle (JDE, Peoplesoft).  What exactly is different this time around? 

Surely in order to obtain true re-use you are going to need some standards (which have moved on a bit, but not enough), some way of mapping out business processes, and some way of dealing with the semantic integration of data (if two applications want to trade some data about “customer”, who controls what that particular term means?).  In addition you need some solid infrastructure to do some of the heavy lifting, and there are certainly some choices here.  In this last area we have IBM Websphere, the immature Fusion from Oracle, Netweaver from SAP and  independent alternatives like BEA.  On the process mapping side there are newcomers like Cordys and a host of others.  The trouble here is that it seems to me that the more complete the offering, the more credible it is yet the more difficult it will be to sell since enterprises already have a stack of established middleware that they do not want to swap out.  If you already have an enterprise service but from (say) Cape Clear and EAI software from Tibco, plus some Netweaver as you have SAP applications, then how exactly do you combine these different technologies in a seamless way?  The last thing you want to do is introduce something new unless you cannot avoid it.

To make matters worse, there has been little real progress on data integration, particularly when it comes to semantic integration.  The pure plays which have real technology have either been swallowed up (like Unicorn) or are relatively small vendors (e.g. Kalido).  The giant vendors of middleware have little to offer here, and are intent on grabbing mindshare from each other rather than striving to make their technologies genuinely interoperable with those from other vendors.  Master data management is as yet very immature as a mechanism for helping out here, and again the decent technologies live with innovative but smaller vendors.  Some partnerships between the giants and the best pure-plays will presumably be the way to go, but this has yet to really happen.

Finally, you have what may be the trickiest barrier of all, which is human.  To get reuse then you need to be able to be aware of what is already out there (partly a technical issue) and also really want to take advantage of it (a more human problem).  Programmers are by nature “not invented here” types, and this is one thing that made object orientation hard to scale in terms of reuse beyond programming teams.  Whatever happened to those “exchanges” of objects?  You can read about early SOA pilots, but I observe that these seem generally of limited scale and usually restricted to one set of middleware.  This is a long way from the “plug and play” nirvana that is promised.

To be sure, SOA has a most appealing end-goal, and so will most likely run and run, yet to me the barriers in its path are considerable and some of the necessary components are yet to be fully matured.


2 comments so far

I am not clear about how SOA will work in an MDM context and would be grateful if you could throw some light on it. Having worked with Kalido MDM, I can understand that it provides a dedicated application where master data for the enterprise can be defined and managed well centrally. What I am not clear about is how MDM will work in an SOA environment.

To take a simple example, suppose my CRM application maintains some basic information about Customers like name, address, etc but there are some duplicates in the data too. In MDM, this data gets de-duplicated and further enriched by, say, adding a demographics hierarchy (which is not maintained in the CRM system). The requirements for this set up are:
1. When new customers are added, they need to be propogated to the MDM system where they will be de-duped (if necessary) and assigned to a demographic hierarchy.
2. The cleaned up data (the relevant parts of it, that is) from MDM needs to be propogated back to the CRM system either periodically or in real-time.

In this context, how and where will SOA fit in?

Thanks in advance,

P.S: If the question is too elementary, could you please point me to some place where this issue is explained clearly? Most of the stuff on the web is at a high level and I am not able to relate it to the problem at hand.

Your question is a good one. Others feel free to chip in, but here is a quick response. You are absolutely right that data in this situation will be initially stored in a CRM system, and a copy of that will be made in a master data repository (and maybe elsewhere, like a data warehouse). In this scenario the MDM repository is just a passive data dictionary, which at best will keep track of where other copies of master data are. In order for it to be more useful the enriched or corrected master data in the repository needs to be treated as the master source, rather than the data in the CRM or other systems. For this to happen the master data repository needs to be wired up to the operational systems via either an EAI approach or an enterprise service bus. In such a case the service bus would provide the “correct” master data to other systems, including the CRM system. This would involve an improvement in the overall data quality of the enterprise. Of course this is a fairly scary scenario in many ways, as it implies real-time or near real-time changes in the repository being propagated back into operational systems, but it is something that a few companies have done. In this case whether or not SOA itself is involved is a bit of a side issue. If SOA makes it easier for the EAI or enterprise service bus to feed data to the CRM system then all well and good, bit it is a nice to have.

I hope that makes some sense. Other views are welcome.

Leave a comment
Your e-mail address is for administration purposes and is never displayed.


(required but not displayed)