Service-oriented architecture (SOA) may be the hot button of the moment in enterprise application development, but at the Ontario government, it's really nothing new.
"For us, SOA is more a re-branding of an approach we've had in play since about 1999," says Ron Huxter, chief technology officer. "We referred to it then as a common components approach."
Same idea, different label. The idea: that various ministries and agencies shared common or similar workflows and processes. So why reinvent the wheel by building a different credit card payment module for every ministry Web site, for example, or a different name and address capture module?
In fact, why build new Web sites from scratch when you can more quickly provision them using a hosted, portal-in-a-box approach? And why create different electronic forms for each department when even seemingly dissimilar processes - applying for a birth certificate and applying for a fishing licence - share common attributes?
The Ontario Public Service (OPS) has worked for almost a decade to develop an SOA environment in which that kind of thinking became second nature. It's now solidly entrenched and bearing fruit. We wanted to find out how OPS did it, the challenges it faced and the benefits it's reaping today.
But how applicable is the experience of big government to other types and sizes of organizations? OPS is one of the largest employers in the country, with 65,000 public servants. They work in more than 20 ministries with a broad range of business lines, from justice to education to recreation to health. And none of them sell widgets. Could a commercial enterprise - a mid-size company, say - replicate what OPS has done?
"Absolutely!" Huxter says. "This can be applied to any organization, public or private, that has diverse lines of business."
While Huxter's Office of the CTO was responsible for developing an architectural framework that established standards for, among other things, efficiently sharing and reusing applications, program components and tools, the transformation at OPS was the work of many not always coordinated initiatives.
"If you're looking to identify an SOA champion on a white horse, I don't think that person existed in the Ontario government," he says. "There were always a number of folks in IT leadership and business leadership who were open to these approaches. It was more the realization of a thousand points of light than a single thunderbolt."
One of the first big moves was organizational. In 1998, the government consolidated 24 ministry IT departments, creating eight new IT organizations responsible for "clusters" of ministries with similar or related responsibilities and ways of doing business.
"There was a feeling that ministries in the same sector could more easily share applications," Huxter says. "A case management system for the courts is the same as a case management system for the jails is the same as a case management system for policing. We called these 'birds of a feather' applications." The new IT organizations were charged with "harvesting as much reuse as possible."
Another major thrust, starting almost 10 years ago and not strictly speaking an SOA initiative, came in the back office with the replacement of 24 ministry financial and human resources ERP systems by single enterprise-wide systems.
"That was a real coming of age for OPS," Huxter says. "Why would the ministries want to care for and feed independent financial systems when they could have a common system like this?"
In the background, a complex IT organizational structure evolved with, on the one hand, groups such as Huxter's, which has no direct operational responsibilities but is charged with fostering the enterprise-wide approach to application development, and on the other, operational IT groups, including some with specific responsibility for identifying and helping develop common components.
The Corporate Architecture Branch, now under Huxter, developed the reference architecture for the entire government. Detailed standards based on it are laid out in GO-ITS (Government of Ontario IT Standards) documents, many of which are available at the Ministry of Government Services' Web site.
This branch also reviews major projects and enforces architectural standards. And it guides government at a strategic level on planning for and investing in enterprise-wide applications.
The Applied Architecture Branch, also under Huxter, puts all of this into action. "It's nice to have IT standards," he notes. "It's nice to have enterprise architecture requirements, but how do you actually make that work at the project level."
The Applied branch does that by assigning personnel to work with cluster-level IT project teams to help them scope and plan projects and then deal with architecture and design issues that arise.
Huxter calls it the "healthy baby healthy projects" approach. The idea is to ensure that projects stick with the program and reuse whatever is available, so they're more likely to be successful, and also fit into the larger strategy.
The province also encompasses centers of excellence for developing applications using the two most important SOA-related development technologies on which OPS standardized: Microsoft's .Net framework and the Java 2 Platform, Enterprise Edition (J2EE), now more simply referred to as Java EE. These centres develop and implement shared tools for their separate application development disciplines.
And then there is the Common Components & Applications branch - not in Huxter's group but attached to the Office of the Corporate Chief Strategist. Its mandate is to identify common components and applications, and provision them for all to use.
Next page: SOA then and now
Related content:
Blocks of SOA: Building services with common symbols
SOA: It's architecture, not technology
Understanding the architecture
SOA: A better ballgame with BTEP
Where to start: Identifying the driver
icon.
