Excerpts from that conversation follow:

What are some of the major lessons your company has learned over the past seven years about developing an SOA, and what would you do differently if you began your work today? You absolutely need executive sponsorship. One thing we did right was as soon as we proved the concept on our first pilot, it was understood we were approaching SOA as a systematic implementation. I don't see how it can be successful or valuable if you don't do that. Otherwise, you are in constant struggle with development managers about who will do development. We didn't define an [ROI] metric up-front, so in our early progress we really had nothing tangible, [and] some business leaders really like to have a number. We had more IT-ish things that showed value, but we couldn't quantify them in raw dollars. You definitely need to establish a reference architecture that will grow with your changing implementations.

The organizational and cultural [changes] are huge. We could have done better with that. We learned pretty quickly that we need to communicate often and thoroughly. We could have done more of that and articulated better some of the more intangible rules.

Today, we would have established very early on a good services repository in the middle tier. It ended up being almost that the architects were the repository with word of mouth. In the long run, that isn't the best way.

While many companies may be working on an SOA today, not many have gotten to the point of complex event-based processing or managing by exceptions. How have you gotten this far, and was this event-based architecture part of your vision from the beginning? It certainly was part of the vision. We knew we wanted to do that level of complex event correlation and automation of business.