Infrastructure revolution

Service oriented architecture (SOA) is less about technology than changing the language of IT service delivery. The good news, then, is that SOA can be implemented at a modest cost using existing technologies. The bad news is that any IT model that hinges on semantics is more susceptible to spin than usual, leaving companies potentially out of pocket and reinventing the wheel.

service150Service oriented architecture (SOA) is less about technology than changing the language of IT service delivery. The good news, then, is that SOA can be implemented at a modest cost using existing technologies. The bad news is that any IT model that hinges on semantics is more susceptible to spin than usual, leaving companies potentially out of pocket and reinventing the wheel.

SOA is a way of organising data and applications that enables output to be delivered in services that are meaningful to the business. This requires the description of the business function to be separated from the content and process. By wrapping data and process in a layer, and publishing it as a service in a standard format, a service can be called up on demand by other services.

In theory, this separation avoids overlapping applications and duplicate data such as repeat customer information in billing, ordering and marketing applications. The separation is also designed to avoid the artificial dependencies that spring up between business function and underlying application resulting in integration gridlock.

A media company interviewed for this article sends the same batch job of customer updates overnight to a range of applications, regardless of the requirement. The arrangement is overkill - and costly - and is being reviewed in favour of reorganising the customer update data into a service that can be called on as and when needed.

But, as in any new regime, there are pitfalls for the naive. One is that people become SOA zealots and convert anything that is binary into a service. "If you express everything you do as a service, you will end up with the same old mess all over again," says Gary Barnett, research director at analyst firm Ovum.

The real trick in designing services is that they need to have enough function to be useful but small enough to reuse. "Size matters," says Barnett. "Get single order line" will likely make a poor service because it is too granular for most interfacing applications, whereas "get order detail" will probably contain enough information to be useful to a variety of applications.

Likewise, when components of a back office application have to be closely integrated to maintain transactional integrity, IT departments are best advised to stick to enterprise architecture integration methods. "Services come into their own for loosely coupled integration such as when an application or process is exchanged across a clear boundary, whether departmental or inter-company", says Barnett.

"If you needed to exchange data with a partner or customer, it probably would not be desirable to modify each other's systems. However, it probably would be feasible to agree a format to exchange material and then extend or modify your own system to complete the exchange," he says.

When used appropriately, the beauty of services is that they do what they say on the tin. "Changing language is incredibly powerful," says Ian Cartwright, consultant at IT professional services firm ThoughtWorks. "By changing the terminology people get a glimpse into each other's world and it opens up the possibility of new conversations."

Rather than go cap in hand to the board to request "extra CPUs to improve the performance of customer billing applications", for example, IT could request extra funds for investment that would "improve the speed at which customer payments are turned around".

Whether describing the service that a computer resource provides will actually reduce duplication and save money is a matter for debate. However, it would at least make duplication more visible, says Cartwright, because the service labels are explicit and in a language that people share.

The other big argument in favour of SOA is that it enables reuse. This has been promised before by other technologies and is a tenuous claim, according to experienced industry watchers. Companies that deploy SOA often hit difficulties afterwards because developers have no means of identifying or sourcing existing services, says Barnett.

"The big inhibitor to reuse is not technical but knowing that something exists already and how to use it," he says. "Pockets of reuse are so exceptional that they are not statistically meaningful." Barnett recalls that when he was a programmer anything that took longer than half an hour to source would get rewritten.

In the meantime, web services technology is driving the renaissance of SOA but is responsible for creating further misunderstanding. Web services is a technologically agnostic way of enabling different applications to talk to each other irrespective of programming language or operating system. It uses Soap (Simple Object Access Protocol) as the envelope or wrapper and publishes a URL that can be found over the internet.

However web services are not essential for SOA - message-oriented middleware does the job equally well. And for internal services the advantage of using available "glue", such as RMI (Remote Method Invocation) to Enterprise Java Beans or message-oriented middleware, is twofold: you can reuse existing middleware technology and you avoid the overhead of using XML.

