By following this SOA model, we're building a middle tier for network management that will then be reused for multiple purposes across the company. In addition, we are moving towards a complete Web services model for all of order management--not just provisioning.

So, piece by piece we're creating macro coarse-grained services that are implemented as a composite application made up of underlying services. Those services will be incorporated into other composite applications as part of our enterprise architecture.

So you're building the base-level components at this point.

It's the base business building blocks, correct. There are infrastructure components which underlie all these, some of which are already built or are in development. So in addition to the business components you've got technical infrastructure components, things like authentication and authorization and identity, but those are being created as part of all these other applications that we're building. We're building out the infrastructure layer to support those larger business components.

Let's talk generally about SOA since you're saying you have a lot of experience with it. Let's talk about some of the myths and realities. When would you say that you just don't even want to bother thinking about this kind of thing?

I would say that you really shouldn't be looking at revamping your architecture if you don't have a dynamic business with lots of change. Why spend the money to swap out any of your infrastructure if it's working for you? Not only is it a lot of energy to go through this exercise, it's also a relatively newer technology, so the skill sets are harder to come by and you're going to be competing for talent with organizations that are growing. The people who have these skills want to work in a growing environment because it's more fun. Companies that are static or in decline will have a harder time finding people.

Some people are challenging the idea that reuse is going to be a big benefit of SOA. Some estimates I've heard say reuse is only about 10 percent to 25 percent. And others are saying you may not want to make reuse part of your strategic goals for SOA-at least at first-because you may find a better way to design a service the second time around. What are your thoughts?

We're already seeing reuse here. The biggest challenge to reuse, in my experience, has been governance. The reason that it's a challenge is because by nature software engineers and architects have a "not-invented-here" syndrome. Every time there's a problem to solve, they believe that they have a better way of solving it. And that using someone else's code, or using someone else's service, is not going to be as good as if they reinvented it themselves because they have a unique way of dealing with the issues.