Of the six approaches to SOA, I briefly described the first one: top-down business driven. I am now thinking of how pilots are given various angles and approaches to airports based on traffic, wind, direction they are coming etc., which only shows that I need to get a life and travel less... but that's beside the point.
The others include: bottom-up legacy integration/enablement, data access driven, message or event driven , model-driven architecture (tools to generate web services) and legacy transformation.
Legacy Integration and Transformation are fundamentally bottom-up approaches: you start with something concrete and find a way to leverage it. Sorta like mathematical induction: from the particular to the general. Now back down to the ground of reality....
Customers want to expose functionality. In the first case functionality that is isolated and can be wrapped and mapped to a mid-tier application server. In the second case, the bottom-up approach is still related to legacy, but in this case the functionality requires some software archeology: it's embedded into the bowels of the legacy system. Now you need some form of compiler-based technologies (many of which evolved from the Y2K days) to extract re-usable portions of code that can be accessed from anywhere, not necessary through the mechanisms of the legacy system.
The two top down approaches are business driven and model-driven: the first one is based on bsuiness processes and the need to align and improve them. The second is based on tools and their ability to generate useful code from a top-down rendition of the business model or analysis model.
Some companies want to start with improving their businesses by focusing on the processes. Others may have more IT focus where they want to improve the business by improving the way IT does the job of supporting the existing processes.
Then we have two approaches that come in sideways: data access and message/event driven. Some people could care less about SOA or any other latest cool technology or promising paradigm; they just want to have a single uniform and consistent way to provide interface-based access to their underlying data: check the status of an order, place an order, access customer data, etc.
And others, coming in from the other sideways angle only care about integration; without knowing or caring about the two points of integration. In otherwords, I want to connect two systems they say and SOA gives me a very clean way to do so. I care only about messages exchanged between systems and the events that trigger the exchange of data or the invocation of a service.
BPM, APIs & Service-oriented Architecture: Insights and Best Practices
From archive: May 2005 X
Ali_Arsanjani 120000D8QB 819 Views
When hitching a ride in the journey to SOA, there are at least six approaches you can take. One is a top-down business driven approach where you or your client want to improve and support business processes with recomposable services that can be exposed within the organization across business lines or between partners in the Service Eco-System
The migration path to SOA will require a choice of the approach.
Ali_Arsanjani 120000D8QB 786 Views