In Part 2 I discussed how activities in a delivery process could be created from capability patterns that are comprised of tasks and/or activities. Capability patterns are reusable patterns which can be applied across a range of delivery processes. Capability patterns have input/output work products which together define the ‘contractual boundary’ to which performers of the capability pattern must conform. In this post I’ll take a look at what these work products are and how they form part of a contract between capability patterns.
The table below shows the set of work products that are used in the process I have been describing.
| Work Product | Description | Notation |
|---|---|---|
| Service Catalogue | Catalogue of all services owned or used by the enterprise. May be technical or business, legacy or new/to be provided. Usually implemented as a service registry. | WSDL |
| Service Certificate | Identifies a service that meets certain quality criteria. | Text |
| Service Portfolio Plan | Describes what services will be provided, when and by whom. | Text |
| Service Portfolio | Describes the entire collection of business services that an enterprise uses or plans to use. | Text |
| Service Model | Defines the complete hierarchy of business and technical services used or planned to be used by the enterprise. Can exist at a logical and physical level. Contains one or more Service Specifications. | UML |
| Service Specification | Defines a detailed specification for each service. Can exist at a logical and physical level. | Text/WSDL |
| Deployed Service | A service deployed in the service platform. | Jave, MQ etc |
| Deployed Service Environment | A deployed service platform. | N/A |
This diagram shows the relationships (finish to finish dependencies) between the above work products.
 |
| Work Product Dependency Diagram |
In this next diagram we can see how what I’m referring to as ‘contractual boundaries’ can be realised using these work products which are passed between two of the capability patterns I discussed last time.
 |
||
| Contractual Boundaries |
Activities produce one or more work products which are consumed by other activities, either in the same capability pattern, or in a different one. This means that provided the input and output work products are agreed the capability patterns can run in parallel or, if needed, at different times. So, one capability pattern, the ‘provide capability’ one in the above example can contribute to the Service Model work product which another capability pattern, the ‘manage service portfolio’ one can contribute to at a later time if need be. Having a common set of agreed work products, which are shared in a repository, becomes the key to having an effective delivery process.
Software Architecture Zen 
[…] first three of these blog posts (here, here and here) have looked at the process behind developing business processes and services that could be […]