Information Age (IA): DHL’s parent company, Deutsche Post World Net (DPWN), owes its growth largely to acquisitions, many of which have been made in recent years. What kind of technical challenges has this created for DHL IT Services?

James Harvey (JH): The challenges we face are meeting the needs of the business within the time and at the cost it needs them. The pace of business growth and change is a considerable challenge.

When you acquire a company you take on a lot of IT and by and large that IT doesn’t interconnect or inter-communicate [with existing systems]. As a service organisation within DPWN, our main job is to make those interconnects. The faster we can do that, the better we can do that and, quite frankly, the cheaper we can do that, the easier it becomes for DPWN to acquire companies. And if we take too long to do that integration, it slows the organisation down and, in effect, it becomes a barrier to acquisition and to growth. So our big challenge is: how do we integrate [other acquired companies IT] within the business’s timeframe and cost requirements?

IA: What role does a service-oriented architecture (SOA) have to play in helping you resolve these issues?

JH: We exploit SOA as a means of integrating acquisitions relatively quickly. At the same time it allows us to improve the time to market of new applications – another key challenge we face.

But that services-oriented architecture sits alongside two other architectures: batch-based, and message-based.

With batch, we typically build up lots of transactions which at the end of the month go towards creating customer invoices, sent to customers as a batch process to their backend ledgers. This is a legacy system, but we had the option of breaking it apart and re-orienting around SOA. That is to say, every day when we have a transaction we could send the results down the message bus to the relevant application and hook it into the [customer’s] ledger. In that circumstance, you wouldn’t need a batch base as it would be done progressively. However, the batch system as it stands works and has been working for 15 years, so why should we change it unless there is a compelling reason to change it?

That said, we have integrated it into the service-oriented approach in order that we, at least, have the applications visible to the rest of the enterprise.

Similarly, the message-based architecture grew up from DHL’s legacy where we had systems in different countries and each one effectively inter-operated with others as if in a customer relationship.

We built up extensive point-to-point links with the proprietary messaging architecture. An SOA is no more than a message-based system in many ways, so you could say, ‘why don’t we take that message architecture, break it up, and re-implement it around the service bus?’

We could do that but it would be a drain of our investment dollars when we would rather use that to develop new functionality and new products. So we embody the functionality so that its integrity is protected, we plug it into the service bus so the functionality is available and visible, but still preserve it essentially as a message-based architecture.

That enables us to integrate an acquired company’s IT by plugging their legacy systems into this SOA. More importantly, we can build new functionality that is able to exploit existing legacy systems, because they’re visible to those new pieces of functionality.

IA: So have you found that SOA really does succeed in providing the much talked of benefits, such as business agility and responsiveness?

JH: I guess I would have to say no. Various parts of the organisation have been involved in SOA for almost 10 years and probably only in the past year could I genuinely argue that it’s been viable from any important aspects – that is the standards have been sufficiently defined and mature enough that you can go to most suppliers and be confident that if you choose their products and you didn’t like it after a year and moved to another supplier that you wouldn’t be locked in.

That’s a big caveat because most implementations of standards have proprietary extensions and enhancements which, by definition, take you away from the standards. Of course, part of what a vendor does is to seduce you into going to those extensions. But I think it’s fair to say that, if you have stuck to the core standards, it is only in the past year that you could have implemented SOA and had some reasonable degree of confidence that you could switch suppliers.

The trick is always in knowing which vendors you should trust, which extensions you should use, and to understand the risks you are taking by doing so. That’s where a lot of the skill is in doing SOA because it’s in the vendor’s interests to exploit the technology by [encouraging you to take on extensions]. To answer your question, SOA is somewhat over-hyped, somewhat under-delivering on its promises, and a lot harder than it looks.

IA: Where do the difficulties lie in practising SOA?

JH: Part of the difficulty is deciding which parts of your applications you should expose, how you identify what the services should be, how the business collaborates with IT. Even to the point where you’ve built up a certain portfolio of services, how much time do you invest in reviewing whether those services are the ones you should be reusing rather than building new ones?

There’s almost a [tipping] point between the time it took to find a services that can be reused versus the time it would take to build one [from scratch]. That’s why for us the advantage [of SOA] is not to eliminate duplicate functionality, it’s really to integrate, to be flexible, to get to market quickly, and to help with acquisitions. That’s really the key.