Previous page: Treasury Board policies and standards
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."
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 flavour 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."
Continued: SOA in health care
Related content:
SOA: A better ballgame with BTEP
SOA: It's architecture, not technology
SOA: Understanding the architecture
Where to start SOA: Identifying the big business driver
SOA at work: Ontario's common components
icon.
