SOA was supposed to simplify integration -- particularly the point-to-point integration required for more traditional approaches to systems and software.
But that's not how it's playing out in the financial services sector, according to a recent article published by Insurance Networking. Instead, companies are finding that vendors deploy even Web services differently and that the standards designed for interoperability are, nonetheless, causing integration problems that require custom code.
This is an excellent, if frustrating, look at what's gone wrong with SOA, and I can't help but think that it also offers insight into why U.S. companies are backing off SOA. While companies have successfully used SOA for internal integration, thus far, SOA's usefulness stops at the firewall.
That's a major problem for SOA. Its main proposition as a business-enabling approach is that services can be used by business partners and potential customers. If you can't extend your services beyond your firewall, SOA starts to look suspiciously like just another way to do integration.
The article contends that SOA is failing to move outward because of security concerns and a failure of standards.
Though vendors may be using the same standard, they're implementing the standards differently and using proprietary messaging, according to Vivk Mehra, vice president of global financial services and insurance at a California branch of Keane, an IT services firm. Mehra summed up the problem nicely, telling Insurance Networking, "Conformance with a standard is one thing on paper and another thing to make it work out of the box, on the ground."
The chief architect at Globant, Pablo Grana, added this:
"It would be very risky to base a product or a project on the transaction specifications related to SOA right now."
And, understandably, risk is not something the financial services sector is willing to pursue right now.