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.
Some significant successes have come out of this multifaceted approach. Many of the SOA initiatives occur at the cluster level with the development of “birds of a feather” applications – health services cluster’s project management work for example. Others, coming out of the Common Components & Applications Branch, have a wider scope.
The government is developing a common process for citizens to register with and make payments to any ministry, for example. It was as much a question of aligning business processes as developing common technology solutions.
One department might have had a process with 14 steps, another a process with seven steps, another a process with 19 steps and so on. But after analysis, it became clear there was really one common process with 20 steps around which a system could be built. Some ministries simply used a sub-set of the steps in their own system.
“It required a lot of alignment and re-definition at the ministry level,” Huxter says. “We’ve had some success with that now, and that really is a huge change.”
Service Ontario is a new enterprise-wide organization for delivering service to the public. In the past, every ministry had its own public-facing initiatives. Now citizens interface with one organization which facilitates communication on all government business with all departments.
It is a business-led initiative, Huxter is careful to note, a reflection of the SOA culture more than an actual SOA project. While implementing it will require a considerable application development effort, Service Ontario has several ‘channels’, not all them technology-based: Web, kiosk, call centre, in person.
Service Ontario, again, required “a huge cultural change,” Huxter says. Cultural change is a theme he returns to again and again.
The four-year-old e-forms initiative from the Common Components branch was launched in part to support Service Ontario. Its objective is to help move Ontario into the era of e-government, by automating the process of turning paper-based forms into online electronic forms. An e-forms “SWAT team” moves from ministry to ministry using a utility developed by Common Components to convert paper forms.
“E-forms gets rid of the paper issue,” Huxter notes, “but it also helps with the biggest problem: invalid data. It could be a box not filled in, or a misspelling of a street name. In the paper world, that would not be found until a clerk checked the form. In electronic forms, the system can do some data validation. It saves half the aggravation.”
More recent initiatives include e-Vista, which will use common procedures and tools for management reporting systems, including common look and feel, executive dashboards. And the enterprise ERP systems will be extended to incorporate centralized payroll.
The SOA culture at OPS was not imposed in a single stroke – nor, likely, could it have been. It evolved slowly. And there were challenges along the way. Elements in both the businesses and in IT resisted.
Each ministry, Huxter explains, is passionate about delivering satisfactory service to its public. “And to provide service in a common way threatens your ability to control how you provide service. You’re putting your eggs in someone else’s basket.” Some ministries were very uncomfortable with the idea at first.
On the IT side, OPS had to contend with the ingrained culture of creativity and invention among developers. As Huxter says: “They like to use what they know and know what they use.”
SOA in many ways ran counter to those instincts. Now, instead of writing code to solve a problem, they were being asked to try first to gather code from somewhere else. Many had to become solution integrators rather than ground-up developers.
Overcoming resistance on both fronts was more a process of evolution than revolution. Time, attrition, the inexorable roll of many SOA-related initiatives gradually changed the culture.
In many ministries, using common processes and applications raises thorny privacy and security issues. When the business controlled the development process, it could ensure that an application incorporated required protections.
Today, cluster-level and Common Components branch developers respond to privacy and security concerns by incorporating the specifications of the business with the most rigorous requirements. But some businesses need absolute assurance. Ultimately, it becomes a legal issue that needs to be solved by devising the proper service level agreements.
“Lawyers are going to have the biggest headaches in all this,” Huxter says. “Legal concepts around liability and intellectual property must adapt or disappear in a world of collaboration.”
Other challenges? Working out charge-backs in an SOA world has been vexing. The initial approach was to charge full freight to the ministry for which an enterprise or cluster-wide application was being developed.
But then other ministries would use the same application and not incur any upfront costs, although they are charged for operational costs. Today, the approach is to start small to minimize costs for the initial user.
“We’re not building the big bang application at the front end now,” Huxter says. “We identify a potential big bang that could be used enterprise-wide, let them build it for the business, then later expand it to be an enterprise application.”
The Ontario government, like every other organization, is still learning how to do SOA. One key lesson it learned early, though, was the importance of developing its own methodologies and tools rather than relying on a proprietary process or tool set.
Using SOA methodologies offered by vendors almost always locks you into using specific products from that vendor. OPS very deliberately developed methodologies and standards that it could freely modify as required and that would not lock it in to a single vendor.
Now it’s just a question of applying the methodologies and building on the successes the government already has under its belt. It’s a process, Huxter says, that almost any organization could emulate, and that many should.
“The more complex your organization is, the more lines of business you have, the more this has to be implemented, or you’re not going to get any control over your IT investments.”
Related content:
Blocks of SOA: Building services with common symbols
SOA: It’s architecture, not technology
Understanding the architecture
