IT vendors feed this confusion by treating SOA as a selling point in their marketing strategies, suggests Kuhbock, with many branding their particular product or flavor around their own definitions.
"It's all based on what they're selling," he says. "Everybody has different reasons for being active in this space, be they producers or consumers of solutions. All have different objectives, so it's hard to get consensus, and this bleeds into every area of its use."
As a consequence, the number of SOA standards is rapidly proliferating. "At last count, there were over 110 SOA standards," says Kuhbock.
St. Arnaud agrees this lack of common standards is a major issue. "There are standards wars going on. Web services have exploded into a multitude of different variations and special sector types. Now suddenly, this great nirvana solution that could make everything compatible has itself become incompatible with different versions."
But various government entities -- the federal Treasury Board, the Ontario Government, Canada Health Infoway Inc. -- have done extensive work in defining SOA standards and providing technical guidance for their constituent areas. So any lack of standard definitions should in theory be less of an issue in government relative to other sectors that don't have top-down leadership.
Not so, says Kuhbock. "SOA has been muddled by the vendor community," he says, pointing out public sector IT people still need commercial software tools to re-architect their systems. "If the government is dealing with vendors A, B and C, and each of those has a set of standards around their SOA-based tools, then the government is back into analysis paralysis sorting it out. No one's really come out with best practices, methodologies and so on, and the vendors keep redefining the standards around their tools."
Nor is any one major vendor's version emerging as a de facto standard in the public sector, since the government uses a wide range of vendors to encourage competition. "You don't just have IBM and BEA, you have Microsoft, SAP, Oracle, Accenture, Deloitte - all moving in different directions," says Kuhbock. Industry groups like the Integration Consortium are trying to facilitate consensus, and vendors are starting to agree to disagree, but this process is proceeding slowly, he adds.
Kuhbock emphasizes SOA is not a software tool or an IT project, but an architecture that enables communication between services, data and processes. "If you're constructing a building, you need concrete, beams and pylons, but if you don't have an architecture, you've created an unstable environment that can crash. Many IT systems were built as silos, so they're like buildings that don't have staircases or elevators to join the first and fifth floors."