Artifact: Goal-Service Model |
|
 |
This model brings together, in a single work product, the details of the mapping between services and associated business goals. |
Domains: Architecture |
|
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
Roles | Responsible:
| Modified By:
|
Tasks | Input To:
| Output From:
|
Description
Main Description |
The Goal-Service Model relates business goals to candidate services and exposed services. This model is developed
iteratively. During Task: Identify and Associate Services to Business Goals, the model includes
all candidate services mapped to the business strategy in terms of business goals. During Service Specification's
litmus testing, service exposure decisions are made. The mapping of exposed services must be
checked and, if necessary, refined to ensure that the details are correct.
Create a single instance of the Goal-Service Model to 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 can be represented in a number of ways, described below. The representation itself is
far less important than the fact that the information represented 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 having | Without this artifact, 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 needing | Where services are developed purely to provide infrastructure capabilities it might be possible to dispense with this
model, as there are no business strategy items being supported by such services. |
Representation Options |
UML Representations:
-
A Model, stereotyped <<Goal Service Model>>, containing the set of Business Goals and either Candidate Services or Service Interfaces and their dependencies that constitute the goal service
model.
-
Content within a separate Candidate Services model that reflects the Business Goals and the Capabilities (Candidate Services) that are traced to them.
-
Content within a Service Model that reflects the Business Goals and the Capabilities that are
traced to them.
Requirements Representation:
-
As a goal can be considered to be a requirement for IT Capabilities to support, it is therefore possible to
capture the business strategy in a requirements tool.
-
In such a case, trace the set of Services, whether candidate or exposed, to these business goals using
mechanisms defined by the requirements tool.
Tabular Representation:
-
The relationship between goals and services can easily be represented in a simple document or spreadsheet
form, using a format such as the following. Goal 2 illustrates an important point: a non-leaf goal --
that is, a goal that is not an end-goal -- does not necessarily have to be traced to a service if all of its
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
Licensed Materials - Property of IBM
© Copyright IBM Corp. 1987, 2012. All Rights Reserved.
|
|