Information Age (IA): Many IT managers are interested in the concept of the service-oriented architecture (SOA) but at the same time fear that implementing it in their own organisations would have a hugely disruptive effect on day-to-day business. What has BAT’s experience been?

Kevin Poulter (KP): Certainly, the decision to establish an SOA involves a long-term architectural vision and commitment. In our case, that

decision can be traced back to a little over two years ago, when we were involved in developing a new business IT strategy. One of the key themes that kept coming up was that of ‘joined-up business’.

From the beginning, we set out to build an SOA framework that could be implemented on an incremental basis. We knew that there was no way the project could work if we had to go to the business and ask for tens of millions of pounds upfront without being able to prove any business benefit.

IA: So this has not been a ‘big bang’ implementation?

KP: Not at all. Since early 2002, we’ve focused on establishing the framework and filling it out gradually, selling it internally to our colleagues and doing a number of proof of concepts to understand what we need to do in order to make the SOA successful for BAT as a whole.

I was lucky in that I already had a team that had done a lot of work with distributed objects in the late 1990s. We’ve taken that experience and used it to establish how standards like web services might be deployed to assist us in integration tasks right across the business.

IA: So what aspect of the SOA are you and your team working on right now?

KP: I suppose I’d have to say that it mostly involves looking at the kinds of technology that will enable us to exercise some kind of control over the SOA. Right now, for example, we’re very much focusing upon establishing a web services registry that will help us with governance and overall management. We’ve got some request-for-proposals out now for that kind of technology and we see it as a crucial part of the project.

An SOA clearly demands a service registry. It will enable us to see at a glance what web services we’re using and also help us to handle the run-time and lifecycle management of web services. That’s really important when you are breaking up some of your mission-critical architecture into finer-grained components. We need to establish an entirely different management regime in order that we can answer a number of crucial questions: How will we handle the versioning of those software components? How will we cope with multiple versions? How will we commission new web services and decommission old ones? How will we handle quality of service?

It’s a whole new management challenge. In our previous life, we used SAP R/3 and it was a nice big application that ran on a particular set of servers. We knew where the servers were, we knew how many users we had and they all had their own logins.

In the new world of the service-oriented architecture, we still have SAP software but in the form of a set of components that we will combine in different ways to form new internal applications. That throws up a whole new set of challenges; for example, security is a prime concern because software is opened up to new communities. You also need to think about managing service-level agreements because you go from having a very fixed number of users to having components that are used by different people in different ways and in a number of different applications – and potentially also by trading partners outside of your business. And above all, you’re working at a whole different level of granularity.

IA: Has the early-adopter stage of service-oriented architectures required you to recruit new members of staff? How easy is it to find people with the right skills to support that SOA vision?

KP: Recruiting has been difficult – in fact, I’m working on that right now! The difficulty is that we can’t approach the vision from a purely programmatic point of view. We must also approach it from an architectural and business perspective. Getting people that have the right balance of development skills but who can also see the bigger, architectural picture and have got the right level of business insight is not straightforward at all. To some extent we are getting round these issues by finding newer, cheaper ways of doing current tasks so that we can focus more on the long-term vision. Our deployment of an application router device from Cast Iron, for example, is an important part of that. We started talking to the company in July 2003 and quickly saw an interesting opportunity because their platform embodies many of the technology standards and architectural standards we’re advocating in our SOA work. It’s based upon web services technology and it leverages BPEL [business process execution language].

At the same time, however, Cast Iron offers integration capabilities in a palatable, accessible form that enables operational units to build links between systems quickly, easily and cheaply. So it suits both our short-term and long-term objectives. It will tackle the day-to-day problems of integration by enabling us to implement a lot of the lower-level integrations that, while they’ve not exactly been a struggle in the past, have taken up more resources in times of both money and time than they should have done.

IA: How has senior management responded to your SOA vision?

KP: In reality, I don’t think there is much awareness of SOA. To be fair, quite a few senior managers are aware that we’re working on this new architecture, but the main thing they really want to see is IT solving the business problems – and hopefully more cost-effectively than in the past. How that’s achieved, however, is most probably not utmost in their minds!

But to my mind, we’ve made great progress. By getting into the vision and setting a roadmap early on, we’ve had the opportunity to really understand what the issues and challenges really are. And in the future, we shall be reaping the benefits of ease of deployment, speed of implementation and agility. By taking an SOA approach based on web services, we can loosely couple software so we can be more agile when things need changing and do it cheaper.

The SOA architecture will also be able to accommodate our future needs and interests as a business. Take business activity monitoring (BAM), for example. That’s certainly something that’s on our agenda and some of the newer technologies we’re looking at right now have that kind of capability. Basically what we’ve done is build an architecture that will accommodate things like BAM – it’s a case of certain things are dropping into place. We need technologies to have reached a certain level of maturity and we also need to see a certain level of ‘pull’ from the business. But the good thing is we already know that we can get there.