Nick Malik has a great post on this topic. Here is how he defines the terms:
- Top down - central group decides everything and the dev teams adopt them.
- Bottom up - central group provides a directory and dev teams make whatever services they want. Dev teams go to the directory to find services they can use.
Now, five years later, we do have a centralized architect group with the necessary authority to govern our SOA initiative. We will use a Top Down approach to ensure we don't relive the mistakes of our past. This works for us because we are a small shop (about 200 IT staffers). Development is done in three business units, two at corporate and one in Europe. Our approach is that the architect group controls our repository of objects and services. All teams can access the repository in read-only mode and submit candidates for consideration to be added to the library. If the artifacts meet our architectural standards then they will be added to the repository.
I believe Top Down SOA will work for us because of our size and because there is a limited amount of staff who have experience with SOA. If we were a large shop with several different groups actively working on SOA then this might be a major challenge. Bottom Up is a faster way to market but can lead to maintenance nightmares if any group thinks departmental instead of enterprise.
I would love to hear from those who have experience in either Top Down or Bottom Up SOA.