Businesses everywhere are investing in service-oriented architecture (SOA) – or thinking about doing so. And while it may be a very smart move for some, it will probably mean doing things differently from what is familiar.
For one thing, both the business side and the developers have to alter the way they think about how an implementation is judged, because SOA may very well be invisible to most of its stakeholders.
“If done properly, an end user should never know whether SOA is being used or not,” said Bruce Johnson, a partner and consultant at Toronto-based ObjectSharp.com.
“It’s a little like asking a homeowner if they prefer copper versus galvanized steel pipes in their home. In the vast majority of cases, it doesn’t matter to the homeowner. Water gets delivered and everyone is happy. The same is true of SOA. The magic that makes it happen should be completely hidden from view.”
A philosophy
According to Johnson, SOA is more of a philosophy than a technology. It requires a shift in mindset because developers no longer need to know what specific objects will be used for – instead, they need to develop things with a final outcome in mind.
Using a technique known as “loosely coupled” programming, SOA allows the code to be more flexible, and used in many different ways, in pieces or joined, within an organization.
This type of programming also reduces the risk that a change in one application/module will force a change across the board.
Management buy-in can be difficult with this scenario, however, Johnson said, because it’s often impossible to visualize what changes have taken place in back end applications.
“They are likely to say, ‘Why did you spend six months on this and not change anything?’”
Although hopefully, the end users will notice one thing – more integrated systems, said Jonathan Eunice, founder and principal IT advisor, at lluminata Inc. in Nashua, N.H.
“That’s the bugaboo of a lot of IT – that it’s still largely islands of automation. There were previous ways of interconnection, but the difference is that SOA gives you very pragmatic mechanisms for going about achieving that (connectivity),” he said.
Eunice said, with SOA, the focus is not on how each piece works, but on bigger and bigger systems working together. While objects put flexible structures around data, the SOA thought is to put flexible structures around interfaces, he said.
“It turned out that object approaches were much more useful within individual programming groups, and they really didn’t say much about how you connect different systems. SOA focuses on what a module accomplishes, not how it’s structured internally. The answer is you don’t know, you don’t care. The focus should be on what I can ask it to do,” he said.
“The interesting thing about focusing on the interfaces, or the services, is that it also changes the way that you think about investing in, and managing, and deploying software.”
Greater integration was what Agfa HealthCare Inc. was looking for when it implemented an SOA project in 2003. And it delivered – but not without some challenges. The main difficulty was the fact that it was a very new concept then, and they had to write most of the code from scratch, said Alan Farquhar, senior software developer at Agfa HealthCare Inc., in Waterloo, Ont.
“We wanted a unified client for everyone. But it was a risk – we didn’t have anyone to blaze a trail for us.”
The company had a specific technology team devoted to the project. Developers were divided into different groups, depending on function, which was a new way of working for them. “The heavy security layer added to the complexity. Anytime there are layers, it makes troubleshooting more complex.”
Today, the company’s IMPAX Enterprise – a digital imaging solution for the health care industry, is the successful end result of that project. It features a unified client that adjusts to different working environments.
“Benefits have been great. You don’t go the SOA route unless you have a really good reason. It’s not for everyone. But it was perfect for us.”
Speed of delivery
Fairmont Hotels and Resorts has also had a lot of success with SOA recently – it allowed them to develop a portal for a newly acquired hotel chain, called Raffles, within a span of two months versus what would have taken a year.
“It has really increased the speed to delivery, and for our developers, it has simplified what they have to do. We are able to deploy what we are doing on the Fairmont side to the Raffles in a very rapid fashion,” said Vineet Gupta, vice-president of technology at Fairmont Hotels and Resorts in Toronto.
“We have always planned on adding new hotels and wanted that to be as simple as possible. We have business process people as part of our IT department. We view ourselves as enablers, rather than just pure techies.”
For Fairmont, SOA was not entered into lightly. It started three years ago, and required a large investment in hardware, software and implementations across about 120 sites.
Standardization was the key goal, Gupta said.
They developed different portals that use same architecture for their North American sites, and going global with the systems is the next step.
“What happens is the actual API, the middleware, keeps getting larger and larger,” he said.
“The basics remain the same, but the way you deliver it changes.”
