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 about some of the myths and realities. When is an SOA not really worth a CIO's time and effort?

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 say reuse is only about 10 percent to 25 percent. Others are asking why reuse should be a strategic goal when you may find a better way to design a service the second time around.

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.

So I think that a governance model is really important to fostering and encouraging reuse. Everyone I talk to about governance says: "Oh yeah, that's a really big problem in our organization." I would say we are working hard on it here, but I don't think that we've solved it either. We've already seen some benefits of having an architecture review board in place that reviews all our big projects and can suggest ways to reuse services.

Maybe one of the differences here is that we're growing so rapidly and there's so much work to do that people aren't worrying about whether they'd like to reinvent things because they don't have the time. If they can find something to get the project done quicker, they're reusing it. For example, the billing services we've created have already been reused four times. That's partly because we set up an architecture review board that lets people know that there are services out there that can be reused.