Capability Profile Structure

Because a service acts as a container for a collection of capabilities, additional “sub-profiles” need to be established to represent each individual capability separately, as follows:

• Capability Name
• Purpose Description – A concise explanation of the capability’s overall purpose and functional context (similar to the short service description).
• Logic Description – A step-by-step description of the logic carried out by the capability. This can be supplemented with algorithms, workflow diagrams, or even entire business process definitions, depending on what stage the capability definition is at.
• Input/Output – These two fields provide definitions of a capability’s allowable input and/or output value(s) and associated constraints. It can be helpful to describe these in plain English during the service modeling phase. The details established here can make reference to existing schema types.
• Composition Role – The execution of capability logic can place a service into various temporary runtime roles, depending on its position within service composition configurations. This field can filled out with a description of the capability’s role or it can simply contain a term used to identify predefined runtime roles.
• Composition Member Capabilities – A list of services (and specifically their capabilities) composed by the capability logic. This provides a convenient cross-reference to other service capabilities the current capability has formed dependencies on. Ideally, identified composition member capabilities are mapped to the portions of the business process logic (documented in the Logic Description field) so that delegated logic is clearly indicated.
• Keywords – Often the same keywords that apply to the service can be carried over to the capability. But it is not uncommon for additional keywords to be added to individual capabilities so as to better classify their purpose. Keywords for services and capabilities should originate from the same parent vocabulary.
• Version – Depending on the versioning system in place, capabilities themselves may be versioned with a number or new capability versions may be added with the version number appended to the capability name.
• Status – The same lifecycle identifiers used for services can be applied to the status of individual capabilities. However, this field can also be used to earmark capabilities that were identified during the modeling stage, but for which no specific delivery date exists.
• Custodian – More often than not, the custodian of the service will be the custodian (or one of the custodians) of the related capabilities. However, when multiple business and technology experts collaborate on a given service, some are only there to assist with the definition of one service capability (or a subset of service capabilities). In this case separate custodians may need to be associated with individual capabilities.