The federal government supports the development of service-oriented architecture (SOA) across the public sector and has posted two documents outlining SOA strategy and a series primer. “We’ve been engaging departments to validate the positions we posted, to find out what they think and to make adjustments,” says Gary Doucet, executive director of architecture for the CIO branch of Treasury Board Secretariat.
Doucet believes SOA shows promise not just for application integration, but also for designing business processes. The concepts of SOA and service orientation overlap, he explains. “When you have services defined in the SOA technology space, they will be context-adaptive and agnostic, meaning the service doesn’t need to be run as part of the application. You can do similar things with business design. Sometimes people think SOA is simply a technology idea, but it has broader implications.”
For example, a manager may have widget processing software that includes accounts payables, receivables, and other generic functions. “He may decide SOA is a good way for that system to work with other systems in the business,” says Doucet. “But why just look at the software as loosely coupled modules? If it’s a business line that manages widgets and accounts payables, there may be people in the larger enterprise that can also use those functions. If you’re able to define it once, you might start looking at reuse of services, not just technology.”
However, Treasury Board doesn’t have any directives or incentives in place yet to encourage uptake in the public sector. “We haven’t said SOA is absolutely the way to go; we haven’t made it a standard yet,” says CTO Chuck Henry. “There are many issues to resolve for the industry as a whole, not just government.”
Besides technical specifications, there are complex governance issues that need to be sorted out first, he says, such as settling liability between service providers, mutual understanding of service granularity, and semantic models to ensure consistent description of services.
SOA’s greatest strength and weakness are at once its flexibility, adds Doucet. “Within the SOA space, there are major families of standards that people can adopt.” He points out that even within Web services, there is great variability. “It’s considered a composable standard that lets you pick and choose which ones you want in your particular context. Ontario and B.C. might both develop SOA-based solutions that may not necessarily be totally interoperable because they picked different parts of the standard.”
It may take time to sort out government standards and policies, says Henry, but as an initial step, the Management of IT (MIT) policy of 1994 has been updated and is awaiting approval. The refresh includes two SOA directives. “One is on governance: how we’re going to agree on standards, and [the other is] direction on technology strategy, where we would, in a broad stroke, figure out how to solve some of the problems in government. Under that are our standards, which is instruction at the working level.”
Henry emphasizes the government’s organizational structure needs to be considered. “We have a Westminster system of parliament around accountability that limits our ability to have strong central mandates on things like SOA. We encourage people to learn more about SOA and develop pragmatic approaches. There may be business contexts where SOA might not make sense right now.”
The technology will sort itself out in the marketplace as SOA evolves, Henry adds. “In government, it’s more important we agree on a philosophy of interoperability and reuse of capabilities, be it software or human.”
Related content:
Blocks of SOA: Building services with common symbols
SOA: A better ballgame with BTEP
SOA at work: Ontario’s common components
