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.
 |
| 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.
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
0 comments:
Post a Comment