Service Discovery, part 2: Top-down

Time for part II. In Part I I explained that the Bottom-up approach is valid in itself, but it is does have its limitations.

A logical alternative is the Top-down approach. In short: this approach looks at the processes in the business, decomposes them into subproces/tasks/functions until 'logical units of work' are defined, which we call services.

Is that all there is to it? In principle: yes. However, there's more to it than meets the eye. A pure BPM (Business Process Management) approach, for example as advocated by IDS Scheer, will deliver a 4-layered process structure for the entire organization. Since the introduction of the Oracle BPA Suite you are then able to convert the lowest level of process to an executable process (BPEL) in which individual tasks become service-operations.

The decomposition of the process in itself is not enough to discover services, because you will have to convert the 'candidate-service' into a real-world executable and discoverable service. This means you will have to compare the functionality of the service with the available infrastructure (which consists of more services, hopefully). Quite often, the service functionality is delimited by specific functionality not being available. For example, suppose you run a very specific proprietary financial system where you cannot interact with either the business logic or the data store. If this is the ultimate source that you will have to use, the chance of being able to fulfill the service functionality needs are quite slim.

Does this invalidate this approach? Of course not. I find this approach working very well in those areas where SOA is used to add new functionality to an existing infrastructure or in a complete greenfield situation (which are quite rare). What this approach does for you is that it's easy to involve the business into designing the new services. The defined services are very recognizable for the business, but not always easy to implement.

Using tools to convert services that are discovered during the process analysis, means that the process analysis has to be done very thoroughly. And, even more important, the process analyst should have knowledge of the limitations of the execution platform. Otherwise you'll end up with services and orchestrations that work rightly on paper, but will never execute in reality. How to address that will be explained in part III.