Is SOA getting boring?
Politics takes over from technology
At IBM’s annual Impact SOA bash last week, software group head Steve Mills stated that the next frontier for SOA is really not a frontier at all: it’s the basic blocking and tackling of getting Enterprise Service Bus backbones to deliver the high levels of ACID reliability and fault recovery now taken for granted with OLTP transaction systems.
In other words, when you start thinking about enterprise SOA, you’d better expect rollback, compensation, and high-availability features that are taken for granted with online transaction systems.
By comparison, IBM’s message last year was that it was time for SOA to graduate from IT and get driven by the business.
No matter, when we sat down with Mills afterward, we asked him if this meant that SOA was getting, well, kind of humdrum. No more quibbling about whose standard for federated identity to latch onto, what’s most important are the basics of enterprise systems. Replying tongue in cheek that SOA’s always been boring, Mills added that now, the question no longer centers over whether SOA will work. But he notes that with more moving parts, delivering that reliability presents more of a challenge.
Of course, it took about 20 years for enterprise databases to achieve that kind of rock-solid assurance, but applying the lessons learned should make that journey quicker today. Nonetheless, compared to database transactions, SOA could involve a far more complicated use case. For starters, there’s the architecture, which calls for a middle tier abstraction layer that separates the service from whatever physical systems implement it. Of course, you could argue that the golden age of transaction processing introduced its own middleware: transaction monitors.
Nonetheless, the dynamic nature of SOA, where services could be orchestrated and service providers swapped at run time, could make delivering ACID reliability for run-of-the-mill OLTP systems appear almost like child’s play. Troubleshooting could require serious detective work. For instance, when a customer history service that is composited from order history and account identifiers in ERP, and interaction history from CRM, where do you start looking when the service fails to execute?
There’s yet another parallel between SOA and the evolution of databases. Twenty years ago, there were debates over whether SQL databases could handle the load and deliver the performance of legacy databases or file systems. The answer was throwing Moore’s law at the problem. Today, there are similar questions regarding SOA, because if web services standards are used, that means a lot of fat, resource-hungry XML messages whizzing around. Mills’ answer is that there’s a glut of underutilized processing capacity out there and a crying need for virtualization to make that iron available for XML.
Obviously, SOA plays to IBM’s strengths - large systems, and ways to integrate them. But the world of run-time governance of SOA remains fragmented, which explained AmberPoint’s presence in the vendor exhibit area.
That hits on another point, which is IBM’s contention that it is best situated to glue everything together. Mills contended that SOA brings pressure on the SAPs and Oracles of the world to open their APIs using Service Component Architecture and Service Data Objects. Obliquely, it points to new competition for where new functionality gets situated: inside the application stack, or at the BPM or service composition layer in the middle. Mills denies that there’s a power struggle going on. In his words, the question of who wins or loses when you add SOA to the mix is “one of those silly debates… we’re not saying what we do is more important than what SAP does.”
Well, maybe it’s silly, but IBM has plenty of accounts where there’s a lot of SAP and Oracle, so there’s going to be competition for that middle tier.
But what about the other half of the enterprise market that uses homegrown rather than packaged apps? Later that day, we sat in on another session to explore how IBM is building a composite apps business for that segment (more specifically, for banking, insurance, telco, and healthcare sectors). This was a follow up to a session we caught a year ago, just as ink had dried on IBM’s Webify acquisition that brought the underlying technology for building vertical industry SOA frameworks.
Balance of power questions abounded there as well, although IBM is taking pains not to call these composite applications, but composite solutions. The inference is that solutions are supersets of applications, and thanks to SOA, far more dynamic.
With that assumption, IBM is still playing linchpin - they own the underlying framework, and reprising the role performed by its global business services groups, IBM also plays arbiter in recommending solutions. This year, it introduced tooling that allows customers to add their own framework extensions, or get IBM to integrate third parties currently not on their preferred partner list. Three partners - Kana for contact management, Seec for insurance business components, and Chordiant for “customer experience solutions" - testified that of course it’s a two-way partnership (they’re also veteran IBM business partners).
But IBM is clearly first among equals, as the framework is its own, is responsible for level one support, and therefore, is positioned to assert account control. But realizing that the technology has surged ahead of the business model, IBM and partners are still shaping the rules of engagement for composites as they go along.
From a technology standpoint, SOA might be getting a lot more boring. However, impacts to vendor business relationships are for now anything but.
This article originally appeared in onStrategies.
Copyright © 2008, onStrategies.com
Tony Baer is the principal with analyst onStrategies. With 15 years in enterprise systems and manufacturing, Tony specialises in application development, data warehousing and business applications, and is the author of several books on Java and .NET.