SOA is still a work in progress, and its capabilities are ill-defined and confusing. SOA facilitates system integration, but it doesn't actually do the integration. "It's an architecture, nothing more," says Kuhbock. "In the construction industry, you engage an architect to design the building so it has a sustainable infrastructure and everything works together - but then you engage construction crews to build it."
SOA design is counter-intuitive and difficult for IT staff trained in classic waterfall systems design, adds Turner. "The traditional way is to look at application suites as a whole, design in the most integrated way possible, internally within the system, and use programming logic that produces tightly-bound functions with minimal duplication."
While it may be an elegant system initially, the costs to make any modifications or additions later are high, since the system isn't designed to change or grow over time, he says. "Then SOA comes along, intentionally breaking things down into blocks and duplicating functions so they can work as loosely coupled modules. It's less elegant, but in the end, they're cheaper to put together."
Governance and accountability issues are also stumbling points when sharing SOA infrastructure and interlinking modules -- a problem that's more acute in the public sector versus the private, he says. The horizontal shared services movement in government butts directly against the brick wall of vertical organizational structures.
"The cabinet system we have in Canada is built on the intentional design of silos," says Turner. "Each set of programs is enabled by legislation and statutes, and each organization supports a minister who's accountable to Parliament for that set of programs. Natural silos are designed into the system, so when you try to apply common technology across departments, it goes against the grain. It almost comes down to, do you want efficiency or accountability?"
The tendency to treat SOA as an IT project rather than a strategic architecture is a consequence of these silos, says Kuhbock. At a recent presentation he made to government IT officials, many of them said they had the same central issue: "They can do SOA in their own compartmentalized area, but they can't get it broadly driven; so they're just stuck in their silos again. It's like architecting a town, district by district, without thinking about how the whole town will interact, or mapping out the whole community."
Vendors and standards wars
Beyond the public sector, there are some industry-wide SOA issues that need to be settled. "SOA is on a hype cycle," says Kuhbock. "There's confusion about it in the marketplace across all industries. There's no universally accepted definition, so it's different from one industry to the next."