At the heart of the service concept is conformance with the principle of the "contract based" capability. Whilst many SOA principles will be optional depending upon context, the use of service contracts is likely to be required, because a well formed service is likely to be the primary enabler of the agile business. At the same time it is important to use a pragmatic level of specification detail that is appropriate to the context of use. Our practice research to date has focused on the Rich Service Specification and the Service Level Agreement. In this report we extend that guidance to cover evolution of specification artifacts across the full service life cycle, in an integrated way, to include all the involved parties.
The SOA architectural style is fundamentally about separation; establishing smaller, separate units of capability that create a more agile application and infrastructure environment. Most of the core SOA principles such as loose coupling, abstraction, virtualization etc depend upon the existence of a contract.
The concept of service contract appears in various guises at different points in both the software process and the service lifecycle. Contractual mechanisms are needed to:
- specify the service that will be provided to the consumer regardless of how the service is implemented
- specify constraints on how the service is to be implemented
- specify the commercial terms and associated logistics that govern the way in which the service is provided and used.
In simplest terms each of these three types of contract relate to the specification, implementation and deployment views of a service. But this is a little simplistic and we need to define in detail the relationships between these different types of contract to ensure a coordinated contractual position between provider and consumers..
In addition there are timing, level of detail, and role related considerations around the different types of contract.
Timing considerations center on when different specification types are appropriate in the software process and service lifecycle. Level of detail considerations have to do with achieving an appropriate degree of rigor and depth in the specifications that supports the relevant project phase activity. For each type of contract we require a progressive development approach that provides just enough information to support planning with a reasonable level of confidence and stability, and a continuous development process that involves multiple parties in reaching agreements as details of the design, deployment and usage are finalized. In fact it sounds more than a little like any contractual agreement process.
Consequently it's essential that participant involvement in the contract development process is clearly defined and communicated. A service contract, by definition, implies it is a contract between parties. But are parties always necessary and who are these parties exactly? We need to be very clear about the roles and responsibilities involved.
The need for guidance on service contracts surfaces in terms of questions such as:
- Does every service require a Service Specification?
- How much detail do I need – can this be graduated somehow so I don't have to jump in at the deep end so to speak?
- Can a Service Specification be broken down into more manageable chunks, each with a different audience?
- Does the idea of specification apply only to services – what about other types of software and how about assets in general?
- How does Service Specification relate (if at all) to the world of SLAs and ITIL?
- What about the implementation design of a service – if it's not documented in a Service Specification, then where?
Continued in PDF...
Document Download: Service Contracts in the Service Oriented Process (pdf)
In this report we extend our SOA guidance to cover evolution of specification artifacts across the full service life cycle, in an integrated way, to include all the involved parties.
File Size: 440KB
Published: 9 Sep 2010 00:00