Slouching towards SOA

Unity is hard to do. Service-oriented architecture (SOA) can help turn the masses of silo systems in government into modular components that can be snapped together to share common system services. But the devil is in making a business case today for SOA investments that will deliver indirect benefits tomorrow.

The public sector is ripe for systems integration, but the march of SOA has been slow. About a third of government organizations have adopted SOA, 11 per cent plan to adopt it and 40 per cent say they have no plans, according to a recent IDC Canada survey. Of provincial respondents, 23 per cent say SOA is their preferred strategic approach, but only 15 per cent of federal respondents say the same.

The major hurdle in SOA uptake in both the private and public sector is the need to rewrite legacy code to be SOA-compliant, says Jamie Sharp, vice-president of customer segments research at Toronto-based IDC Canada. By definition, a systems architecture is a set of design principles that is expected to defer future costs, he explains. Reworking existing applications may cost more in the present, but future costs can be avoided because integration will be easier when new systems and services can be plugged in with minimal fuss.

“Most government organizations are making public statements saying SOA is the right way to go,” says Holly Thiessen, national executive for SOA at IBM Canada. But they have to deal with a major complication that the private sector doesn’t. “There are frequent changes in governments and their priorities. They’re trying to figure out how to build a business case when the federal government may change next year, and they may not necessarily have that two- to three-year time horizon these projects require.”

To work around this issue, many government organizations are trying to identify SOA projects that will bring quick returns by identifying services that can be reworked in a shorter time frame, she says. But there is risk in this, as picking a service that can’t be reused or recombined later will jeopardize funding and reputations. “They have to figure out where the logical starting points are to get going, and then get through the politics of getting the business case approved.”

Politicians are wary of these types of projects, says David Brown, a senior associate at the Ottawa-based Public Policy Forum, pointing out that a records automation project brought political grief in the past to John Baird, president of the Treasury Board. “Government CIOs tend to be from the private sector, and they may not necessarily understand the politics. They have to learn how to present their cases in ways that politicians are prepared to make decisions and take risks.”

Due to these constraints, SOA projects have been limited to connecting system A with B, rather than being seen as a way to transform business processes to improve service delivery, says Thiessen. Sharp agrees, pointing out there is little value in making one application SOA-compliant. “That application has to talk to a whack of others, and then integration overall becomes easier.”

The true value in any systems architecture is building on top of it. “The first step is to reuse what you’ve got to deliver more value, but then the next step is to look at doing things different and better with business modeling,” says Thiessen.

She says a good example of a service that is reusable across the board is employee on-boarding. Hiring new government workers, setting them up on systems, transferring them, and so on, requires a similar set of processes across departments. “Organizations have different systems, so it takes a long time to move employees around. If the service were provided in an SOA, this could be streamlined.”

On the service delivery front, unified case management can provide a single view of a citizen from “conception to resurrection,” as one pundit put it. Depending on the particular services individuals use, these can be loosely coupled with SOA so they can be recombined as required in ways that may not exist today.

Sharp says SOA is often confused with electronic service delivery in government circles. But he notes there’s been a shift in focus in the past two years from sexy front-ends to tedious back-ends as SOA gains traction. “From an architectural perspective, re-engineering the front-end is not where you get maximum return with SOA. Historically, a lot of work has been done on the splashy front-end of service delivery that gets votes.

Rosie Lombardi is a Toronto-based freelance writer. She can be reached at