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

Roles	Responsible: Software Architect	Modified By: Designer Software Architect
Tasks	Input To: Apply Services Litmus Tests Identify and Associate Services to Goals	Output From: Apply Services Litmus Tests Identify and Associate Services to Goals

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 having

Without 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 needing

Where 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:

A Model, stereotyped <<Goal Service Model>> containing the set of Artifact: Business Goal and Artifact: Service Specification and their dependencies that constitute the goal service model.

Requirements Representation:

As an Artifact: Business Goal may be considered as a requirement for IT Capabilities to support, it is therefore possible to capture the business strategy in a requirements tools, as described in Tool Mentor: Identify Business Goals Using Rational RequisitePro.
In such a case the set of Artifact: Service Specification, whether candidate or exposed, may be traced to these business goals using mechanisms defined by the requirements tool.

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

Guidelines	Goal-Service Modeling
Tool Mentors	Creating a Goal-Service Model using RequisitePro