Service-Level Profile Structure

There is no one official industry format for service profiles. However, once in use, the service profile format must be standardized as part of the SOA initiative. With an understanding of how services typically transition and evolve throughout stages, the following baseline parts and fields are recommended:

• Service Name
• Purpose Description (Short) – A concise, one sentence description of the service context and purpose.
• Purpose Description (Detailed) – A full explanation of the service context and its functional boundary with as many details as necessary.
• Service Model – Entity, Utility, Task, Orchestrated Task, or a custom variation.
• Capabilities – The profile should document capabilities that exist and are in development, as well as those that are only planned and tentatively defined. Color coding is often useful to make these distinctions as is the use of the capability “status” field (described shortly).
• Keywords – This field can contain one or more keywords ideally taken from an official service inventory-level taxonomy or vocabulary. Service profile keywords should correspond to the keywords used by a service registry.
• Version – The version number of the service currently being documented is noted here. Depending on the version control system in use, version numbers may only be applicable to service capabilities.
• Status – The development status of the service (or service version) is expressed in this field using standard terms identifying a project lifecycle stage, such as “analysis,” “contract design,” “development,” or “production.” If the service is not in production, it can be helpful to include an estimated delivery date.
• Custodian – Details on how to reach the official Service Custodian or owner, as well as others that contributed to this documentation.