Bits at a time

Could service-oriented architecture (SOA) finally be maturing? It seems so. Three years ago, when the hype cycle was at its peak, SOA was being plugged by every enterprise vendor under the sun as a way of getting more flexibility and re-use for the customer's software spend. Even some traditional ERP vendors said they were moving away from the large monolithic projects to more agile delivery.

Instead of the large integrated project, SOA says applications are composed of individual services, loosely coupled, and linked together with tools that allow business processes to be automated on the fly.

That's the theory anyway. SOA's success has been mixed: it has proved an excellent way to wrap legacy applications, but the re-usability has been harder than it looked in 2006.

Malcolm Rabson, MD of Dariel Solutions, says there has been success connecting islands of information. "Because SOA is such a misinterpreted term, we've tended to do different things. We've had the most success getting connectivity and interoperability between islands of data. To go further, we need to get the data onto a dashboard and get it into a business process. The secret is not to do it in isolation, but rather analyse the business problems and processes, and then try to make it accessible to everyone. The fact that it's service-oriented is a by-product."

Rick Parry, MD of Progress Software, says lessons have been learned.

The larger the customer, the more confused they are about SOA.

Joe Ruthven, SOA sales lead, IBM SA

"Two or three years ago when the modern wave of SOA really got started, there was a lot of talk about re-use," he notes. "Today, we've realised that actually it's not that simple. But from an application software perspective, we're in for a huge paradigm shift. What is our customer used to? What do they expect? For the past few years, they've been used to the big bang and huge great monolithic ERP solution with everything integrated and finely coupled. The sort of benefit and return a business expects to get out of that is totally different to what they should be looking to get out of SOA."

But what exactly is SOA and what should organisations be doing about it?

Joe Ruthven, SOA sales lead at IBM SA, says the larger the customer, the more confused they are about SOA.

"If you walk into a bank and utter the term 'SOA', you'll find yourself in the IT department so quickly that you won't know what happened. It's not about technology. The problem is that although the IT guys think they know about the business, they don't. They're not close enough. Business analysis is where it must start. The technology is there. There are more than enough tools available today to implement any kind of SOA that you want. But as long as you don't understand the business problem, you're wasting time."

Parry agrees that it's not about technology.

"What is SOA really? Some people think of it as a product, or as a project. What is it? If you go into any company today and ask, you'll probably get a different definition from every person. In the early stages we will ask a company what they mean by SOA, because it isn't about a product or a technology. It's a philosophy, a strategy and an architecture - that's what the A in SOA stands for."

Vish Rajpal, GM of systems integration at Business Connexion, says what it can do depends on the approach.

It doesn't have to be an all or nothing.

Sam Selmer-Olsen, MD, Bateleur Software

"If I approach a business person, I don't even mention SOA. It's about how the customer can get a better return on his assets. At a technical level, everyone wants to talk more about governance, policy and procedure. Where I see failure is the lack of tangible results. We need to show that there is value in SOA, especially in large organisations. People pump money into projects and want to see a return. We have the skills as vendors and integrators. Let's show the customers what we can do."

Quinton Pienaar, CIO of MIX Telematics, is an end-user who has gone down the SOA road.

"We needed integration and architecture so we bought the tool from the vendor," he says. "What we learned is that SOA suits an agile business and if you need lots of integration of disparate apps very quickly, then SOA is a good fit. But I've seen bad implementations where people jump on the bandwagon and do it for its own sake. It fails when the developers don't understand how to write code in an SOA way, when they don't follow the methodologies."

One of the key methodologies in any SOA implementation is getting the upfront architecture right.

"Architecting is key," says Mike Steyn, director of Trivector. "You need to tackle problems with proper design and architecting upfront, otherwise you'll never get the benefit. This is not just at a technology level: it's about how to design at a business level so that re-use can happen. We haven't even started to unpack that. I think that business architects are going to be key people to make SOA work. But very few people understand business architecture."

Clive Hatton, enterprise architect at RealIRM, says design and architecture is critical and that it is ignored at an organisation's peril.

