| |
Thursday 1st May 2003
COMMENTARY - A FRAMEWORK FOR SOA
| A FRAMEWORK FOR SERVICE GOVERNANCE
Of course justification is merely the starting point. The hard work commences with actual implementation. Here we introduce the term governance - the matter of achieving sufficient control over the implementation process such that relevant policies and practices are implemented and the overall ambition is realized.
We recommend that in parallel with the development of the Business Service Bus, an organization should develop a SOA Framework, a structured overlay to the current set of deliverables that makes plain the obligations on implementing projects to the SOA.
In the SOA Framework we analyze the deliverables comprising the requirements, specification and implementation layers, (could easily be conceptual, logical and physical a la Zachmann) and identify:
1. Key decision areas and
2. The medium in which architectural decisions are communicated, for example patterns, templates, common components, common services, protocols etc.
The implementation of an SOA is a critical requirement if cross organization synergy is to be achieved. Relatively few companies have implemented common or shared component strategies, whereas we should expect all significant enterprises, and ISV's to implement
comprehensive service oriented architectures. In contrast to components, the service is clearly understood by the business user and there is likely to be real opportunity in all organizations to establish common sets of technical and business services, that create consistency of rules, information, usage, whilst at the same time increasing the
organization's flexibility and ability to implement rapid change.
We welcome comments and feedback on the draft CBDI SOA implementation framework. This is available to Bronze, Silver and Gold members. If you are not currently a member, you can register instantly as a Bronze member for free.
SOA FRAMEWORK | ABSTRACT: We provide a framework for planning SOA implementation, with candidate deliverables for architects, and invite feedback.
Now that everyone is getting to grips with what SOA is, it's relevant to consider how to implement SOA.
Typically many organizations will come to Web Services through technical level experimentation and then deployment as a better form of application integration. Once basic competency is achieved, it's recognized that the next stage ROI will come through exposing primarily existing application functionality on a service basis.
At this stage, the notion of the Web becomes merely a description of today's chosen transport, and important characteristics of the service are those that allow it to be used with zero additional involvement of the provider (including designer, builder as well as host).
We recommend that the management of services needs to reflect the fundamental characteristic of the service - that it HIDES the implementation in its entirety. Simple to say, less easy to achieve. An important first step is to have a structured approach to managing sets of services in a business service bus.
THE BUSINESS SERVICE BUS
The Business Services Bus concept, first coined by CBDI is a way to tie together services into logical sets that reflect the structure of the business and are designed for wide-spread use across the enterprise. The Human Resources Bus would for example contain the set of services that underpin HR applications for the enterprise. The logical grouping and design of each bus ensures that there is minimal duplication plus uniformity in naming, ordering, and types of parameters.
The Business Services Bus concept extends the Domain Model of the organization by identifying the functionality required by the various departments in an organization and expressing that functionality in a collection of related IT services. This approach is key to delivering the full benefit of SOA. Simply exposing some methods in your code as a Web Service creates only limited benefits to the organization and can create maintenance problems if done badly.
The well-designed service bus acts as a façade for the implementation software that lies behind. Early attempts at delivering Web Services simply expose software functions that already exist in current applications. This will often result in services that are not consistent nor of the right level of granularity. Whereas a service façade can be used to aggregate and normalize existing functionality into an SOA.
It is our experience that in order to realize the benefits of SOA, a business model should include a service model which accurately reflects the implementation of services in the code. The documentation and graphical representation of the service domain encourages re-use and ensures a logical consistency between services.
BUSINESS JUSTIFICATION OF SERVICE TECHNOLOGY
For the architect, probably the most difficult issue is how do you get your decisions implemented? If the Business Service Bus provides the top level view of the services as requirements right through to provision and replacement, what's needed is a new approach to ensuring that the critical service oriented characteristics are implemented where appropriate throughout the entire organization. It is the consistent implementation of the service view of the domain model that will potentially drive productivity and quality benefits right across the organization.
The difficulty here is that SOA doesn't impact everything, it requires a delta to be implemented against current practices, such that the architectural integrity is devolved. However the service perspective provides us with an interesting opportunity to map business issues directly onto technology.
1. There is full traceability between the service as a business capability and its technical implementation.
2. Web Service technologies will increasingly enable innovative and or improved service delivery methods that are an integral part of the business product. Ergo there is no mapping, the business and IT perspectives are one and the same. |
| | Read Full Article / Link to referenced materials |
|
Home