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.

What would you say are the key aspects of the architecture review board?

The architecture review board is responsible for helping, at least at the initial stages of a project, with the service architecture. Things like, "So what should the macro services be? And how do they relate to things that already exist?" The architecture review board also maintains the business enterprise architecture, which is never static. And they are available as internal consultants for projects to help make decisions that are architectural in nature.

It's important to mention that the architecture review board is not just a technology organization; we've created it as a subcommittee to our product steering committee so it will be more business focused.

Explain how that works.

The product steering committee is comprised of all the product owners across the business and is responsible for approving all new business product-related projects. We attached the architecture review board as a subcommittee so that it would not become a technology group for technology's sake, but a technology group that's responsible for supporting business projects.

It's one of the lessons I've learned having done SOA three or four times in different organizations. The last time I did an architecture review board we did it as a technology group and it didn't work nearly as well.

Sounds great in theory. How does it work in practice?

They may call the architecture review board when they are in the initial phases of thinking about a new product. Or they could already have the product in mind and want to know how to deliver it. And that's where the architecture review board will come in.