Finally I found some time to finish this series. My apologies to those who've been waiting for part 3, but ..... here it is.
I have outlined two different approaches so far: bottom-up and top-down. As is usually the case, both have merits and drawbacks. In fact, the real solution is to do both, and not just one. That's what I call 'Meet in the Middle'. The top-down approach is very important to achieve the business goals, where the bottom-up approach is just as important to utilize the investments made in the current systems for the last few years. By combining these two approaches you get the best of both worlds: integration with the current application infrastructure (in a service-oriented way) and preparedness for more process driven functionality which supports the business needs.
But (of course there's a but) there's a little more to it. Matching the two approaches is not as easy as it sounds. There will be quite a gap between the business services as described in the top-down approach and the application services discovered in the application infrastructure. The trick is now, to take a business service and analyse which of the application services youi need to compose a service that will bridge the gap. This composite service can be multi-layered, and usually is.
One of the paradigms we use in grouping and discovering services is domain driven design (see Eric Evans marvellous work). Stated shortly: we define business domains (top-down here) consisting of delimited data and corresponding services (multi-level services: from data manipulation to business level services). This domain (and therefore its data) can only be accessed through the services. These are the building blocks for the future business functionality.
The attentive reader will have seen the problems looming on the horizon. The main issue is, that the domains we have recognized will be spread over the existing application infrastructure. So, how are you going to delimit the domains? That's the hardest part. In a greenfield it's easy, because you can define and build the domains. In real life situations you will usually build a part of the domain and integrate it with the existing applications. So you will need composite domain services which will present a unified view towards its consumers, and will integrate the different data sources on the back-end.
How hard this is, usually depends on the openness of the systems involved. Even though a lot of systems are walled of, there are usually several strategies you can employ. This goes from the use of service adapters, wrappers, up to direct database calls and file interfaces. You'd be surprised how far you can get.
