Transforming a puzzling patchwork of disjointed legacy applications to an integrated yet flexible suite may seem a daunting task.
But it's a goal the Ontario government is well on its way to achieving thanks to its new Service Oriented Architecture (SOA) initiative.
SOA is a software architectural concept that defines the use of services to support the requirements of software users. Stressing virtues of interoperability and reusability, SOA promises greater flexibility and responsiveness in data systems and the business processes they support.
In Ontario, the new SOA framework will reuse systems for common business processes and make the government's IT infrastructure more flexible to adapt to changes in government programs, and even changes in governments.
Ron Huxter, chief technology officer in Ontario's Ministry of Government Services, used an IBM Canada breakfast on SOA best practices in Toronto last month to outline the government's blueprint. He said one key driver for moving to SOA was the need to be more agile. "We have 200 to 300 different lines of business … of which one-third to one-half get whipped-out every four years."
While SOA may be new to Ontario, Huxter says the idea isn't. The government’s current initiative is a carry-on of what’s described as a "common component strategy" the province tried to implement six years ago. "The reason it wasn't very successful is because it was a technology effort and not a business effort."
That's a mistake they're not planning on making this time.
Huxter says the exercise is being driven as a business initiative, with IT as an equal partner at the table. A Common Components and Applications Services group, which Huxter says will be announced shortly, is responsible for identifying common components that can be reused across the government. "All government programs have unique outcomes but not unique processes."
The group will also act as a "gatekeeper" to ensure new applications proposed for development or purchase are compliant with the government's SOA standards.
"The only thing dumber than building legacy applications is buying them," Huxter says.
The other place the province will be looking to find components and applications is from other provinces. Seeing no need to reinvent the wheel, Huxter said Ontario has already talked to British Columbia and other provincial governments.
While the benefits from SOA are strong, there are some significant challenges. One revolves around the issue of attributing liability and responsibility, particularly when it comes to a security breach. It's an important consideration in any government organization, but difficult to do when processes are shared across multiple ministries.
"How do you attribute liability across that architecture?" Huxter says. "It will be interesting to see how that plays out."
Another major challenge is cultural. Huxter declared that the days of enterprise software vendors selling end-to-end applications promising to “do it all” are over. Instead, he sees the future as specialised components for specific business processes that are plugged-into an SOA. That will mean a changing role for application developers.
"What that does is transform the application development world into the integration world, and that's what we're in the middle of right now," he says.
Richard McDonald, a distinguished engineer with IBM Canada, agreed that the concept of SOA isn't new, just the term. He was talking about some of these concepts around application development strategies as long ago as 15 years.
What McDonald said has changed is the need for IT systems to be more agile and flexible. On the technology side, advances in technology and an increased focus on interoperability and common, open standards are helping make SOA possible today, he says. "This is now enabling the design approach that some of us have been taking for many years," McDonald says.
While IT is at the core, McDonald said technology is not where the discussion should happen. The goal is to be better able to respond to changing business needs. It is those business needs that must be the first consideration.
"Business people tend to think about business processes as the systems they use to run the processes, and that's wrong," says McDonald. "They should be talking about the business."