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.