That helped us distill some basic information assets-some basic information services, if you will-that would be relevant to hundreds and hundreds of applications. For example, things around investment data, end-of-day market data, single sign-on, core application libraries that every application would use, entitlements, and the like. And through this, again, instead of having 5,000 services, each with one consumer, we instantiated the service catalog with a smaller number-one the order of tens-that would be relevant to hundreds of applications. Then we again went to a communications program, to get people in tune with those, in touch with how to use them, and educated on how to get the most out of them. The early awareness training has been the easiest to get out there and make common.

On the infrastructure and communications, training is actually harder, because it's all sorts of skill sets there. And the detailed engineering training is probably the hardest. That's something we're working with third parties to shape, and we'll be rolling that out in the second half of this year.

CIO: Are you able to say what third parties you're working with?

Stepper: We started with the vendors we have, meaning IBM. But we found that the canned training only goes so far. We're trying to strike a balance between 'what are the service-oriented architecture skill sets we need' with 'How can we apply [these skills] at Deutsche Bank?' That means taking things like instrument data examples, application library examples, our particular implementation of enterprise service bus, etc., and make them as real as possible, so that when people need the training, they can actually do something as opposed to just going to the more generic . It's been tough to strike that balance, but we're certainly working on it.

CIO: You have, again, over 100 projects in play, and a couple of those are flagship products for the bank. So clearly you're building. What decisions have you made in terms of languages, interoperability, standards? For argument's sake, as I speak to organizations that are doing SOA, some have chosen to use SOAP, some are going with , some aren't using either. Some are using their own custom XML payloads. What's your approach to how these applications actually touch each other? How are they talking?