So, which is right for you?
Well as usual the answer is that there is no right answer; this is a sliding scale and how much of each technique you use will depend very much on the solution you are developing and the development processes you follow. I met with a customer a week or so ago who is very much struggling with this decision, and specifically feels that the current literature indicates that Within the RUP rather than using these top-down and bottom-up terms which instantly give the feeling of contradiction we simply identify a set of techniques that may be used for service identification. The following picture is taken from the RUP update for SOA and demonstrates these techniques quite simply. they have to pick one over the other.
In terms of the use-case and business process techniques, these are more top-down approaches whereas the remaining techniques are more focused on the analysis of existing assets. So, let's take a look at the advantages and disadvantages of the top-down vs. bottom-up approaches in general.
- Top-down - Has the advantage that the services identified throughout the layers of the solution are aligned with the business processes which provided the scope for the solution. It is also attractive from a project management perspective in that the business process under consideration provides a natural project scope for the development effort. However, the major drawback to this approach (and the reason the customer I mentioned earlier got unstuck) is that it becomes harder to ensure that you develop services for reuse (some thoughts on SOA and Reuse) as developers are looking to develop services that support this process rather than ones that will contribute to an enterprise-wide service portfolio.
- Bottom-up - A bottom-up approach has the potential to develop a set service that can support a number of processes, addressing the concern above, as the developers are looking across a broad set of artifacts. The issues here are that where data is the focus of the artifact analysis the tendency is to generate CRUD services (which is bad) or to develop access operations that do not match well the requirements of processes and therefore require business services to make multiple calls into data-management services.
The best advise right now seems to be that you should lead with a top-down approach, that development teams and projects should be managed in such a way, but, in parallel you should have an SOA architecture team that can review service specifications, propose existing services for reuse and validate new services to ensure they fit into the enterprise service portfolio. This really frees project teams from having to understand all the existing portfolio, and allows the architecture team to also capture reuse guidelines and to act as intermediaries between different project teams. This does not imply that there is no bottom-up identification, but that it happens within the scope of a project which is top-down.
P.S. Beware any development process that dictates such a rigid set of techniques and an equally rigid step-by-step approach - for there you will find a process that has either only been used on a single project or never been used at all.