CIO: Why did adding that enterprise service bus and other technological pieces in place make it easier for you to embark upon these first 100 projects?

Stepper: Sometimes those first few steps are the hardest. Instead of spending an inordinate amount of time debating tools and techniques, we got past that within a relatively short amount of time with TIBCO and IBM.

When we're talking to applications, there's something for [developers] to actually use; something that works, something that's already production grade, something that's already set up as the utility. So the first 10 projects didn't have to go through the nightmare of on-boarding, and we don't have endless debates about what toolset to use. We had some of the best SOA engineers work that out early. So, instead of building it as they came, they anticipated the demand, built it out in a pretty quick timeframe, and it ended up being production grade. That was a great call. Now, when we approach applications, it's easier to onboard them, it's easier to get [developers] trained, it's ready to be workflow- or Web-service-enabled, and so on.

CIO: And about when did you do this? And how did you determine that it was, in fact, production grade, when there really wasn't a production-grade SOA in place to throw these things against, and do that kind of performance testing?

Stepper: I'd say the environment was in place at the end of last year. It wasn't ready for prime time, although there were one or two early adopters. It was in the first quarter of this year that Hermann [Lamberti] reiterated, from the top, how important this was. That pretty much aligned everyone to make sure that they were engaged in making this move to a service-oriented enterprise happen.

That was a watershed moment in many ways. It was no longer people waiting to see if it would work. We were no longer asking, 'Could we?' but were asking, 'Why wouldn't we?' Hermann's interest got everyone, both on the infrastructure side and on the app/dev side, to lay out what the demand would be over the course of a year. And it was easier than any other infrastructure project to get the right resources behind it, to flesh it out. So, the building out has been going on over the course of '08. We have a number of significant projects on it now. It's not perfect, but we've got the people lined up, and we're very confident in the platform that we have.

CIO: So you're affecting culture change by having a top-down push, putting core platform components in place first to eliminate debate, targeting shared infrastructure as your entry point, and then establishing SOA as a clear direction for the organization. But once that's done, what are the next steps? You now have over 100 service-oriented applications in various stage of development. How did you select them? How have you affected culture change among the application developers, specifically? What type of training has been required? What have you looked at in terms of getting everybody up to speed? I imagine the bank has myriad skill sets among the developers, and yet now everybody has to converge around this common approach.

Stepper: We did a number of things. At the end of the first quarter, we did something that's not too common for Deutsche Bank, which is, we created some cross-bank governance structures for our SOA program. Most people will hear the word 'governance' and tune out. But this was a group making sure that a group of people across the bank were able to pick up the early work of the infrastructure, and expend that to training and communications for the flagship project to the service development.

What we didn't want to do is just turn all the activity onto SOA and create spaghetti; to let 1,000 flowers bloom into something that, in the end, doesn't really add up to much. What the governance structures did was to build on the work we did on the infrastructure side, and advance it when it comes to things like naming standards. All of the engineering decisions that have to be made—which can make all the difference in how these things are used and operate. To extend that to communications, we had the same governance structure set up. We rolled these programs out to touch the development community in small groups. We made sure they were aware of what was going on, that we listened to the problems that were affecting them, and that we would determine what would make a difference for them.

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.