Previous page: Ontario's common components approach
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
SOA: A better ballgame with BTEP
Where to start: Identifying the driver
icon.