If necessary, such services can later be exposed as web services to business partners. Many companies still use virtual private networks for business partners to connect to web services in order to keep transactions secure.

The other trap is that IT departments think that developing services is the end goal of SOA, whereas it is a philosophy about the whole lifecycle of services. "I can create machine-readable definitions for functions but they are useless if the developer does not know how to use them," says Barnett.

If developers are still in doubt about when they are doing SOA and when they building web services, renovating a house is not a bad analogy. "Web services are the mortar. But you also have to consider the bricks and the shape of the building," says Barnett.

Case study: Colt Telecom adopts SOA to cut costs

Colt Telecom started moving towards a service oriented architecture to cut costs. "We had to drive down the cost of operations and it is being made easier by the arrival of web services," says George Whitehouse, enterprise architect at Colt.

The telecoms provider grew fast in the 1990s by rolling out fibre networks in major cities. It repeated this model in 13 European countries and each spawned its own operational systems such as billing and fault management in order to support the region's business.

Rationalising the duplicate systems into one datacentre was the next stage for the company's growth. Colt had more than 10 instances of each core application and many of these contained duplicate references to customers. Consolidation was a way of achieving one, coherent view of all customer transactions.

SOA was seen as a means to achieving both goals because it separates business logic from enabling applications. In practical terms this means that it is possible to add a new customer name to a particular function without having to mess about with filling in values in underlying fields. "If you abstract away to the business logic, then you can just deal with that rather than having to worry about the system behind it," says Whitehouse.

Reuse of business functionality is a key driver for the project. It is a continual progression rather than one big bang, says Whitehouse. His team picked areas that had a major impact on the business and the first task was to build a master repository of customer data that all other applications interface to.

Although Colt is keen to embrace the philosophy and methods of SOA, it recognises that the use of web services is not always applicable. When developing interfaces between internal applications Colt uses webMethods' toolkit as its messaging middleware and has relied on tried and tested technologies where transactional integrity is necessary. 

Web services are only being applied where guaranteed messaging is not a requirement until the web services standards for secure messaging are mature enough to adopt. When the company wants to interface with external suppliers in a business to business context, it uses mature technologies such as XML messaging over HTTPS. "These are standard technologies and can be done securely," says Whitehouse.

Colt takes a pragmatic approach to the adoption of web services and uses them only where they make sense for the business. The publishing of web services using the UDDI standard did not appeal because it entailed publishing the service to the wider world - an exposure that Colt does not want or need. "B2B is all about setting up a secure environment with trusted partners," says Whitehouse.

The hardest part of developing and deploying SOA is that the approach is primarily about design, not technology, says Whitehouse. "It is hard to get people to look outside their functional area. Developers tend to optimise what works well within their framework, but not what is good for the business."

Case study: Celesio aims to be more responsive to market demands

Pharmaceutical distribution company Celesio examined service oriented architecture in late 2003 as a means of responding more quickly to market demands, including the regulatory changes that are part of the industry.

"Rather than just replace our legacy systems with off-the-shelf packages or build new systems from scratch, we decided it made more sense to wrap some legacy systems as services, build new services and use services from off-the-shelf software where appropriate," says Simon Bennett of Celesio's corporate IT systems architecture group.

"By separating out the business process from the underlying application that delivers it, it becomes possible to implement new services and new variations of process more easily."

Although the architecture made perfect sense, Bennett says the "hows" of implementation have been taxing at times. One of the challenges has been gauging the correct level of granularity for services.

Another difficulty is achieving a top-down, centralised view that is essential for reuse. "If you do not impose this, everyone ends up developing their own service, and without reuse you end up creating new legacy systems," says Bennett. "Without reuse, it is no different from doing a rewrite of the legacy systems, and that takes too long.

"We are looking at service repositories and registries. A repository will meet our needs by storing actual implementation artefacts rather than just meta data."

Read more on Web software