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.