Introduction to
Service-Orientation
|
|
Service-Orientation
Design Principles
|
|
|
Effects of Service-Orientation on the Enterprise
|
|
Service-Orientation
in the Real World
|
|
|
|
Service-Orientation in the Real World
|
Additional Considerations
To supplement the benefits and challenges just covered, this page discusses some further aspects of service-orientation.
It Is Not a Revolutionary Paradigm
Service-orientation is not a brand new paradigm that aims to replace all that preceded it. As previously established on the Origins and Influences of Service-Orientation page it incorporates and builds upon proven and successful elements from past paradigms and combines these with design approaches shaped to leverage recent technology innovations.
This is why we do not refer to SOA as a revolutionary model in the history of IT. It is simply the next stage in an evolutionary cycle that began with the application of modularity on a small scale (by organizing simple programming routines into shared modules for example) and has now spread to the potential modularization of the enterprise.
Enterprise-wide Standardization Is not Required
There is a common misperception that unless design standardization is achieved globally throughout the entire enterprise, SOA will not succeed. Although design standardization is a critical success factor for SOA projects that is ideally achieved across an enterprise, it only needs to be realized to a meaningful extent for service-orientation to result in strategic benefit.
For example, service-orientation emphasizes the need for standardizing service data models to avoid unnecessary data transformation and other problematic issues that can compromise interoperability. The extent to which data model standardization is achieved determines the extent to which these problems will be avoided.
The goal is not always to eliminate problems entirely because that can be an unrealistic objective, especially in larger enterprises. Therefore, the objective is sometimes to just minimize problems by taking special considerations into account during service design.
In support of this approach, design patterns exist for organizing the division of an enterprise into more manageable domains. Data standardization is generally more easily attained within each domain, and transformation is then only required when exchanging data across these domains. Even though this does not achieve a global data model, it still establishes a very meaningful level of design standardization.
|
|
