Canadian city trumps biz world with SOA
Service-oriented architectures are expected to have a stronghold over future apps
but those implementing the integration process today continue to encounter uncertainties
from the corporate world.
When the City of Edmonton launched an SOA pilot program—that automated
its apps for new employee records across multiple information systems—it
meant bureaucracy beat businesses to the punch, but city app developers learned
that winning the SOA race has its pros and cons. Despite strong forecasts, not
everyone is sold.
“The pilot was successful in terms of people saying, ‘great technology,’”
said James Donahue, enterprise architect and project manager, City of Edmonton.
“But who’s going to support it?”
After reviewing a myriad of software including VA, Oracle, TIBCO and SAP’s
NetWeaver, Donahue settled for Sonic Software in July 2005, and teamed with
Online Business Systems, launching the pilot that integrated SLIM, SAP, POSSE
and PeopleSoft apps for Canada’s fifth largest city.
The city used Sonic’s enterprise service bus (ESB) to automate employee
records procedures. The city employs 10,000 people, including more than 100
IT professionals. Those IT employees are responsible for supporting 142 of Edmonton’s
1,000 plus apps.
“We took a very non-committal approach,” Donahue says. Despite
demonstrating resistance early on, Donahue’s crew pulled off four weeks
of training in just four days. Flexibility and hands-on learning, he said, were
instrumental to the program’s success. And having an SOA solution to “showcase”
to businesses became paramount.
“This was an odd situation for municipal government to be in. For the
first time we were ahead of the businesses,” Donahue said.
Donahue’s plan to integrate enterprise apps SLIM, SAP, POSSE and PeopleSoft
worked but he cites steps that may have help avoid pitfalls. He suggests less
software research and to allot more time for vendor negotiations. Donahue advises
others to consider the impact with supporting new middleware and CPU licensing
costs, with the advent of multicore servers.
He also says develop an SOA strategy and line up production work early on.
Donahue worked with Murray Laatsch, integration architect, Online Business Systems,
performing “technology spikes,” which enabled city officials to
review integrated apps; four user case scenarios allowed them to visualize how
each department would be affected by those apps.
Reflecting on the recent pilot program, Donahue now plans to work with officials
on a city-wide SOA strategy—a strategy he hopes will support Edmonton’s
internal shared service call center through POSSE integration. Besides an SOA
roadmap, Donahue has also identified the need for more tools and more business
“SOA is something that has more longevity than the uses of the technology
themselves,” Donahue said.
John Bachman, senior director of product marketing, Sonic Software, agreed.
But he said at this stage of the game, it’s critical to get businesses
on board and promote SOA solutions that work.
“It’s not fair to say the benefit of SOA is agility. I think that’s
under-selling it,” said Bachman.
While SOA integration enables IT to implement new business functions across
varied systems, Bachman says it can cut costs by “institutionalizing”
uses, creating methods that are reusable. Bachman says SOA integration is a
multiyear project that developers should approach with a high degree of flexibility.
He suggests start small, modernizing file processes first—an app that
“dogs” developers every day.
Gartner, Inc. predicts SOA will lay the foundation for 80 percent of new development
projects by 2008. However, Bachman cites a 2005 SOA Webinar where 58 percent
of attendees admitted either they were not using SOA or they were simply in
the learning phases.
“We’re talking about a very early market here,” Bachman says.
“If you find you’re still confused about everything going on [with
SOA], you’re in good company.”
Jason Turcotte is an assistant editor at Application Development Trends. He can be reached at email@example.com.