Monday, October 22, 2012

Capability-Based SOA

Two of the most complex problems facing all SOA implementation projects tend to be:
  • The determination of what to do with existing capabilities.
  • The determination of how to define the specific nature of new or transformed capabilities.
Existing capabilities are usually systems but of course can include services or other code that could be readily included within some type of SOA development effort. We tend to refer to this as legacy capability, but the term legacy often has a negative connotation. Perhaps "realized" capabilities better describes the situation in that it reflects that these elements were at some point already successfully deployed and adopted.

The up front portion of most SOA engagements tends to be the most critical part...
 Deciding upon the nature of the new capabilities is also extremely important. If one approaches the situation with the assumption that the development of standards-based services code will magically allow for a plug & play enterprise they are likely to be fairly disappointed. Building service applications does not represent a solutions architecture - with the advent of SOA we must now be more cognizant than ever before of the various inter-dependencies and relationships between infrastructure, application logic and data architecture. This then implies that we need to consider and plan how all of these will fit together or else will leave our fate in the hands of unforgiving chaos.

The fact that all of this involves SOA doesn't change the fact that one must apply a number of basic system engineering techniques and principles to help manage these issues. The diagram below illustrates one possible approach; it breaks the process into three parts:

Part 1 - Capability Taxonomy
Understanding our domain starts here - this ensures that everyone is on the same page from day one, skipping this step (especially in a large enterprise) will place most transformations at risk from the get go.

Part 2 - Capability Granularization
First of all, you need to decide what this is going to look like - are you going to manage like services within some sort of module framework (i.e. statically determined compositions), or are you going to make more discrete services available - ones that can be combined by the users at run-time or added to pages / portals. Or perhaps there will be a mixed approach - whatever that approach is though there will need to be rules guiding how certain capabilities are going to be developed.

Part 3 - Capabilities to Systems Allocation
Then, systems analysis needs to occur to determine if existing capabilities (within systems etc.) can be parsed or transformed into the various new forms defined in the previous step. Only then will the eventual reuse and migration paths become clear.

Copyright 2012, Semantech Inc. All rights Reserved 


Post a Comment