"At a business level SOA is about agility," he says. "It's about creating an organisation that is agile, that can adapt to the environment and make changes quickly to be competitive. The thing that worries me is that there have been a number of technologies in the past that have promised this: from object-oriented programming to enterprise application integration. To be honest, as an IT community, we've never really delivered on the true potential of those technologies. I think we treat design quite glibly, but we have to think about it very consciously. How are we going to design things at various levels? What will it take to achieve what we want? If we don't do that right up front in the SOA world to achieve re-usability and all the other things it promises, then it won't work."

Sam Selmer-Olsen, MD of Bateleur Software, agrees that architecture is key, but notes one problem.

"Architecture is a difficult sell," he says. "Workflow and BPM have certainly made it somewhat easier because they are strongly about PC and Web interfaces wrapping legacy functionality. If you're going to incorporate mainframe data with a front end, SOA is the new way to do it."

Eugene van Rensberg, director at K2, concurs that BPM has lessons for SOA.

"We're learning the same lessons that the BPM vendors have been learning. They've been through the same questions from customers: show us value, show us a successful implementation. Why is business not involved? Why is business not selecting the tool? I keep hearing that same strategy we went through with BPM repeating itself in SOA. People still see BPM as a potential killer application for SOA if we could just combine those attitudes and lessons learned."

But Trivector's Steyn cautions against over-architecting.

"The architects have a responsibility to provide design philosophies, guidance and governance. Unfortunately, it's a big mistake to try to over-architect something. What's needed is just enough architecture just in time; there are just those three or four things that we have to get right in order to show value."

And SOA does have the potential to reduce the confusion between business and IT, according to Godfree Dzebu, GM of systems integrations services at Cornastone.

"If you look at traditional organisations, you find that the requirements are defined by the business and then IT goes and does the job. When you use SOA techniques, the language gap between the requirements from business and the implementation by IT is minimised."

So how does one approach an SOA project correctly? Mary Brady, international account principal at HP, says there's the ideal way and there's the pragmatic way.

"The pragmatic way is to start off small on various projects and show a deliverable. To talk about big ROI is not possible. We have seen benefits from small projects where people are using SOA to integrate between different systems but they do need to go the extra step beyond that and look at governance and their policies. Our approach is pragmatic - don't use a big bang, start small and develop principles as you go."

IBM's Ruthven notes that this method has another benefit.

"One of the advantages of going small and doing something for one line of business owner is that he will then sell that to his colleagues," he says. "If you can attach a project to a line of business executives and demonstrate ROI in three to six months, everything else follows."

Bateleur's Selmer-Olsen has done just this.

"Because wrapping existing applications doesn't have to be an all or nothing, it can start as small as you like. With one of our clients we've done a single business function that they wanted to make available to a customer across the Internet. One program needed to be wrapped."

What happens then is that instead of applications or entire platforms, components can be mixed and matched according to need. Richard Firth, CEO of MIP, says the ugly term that everyone understands - best practice - is no longer about ERP from end to end.

"SOA allows customers to choose best practice at a component level. One business unit might want to do something one way but another one might need to do it a completely different way. We're building a house and putting in plug points. The plug isn't there for its own sake, but so that you can use a heater or a toaster. The time constraint for SOA is to put in the architecture upfront for the bigger applications to be able to source or issue information at will. We went through a huge phase in IT where everyone chose a database. You would get asked what database you were running, which has nothing to do with what applications you were running. But the technical evaluation is completely changing now, so the business can choose the solution that's right for it and integrating the components that are right for it."

This is good thing for businesses with long technology refresh cycles but quicker business cycles, says Ryan Purvis, business unit manager at 3fifteen.

We can now do things in bite-sized chunks.

Rick Parry, MD, Progress Software

"SOA principles allow for looser coupling so if technical refreshes happen over a five-year period, but your business needs are evolving more quickly, integration is easier. You should be able to change the back-end without interrupting the front-end and vice-versa."

If that can be done one component at a time, so much the better. Concludes Parry: "The great opportunity is that we can now do things in bite-sized chunks."