SOA Approaches- Top down vs Bottom up

Post date: Mar 31, 2013 1:55:15 PM

What should be the approach of taking a SOA implementation? Top down or Bottom up. Should be start from scratch which some book worm believe is true or in practice there is any answer to this question - "What should I do of my existing assets? Should throw away them and start a new SOA project from scratch? These are the questions I will try to answer from an architects view point (obviously not from a vendor view point)...

There are two approaches to execute SOA top down and bottom up.

Top down

Also known as green field. This approach is best suited when you are going to implement a new system. Following are some of the activities or steps involved-

    • Identify broad business domains and their relationship

    • Identify business process running or required to run the system. Also identify where they with with others (processes, roles etc)

    • Identify high level services required to run these processes based on process activities

    • Analyze as is system for identify processes implemented to map them with desired system and processes required to know gap.

    • Make a strategy to fill the gaps by enabling missing processes in new system.

    • Other steps are as usual steps of SOA life cycle and project life cycle which I am not covering here in detail.

Benefits of this approach

Helps in scope definition.

Capturing of business rules at a high level.

Better understand the business context

Dependencies can be identified earlier at higher level

Interactions between various actors.

Complexity within the enterprise in terms of message exchange patterns is known earlier.

This was business process driven flavor of top down approach. There is another variance of Top down approach - use case driven.

Bottom up

Generally this approach is taken for modernization of legacy systems or non SOA systems to SOA eco-system.

Following are some activities involved-

    • Analysis of applications at enterprise level

    • Build buy reuse analysis

    • Analysis for redundancy and re-factoring effort

    • Identification of coarse grained services and creating interfaces/facade on top of old functionality.

    • Enabling these facade as services.

This approach not necessarily require business process approach (identification of processes, modeling them and then using services to implement those processes).