Blocks of SOA

Nor is any one major vendor's version emerging as a de facto standard in the public sector, since the government uses a wide range of vendors to encourage competition. "You don't just have IBM and BEA, you have Microsoft, SAP, Oracle, Accenture, Deloitte - all moving in different directions," says Kuhbock. Industry groups like the Integration Consortium are trying to facilitate consensus, and vendors are starting to agree to disagree, but this process is proceeding slowly, he adds.

Kuhbock emphasizes SOA is not a software tool or an IT project, but an architecture that enables communication between services, data and processes. "If you're constructing a building, you need concrete, beams and pylons, but if you don't have an architecture, you've created an unstable environment that can crash. Many IT systems were built as silos, so they're like buildings that don't have staircases or elevators to join the first and fifth floors."

Adding Web services to link the floors without a master plan may not improve the situation, he warns. Should you just add a stairwell to link the two floors, or do you need an elevator shaft for the entire building?

Software can be used to enable SOA, but it doesn't create the architecture: a comprehensive strategy does that. "Once you map out the SOA strategy for an organization, then you can take out bite-sized pieces that are SOA-enabled projects. If you don't do that first, you're just adding another hairball to systems," he says, pointing out many SOA silos are starting to pop up in organizations.

"If you're using it to service-enable a couple of functions, but those services aren't spread over the entire organization with the proper governance around them, they'll just get lost in all the other hairballs in the IT infrastructure."

SOA in health care

Canada Health Infoway is promoting SOA to evolve e-health records across the health care sector, says Michael Martineau, e-health practice leader at the Branham Group, an Ottawa-based research consultancy. "Infoway has produced reference architecture and provincial blueprints as guidance for this. All the provinces reference it in their plans," he says, noting it's all based on health care organizations exposing a suite of services that others can use.

The SOA framework developed by Infoway is not fundamentally different from the federal government's approach, explains Martineau. "A framework can imply a variety of standards. Health care has some unique messaging standards and other differences in nomenclature. For example, when a service returns data, how it's interpreted will be different for lab data compared to an e-commerce transaction. But the conceptual framework is the same."

It's possible to develop e-health records without SOA, but Martineau points out calling them "records" is misleading. "It's a bad term because it's not one single record. The data needed for it resides in different systems such as medication, labs, etc. An e-health record is really a system to pull data from different sources, so this initiative is a great big integration project. SOA is the best way to do it, and that's why Infoway is pushing it."

But uptake of SOA is relatively low in the sector. In a Branham survey of health care senior IT staff conducted last fall, about half said they had no plans for SOA. "This has to do with the proprietary architectures and complete vendor suites that are prevalent in the sector," suggests Martineau. "Their view is that whatever the vendor gives us, that's what we're going to use, so SOA doesn't make sense for us."

Infoway faces many challenges in developing this area, he says. Many large health care IT shops such as hospitals are spending most of their limited budgets on maintaining their systems, so moving on SOA is very difficult. Nor is there any formal mandate to adopt SOA, beyond requiring it in project plans if organizations want to access Infoway dollars.

"But most of Infoway's projects to date have been provincial or regional projects, and I haven't seen much trickling down to individual health care organizations," says Martineau. "And there's the chicken-and-egg problem of vendors, who have to adopt SOA as well. IBM has been aggressive in moving to SOA, but some vendors are resisting as it serves their interests to lock in their customers."

In Ontario, the regional reorganization into local health integration networks (LHINs) is providing a driver for SOA adoption in some areas, he says. There are two main approaches. Where there are many versions of a proprietary platform, health care organizations are consolidating their systems around one vendor's platform. In Northern Ontario, for example, many hospitals are Meditech shops, and these will eventually be consolidated into a single version for the region, he says.

"We're seeing the same thing in other parts of Canada. Until Meditech moves on SOA, it'll be harder for these regions to move as well. But there are products from other vendors that wrap around Meditech to expose services as SOA to other apps, so it's still possible."

In areas such as the GTA that have multiple vendors and platforms, health care organizations are starting to adopt SOA to integrate within their regions, he says. SOA is the best approach for building modular interfaces around disparate platforms to glue health care systems together within a region, without getting bogged down in technical specs, says Martineau.

"For the first time, technology and business people can talk the same language," he says. "The process for conducting lab tests can be defined as a series of services and functions, and you don't need to care about the technical details or the programming language."

There are back-end advantages as well, he adds. "You can take a service and split it across several servers, do load balancing and so on. People don't care about behind-the-scenes adjustments. The old way, you did have to worry about this, as the business architecture was different from the technical architecture."

SOA in municipalities

Vendor issues also play a role in the municipal sector, says Roy Wiseman, CIO of the Region of Peel. Municipal software is a very niche market with small vendors providing specialty software tools. "They're not big-10 names," he says. "It's software for tasks like the collection of payment for parking tags and registration systems for voters."

Municipalities are primarily looking for off-the-shelf products, but their specialty vendors are slower to adapt to new technology such as SOA. Nevertheless, Wiseman says, he sees significant changes afoot in the future. "SOA drives the software development industry more than it drives us."

Larger municipalities such as Calgary and Edmonton, which have SOA projects under way, have more money and influence, and can attract vendors who will customize their wares or undertake software development projects themselves. But smaller municipalities don't have the same clout or resources, he says.

SOA is starting to trickle down to the municipal level. "Over the next year, we'll start seeing it referenced as a regular feature in RFPs for off-the-shelf and custom solutions," says Wiseman. But most vendors aren't ready to respond at present. "We're shooting ourselves in the foot if we make it a mandatory requirement now, as none of the providers are at that point."

Once it gains traction, Wiseman believes SOA will play a powerful role in sewing together the individual geographic information systems (GIS) across municipalities. Searching for GIS-based information across a province or region would become quick, simple queries instead of labor-intensive exercises.

"If you look at Peel or Ontario, there is really only one geography," he says. "All of us have one subset of information about that region, be it street networks, gas and electricity lines or land parcels. We can build apps to pull that in from different sources, but we all need to do that in a standardized way. Building one-to-many interfaces is where there's real complexity."

Simplifying interaction between organizations is where SOA has the greatest value, says Wiseman. "We can all build one-to-one interfaces internally, but when you get into inter-jurisdictional dealings, then you need a common language."

SOA can provide that Esperanto. But due to all the hype, some believe SOA is just another technology fad. While Wiseman doesn't believe SOA is revolutionary, he does believe it's here to stay. "It's the evolution of the same idea that's been around for years: object-oriented programming, CORBA and so on, which are all about fitting together software components so they interoperate." SOA will likely continue to evolve, perhaps into something with a new name, but the fundamental approach to unifying systems will remain the same, he says.

Rosie Lombardi is a freelance writer based in Toronto. Contact her at

| 1 2 Page 4
ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon