Artifact: Goal-Service Model
This model brings together, in a single work product, the details of the goal-service model.
Domains: Analysis and Design
Work Product Kinds: Model
Purpose
The goal service model is used to ensure direct relationships between the business goals, as an articulation of the business strategy, and the services which represent the IT capabilities provided to the business to meet the stated goals. This model is therefore a capture of the traceability between Business Strategy and IT Capabilities.
Relationships
Description
Main Description

This model is developed iteratively, firstly during Task: Identify and Associate Services to Goals the model includes all candidate services mapped to the business strategy in terms of business goals. During Task: Apply Services Litmus Tests service exposure decisions are taken and so the mapping of exposed services must be checked and if necessary refined to ensure that the details are correct. An instance of the Goal-Service model should address all business domains that are within the scope of the project.  It is preferable to create a single Goal-Service Model instance for the project, rather than one per domain. 

This work product may be represented in a number of ways, described below, the manner of its representation is far less important than the fact that its information has to be kept up-to-date as the details of the service model change. Therefore it is common for this model to be represented in a form that facilitates rapid review and change.

Key Considerations
The Goal Service Model is required to ensure traceability between the Business Strategy and IT Capabilities; it supports accountability in the relationship between the business and IT and as such must be kept up to date.
Tailoring
Impact of not havingWithout this artifact, in one of its forms, there is no traceability and therefore no accountability between the business expression of strategy and need and the IT systems developed to support the business.
Reasons for not needingWhere services are developed purely to provide infrastructure capabilities it may be possible to dispense with this model as there are no business strategy items being supported by such services.
Representation Options

UML Representation:

Requirements Representation:

Tabular Representation:

  • In a simple document or spreadsheet form the relationship between goals and services may easily be represented, using a format such as the following (note that a non-leaf goal, that is, not end-goal may not necessarily be traced to a service if all of it's sub-goals are traced):
Goal or sub-goal Supporting Services
1. <Goal> <Service-1>
1.1 <Sub-Goal> <Service-2>
1.2 <Sub-Goal> <Service-3>
2. <Goal>
2.1 <Sub-Goal> <Service-4>, <Service-5> 


More Information