Public Sector SOA

The UK Government has identified four primary opportunities for using SOA in eGovernment:

• Syndication
• Rule Engine
• Joining up internal architecture
• Hand-shaking between agencies

For each of these opportunities, I shall quote a brief description from the GovTalk website, and then add some commmentary of my own.

Syndication

"This is where the services of a single Agency are to be aggregated with that of others and delivered by a third-party. This approach is supported by the introduction of common vocabularies and category lists such as the Integrated Public Sector Vocabulary (IPSV). A potential example would be DirectGov."

This is essentially a call for public-private mashups - in other words, joined-up services. There are some interesting opportunities for voluntary agencies and community groups to create customized "added value" services for particular target groups. This kind of thing can help to extend the reach of government services into otherwise disadvantaged groups, and thereby supports an "inclusivity" agenda.

This can also support an agenda of autonomy and decentralization, including alternative notions of identity (e.g. Identity 2.o).

Rules Engine

"Where a number of Agencies are dependant upon the rules set by another agency, and where those rules are complex and likely to change. A Web Services ‘call’ can be embedded into an application to perform calculations and return results into local data."

Among other things, this supports an agenda of "joined-up policy making", because it helps with the coordination, monitoring and maintenance of a broad range of policies across a broad portfolio of government systems and services. Ideally, government should be working towards closed-loop policy management, in which (i) policies can be directly associated with the sum of their outcomes, using service-oriented business intelligence and analytics, and (ii) policies can be adjusted in a coordinated manner to improve outcomes.

Joining Up Internal Architecture

"Where an Agency operates enterprise technologies, such as Workflow, Records Management, Middleware, Content Management. This approach avoids embedding API(s) from one component into another. The potential to create Web Services wrappers around proprietary technologies leads to the ‘swapability’ promoted by the e-GIF."

In other words, joined-up infrastructure. At the infrastructure level government requirements are pretty similar to those of any other large organization, except that governments often put greater emphasis on open standards, multi-vendor support and interoperability.

Handshaking with other Agencies

"Where an Agency wishes to interact with another Agency (G2G). This may be in terms of: Creating Workflow Instances, Making Appointments, Shared CRM facilities. Access to Data."

Finally we come to joined up business processes - orchestration and workflow, choreography and collaboration. This is perhaps the most obvious type of joined-up government, but not (as we have seen above) the only type.

So who does the joined-up thinking? Apparently, the joining-up initiative isn't imposed by any centralized planning body, but merely stems from "an agency wishing to interact with another agency". (So no arm-twisting from the Prime Minister then?)

Final remarks

Joined-up government is not just about joined-up processes - it also includes joined-up services, joined-up policy and joined-up platforms. There are some interesting initiatives underway in the UK government, and I look forward to seeing some practical results soon.

Sources

UK GovTalk e-GIF FAQ

[update] For a description of current initiatives in Canada, see John Gøtze: Aligning the Ducks.