SOA is simple - really

Vendors could do themselves a favour by demystifying service-oriented architecture (SOA). There's nothing magical about it: businesses use service-oriented architecture all the time.

A building company will use an associated rubble removal service that kicks in once the building service is completed. The two services are not the same thing, do not depend on each other, yet have a clear relationship that contributes to the overall smooth operation of the business. They may use the same truck: one service to get the materials to the site and the other to take the rubble away, but both services are still independent, although coupled.

Sharing the underlying technical function of transport is cost-effective for a business that provides both building and rubble removal services. It's a simplified example but it illustrates many of the basic principles of how SOA should work: loose coupling of services, optimisation of business processes, sharing of underlying technical services for lower costs and nary an IT acronym in sight.

SOA could do with a healthy dose of simplification. For a good five years, enterprise customers have had to deal with a great many definitions of SOA, all subtly different and far too many full of IT terminology instead of business service descriptions. And there's been a battle between the 'top-downers' (those who see SOA defined and designed by management), and the 'bottom-uppers' (who hope SOA percolates and gains traction through the organisation from the users upward).

Morne Rossouw, presales manager at Software AG, uses Lego as an example.

"The individual Lego block is the technical service, the building block out of which everything is made. Every block has a value to your organisation. But as soon as you take them and build something with them, then although you have more value, it's less agile. That's why I think bottom-up cannot work because you won't know what technical services to build.”

"If someone brings you SOA-in-a-box, then slap them and send them home."

Morne Rossouw, presales manager, Software AG

Adele Melvin, senior manager at Accenture, has a different definition of a technical service.

"We see technical services as foundational services that you have to build. Those are foundational to any IT infrastructure: your monitoring tools, error handling, incident management and so on. Business services are services that enable business capability and they are built top-down. They have to be built top-down. But I can't see foundational services being built top-down."

So how does business look at SOA? Is it possible to replace existing software with a bunch of loosely-coupled services that are difficult to test, have uncertain ROI and introduce slowdowns? Mike Rolfe, MD of Cordys Software SA, says the approach has to be pragmatic.

"SOA is an evolution rather than a revolution and you need to look at it to see what business value you get out of it," he says.

"If you don't do that, it becomes a means to an end, but for what? If you look at very large sites and large implementations, everything that gets done there is pragmatic. You do one of two things. You either look for real return on investment, which means developing the services you require, and you don't necessarily choose low-hanging fruit either because it might just be easy to do. Or you start with a reference architecture where you can analyse the portfolio of services and see whether you can go the SOA route or not.

“For instance, an application may have one instance per year of usage so it's pointless making it an SOA service. Something else might need a very high transactional speed and you don't want to put another layer of overhead. SOA is a good idea if you have a diversified or dynamic infrastructure or product. An insurance company, for example, may have products that have to change by the day or by the minute to be competitive."

Kree Govender, key account manager at Gijima, says business value is the driver but cultural change an often unwanted side-effect.

"If you strip it down, SOA is for creating business value. What makes it very different and difficult is that if you have a fledgling organisation, nothing's in place and it's easy to move the blocks around and channel them.

“However, if you have an organisation that has been running for a very long time, there's a plethora of tightly-coupled systems and it's hard to strip all of that away.

“Unfortunately, business in SA doesn't realise that to put in SOA requires their active participation. They think of it as some sort of IT thing. But it needs constant investment. You have to constantly monitor services. Are they being used? Is this deprecated? Is this useful? ROI is one of the hardest things to show and at some point it will have value."

Clive Hatton, senior consultant at RealIRM, says business needs to understand the benefits it gets from SOA but the challenge is how to explain it for them to understand.

"How soon will they get benefit? It may not be soon, it may be over a long period of time and it may take a lot of work to get there. And you need to understand the architecture. It's not just application architecture but the data architecture, the networking and the business architecture. Without understanding those, you won't get the implementation right."

Rolfe says the way to get going is with a new process.

"Where do you start? The best place is with a new process where it's a green field. And then what you do is you systematically produce the services that you need to drive the new process. What that will do is show the company what agility is really about, which will then fuel the fire for further movement into the space."

But companies often underestimate the effort required to move to SOA. Malcolm Rabson, MD of Dariel Solutions, says: "We've done about 16 SOA implementations and you can split them between corporates and SMEs. They are two very different approaches. Success is always based on the involvement of the customer.

SMEs tend to say, 'Call us when it's ready'. I recently asked a JSE-listed company CEO who runs his company and he laughed and said, 'I do'. I replied, 'No, you don't; your middle management has taken this bus and asked us to build a Ferrari and now they want a Porsche. It will cost R2 million to do that change. Will they still get a bonus?'

“Middle management has no skin in the game. We have kick-off sessions to flush out this sort of thing and identify business people to own and drive the process. When we explain what a business user really is, they try to say we'll get him to help us out between nine and 10 in the morning. But what they need to be doing is making him sit with us for a year.

“The issue has never been the technology framework - it's the commitment of the users. Business people always complain how IT doesn't deliver, but there isn't the necessary involvement."

Technically, it has become easier, though, he says.

"We've found that the tools have got better at facilities integration and exposing services. And we have also got better at looking at business processes. But instead of sweating the Cobol assets, customers are dehydrating them. Why not? They work well. Cobol systems are still the backbone of much of the financial world."

How do you get business buy-in? For Rossouw, it's about building bridges.

"SOA is a methodology, not a set of tools. It's bridging the gap between business and IT and what IT needs to deliver. What business demands is agility. I'll give you two examples of customers of mine. I've designed SOA architectures for them and they don't have dashboards or enterprise service buses. If someone brings you SOA-in-a-box, then slap them and send them home because they are going to waste your time.

“The first customer took its legacy environment and did an SOA service by design. A service is a piece of business logic that can execute, either technical or orchestrated - it doesn't really matter. This customer got huge benefits redesigning its system by orchestrating it in the language in which it was written.

“Then I have another customer that does have an enterprise service bus as part of its output strategy. But the orchestration is still native. Let's be honest: no service bus is going to outperform a mainframe with a batch job. When customers ask what the final result will look like, I say we'll do mash-ups - this portion of your system combined with another one. I won't get rid of your green screens but I will give you modern screens and web portals that enhance what you have."

Rolfe agrees. "The largest clearing house in Europe uses our technology but they don't use it for the fundamental transactions, because the primary requirement is speed. However, they do use SOA for all their customer requirements."

"Businesses don't realise that to put in SOA requires their active participation."

Kree Govender, key account manager, Gijima

JP Morgenthal, author of Enterprise Information Integration, points out that many people in the IT industry use the term SOA quite freely, most often as a way of building software systems. That is possible if the systems perform clearly-defined business functions. But, he says, if the conversation devolves into a discussion about 'SOA platforms' and 'utility services', then these are "sure-fire indicators that the discussion has degraded into software design methodology and has left the realm of SOA".

When in doubt, think of the independent yet loosely-coupled services of the building company, sharing technical services for more efficiency. You might get rid of a lot of unnecessary rubble yourself.