it4it service model - the open group

IT4IT™ Service Model

Definitions, Details, and Example

A Guide by:

Sue Desiderio, JNS Solutions, Inc.

With significant contributions by:

Mark Bodman, Sukumar Daniel, Keith Jahn, Stephanie Ramsay,

Lars Rossen, Jan Stobbe, Christian Verstraete

<Month> 2019


www.opengroup.org A Wh i t e P a p e r P ubl i s h e d b y Th e O p e n Gr o up 2

Copyright © 2018, The Open Group The Open Group hereby authorizes you to use this document for any purpose, PROVIDED THAT any copy of this document, or any

part thereof, which you make shall retain all copyright and other proprietary notices contained herein.

This document may contain other proprietary notices and copyright information.

Nothing contained herein shall be construed as conferring by implication, estoppel, or otherwise any license or right under any patent

or trademark of The Open Group or any third party. Except as expressly provided above, nothing contained herein shall be construed

as conferring any license or right under any copyright of The Open Group.

Note that any product, process, or technology in this document may be the subject of other intellectual property rights reserved by The

Open Group, and may not be licensed hereunder.

This document is provided "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING,

BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR

PURPOSE, OR NON-INFRINGEMENT. Some jurisdictions do not allow the exclusion of implied warranties, so the above exclusion

may not apply to you.

Any publication of The Open Group may include technical inaccuracies or typographical errors. Changes may be periodically made to

these publications; these changes will be incorporated in new editions of these publications. The Open Group may make

improvements and/or changes in the products and/or the programs described in these publications at any time without notice.

In the event of any discrepancy between text in this document and the official IT4IT Reference Architecture Standard documentation,

the IT4IT documentation remains the authoritative version for certification, testing by examination, and other purposes. The official

IT4IT Reference Architecture Standard documentation can be obtained online at www.opengroup.org/it4it.

Should any viewer of this document respond with information including feedback data, such as questions, comments, suggestions, or

the like regarding the content of this document, such information shall be deemed to be non-confidential and The Open Group shall

have no obligation of any kind with respect to such information and shall be free to reproduce, use, disclose, and distribute the

information to others without limitation. Further, The Open Group shall be free to use any ideas, concepts, know-how, or techniques

contained in such information for any purpose whatsoever including but not limited to developing, manufacturing, and marketing

products incorporating such information.

If you did not obtain this copy through The Open Group, it may not be the latest version. For your convenience, the latest version of

this publication may be downloaded at www.opengroup.org/library.

ArchiMate®, DirecNet®, Making Standards Work®, OpenPegasus®, Platform 3.0®, The Open Group®, TOGAF®, UNIX®,

UNIXWARE®, and the Open Brand X® logo are registered trademarks and Boundaryless Information Flow™, Build with Integrity

Buy with Confidence™, Dependability Through Assuredness™, Digital Practitioner Body of Knowledge™, DPBoK™, EMMM™,

FACE™, the FACE™ logo, IT4IT™, the IT4IT™ logo, O-DEF™, O-PAS™, Open FAIR™, Open O™ logo, Open Platform 3.0™,

Open Process Automation™, Open Trusted Technology Provider™, SOSA™, and The Open Group Certification logo (Open O and

check™) are trademarks of The Open Group. All other brands, company, and product names are used for identification purposes only

and may be trademarks that are the sole property of their respective owners.


Document No.: TBA

Published by The Open Group, <Month> 2019.

Any comments relating to the material contained in this document may be submitted to:

The Open Group, Apex Plaza, Forbury Road, Reading, Berkshire, RG1 1AX, United Kingdom

or by email to:

[email protected]

http://www.opengroup.org/library

mailto:[email protected]



Table of Contents

INTRODUCTION 4

DEFINITIONS 5

Service Roles 5 1. Consumer 5 2. Product Owner 5 3. Service Broker 5 4. Service Owner 5 5. Service Provider 5

Service Overview 5 1. Service 5 2. Service Interaction 6 3. Service System 7 4. Service Offer 7

Service Model 9 1. Service Backbone 11 2. Service Delivery Lifecycle Objects 11 3. Service Consumption Lifecycle Objects 12

IT4IT SERVICE MODEL 14

Service 14 1. Primary Data Objects 15 2. Secondary Data Objects 15 3. Example: Service 16

Service System 17 1. Primary Data Objects 17 2. Secondary Data Objects 19 3. Example: Service System 21

Service Offer 23 1. Primary Data Objects 24 2. Secondary Data Objects 25 3. Example: Service Offer 26

Service Interaction 28 4. Primary Data Objects 28 5. Secondary Data Objects 28 6. Example: Service Interaction 29



Boundaryless Information Flow

achieved through global interoperability

in a secure, reliable, and timely manner

Introduction

This guide supports the IT practitioner working to implement the IT4ITTM standard in their organization by

providing a deeper definition of the IT4IT Service Model and its components, providing details regarding the

key data objects (Service Backbone), and making it real with practical examples. The reader should refer to the

Service Model Management (SMM) Snapshot, with its proposed updates to the existing IT4IT™ Reference

Architecture Version 2.1, to understand how the Service Model supports all aspects of the IT4IT™ Standard.

The Service Model is the backbone of the IT4IT™ Reference Architecture (RA), a standard of The Open

Group, in the same way as the IT4IT™ Reference Architecture acts as the foundation for convergence of IT and

business. This paper leverages the definitions established in The Open Group White Paper: Defining “IT

Service” for the IT4IT™ Reference Architecture (see References), which was part of the published Body of

Knowledge released with IT4IT™ RA Version 2.1.



Definitions

Service Overview

1. Service

In simplest terms, a Service is the action of helping or doing work for someone. Historically, it

was meaningful to differentiate between IT Services (Services consumed by technical Consumers)

and business Services (Services consumed by the business or external customers). However, the

need to differentiate along these lines is no longer necessary or healthy, and in fact can lead to

confusion because the majority of what would have previously been called business Services

today rely on technology components (previously called IT Services).

In contrast to a Manual Service - which is a performance or act which does not require any

computing, technology, or digital components - a Digital Service is important to consider as you

architect your Service Delivery and is described below.

But first, it is important to note that at the time of publishing this Guide, the IT industry is

currently unsettled on the nomenclature of “Service” vs “Product.” Some organizations and

software vendors are staying with “Service” or “Digital Service”, while others are choosing

“Product” or “Digital Product” to promote digital product management practices’ growing

influence in organizations. For the purposes of this Guide, we are treating these terms as

interchangeable and each organization is free to choose their own nomenclature

a) Digital Service

Digital Service is a performance or an act that applies computing and information

management competencies or resources for the benefit of another party.

For example, self-service banking at an ATM machine would be a Service. The Service

Offer would be the account agreement with the bank offering the self-service banking.

The Service System would be the software managing the ATM machine, the ATM

machine itself, and the support system of the ATM machine. The Service Interaction

would be experienced by the customer whenever processing a transaction via the ATM

machine.

There are three aspects to a Service that need to be understood at a fundamental level:

• Service Interaction

• Service Offer

• Service System



Figure 1: Service Overview

See The Open Group White Paper: Defining “IT Service” for the IT4IT™ Reference

Architecture (see References) to understand the perspectives of the Service in more

detail.

2. Service Interaction

Service Interaction is an occurrence of the performance or act where the computing and

information competencies are applied. Each Service Interaction occurs at a specific time/place and

can be measured using industry standard key performance indicators (KPIs); for example, quality,

performance, cost, value.

Service Interactions can be grouped into three primary Service Provider/Consumer relationship

patterns:

• Human-to-Human – where the dominant engagement between Service Provider and

Consumer is humans, characterizing a Manual Service

Examples include Service Interactions that provide consulting or support outcomes. The

humans performing labor may rely on Digital Services to perform their work, creating a

subsequent Human-to-Machine interaction as part of the human-provided Service System.

• Machine-to-Machine – where the dominant Service Provider and Consumer are both

technology (machines)

Common interactions between platforms implement these Service Interactions. Examples

include web services, micro services, and APIs.

• Human-to-Machine – where the dominant Consumer is a human and the Service Provider is

technology (machine)

This is the most common form of Service Interaction that IT facilitates and usually appears in

catalogs. Service Interactions in this category are oriented around technology-enabled Services

that Consumers engage with. Examples include applications, like the one running on the ATM

Service InteractionThe occurrence of the act, performance, or transaction

The OutcomeThe “value”

Motivation, desired result,

expectation

Service SystemThe “actor”

Integrated resources: people,

technology, money, information,

competencies

Results in

Sets consumer expectations forSets provider expectations for

Service OfferThe “available capability”

Value proposition, catalog entry

Facilitates

Is an abstraction of

Service



in the example above, and chat-bots.

3. Service System

Service System is an integrated set of resources, applications, other Services, and supporting

capabilities all functioning as a single entity to fulfill the Service. From the Service Provider side,

the Service System underpins the Service Offering and explains how Service Interactions are

facilitated, be they manual, digital, or a combination of the two. Manual Services may not

formally express their Service System, but do capture dependencies on components required to

deliver an outcome.

The resources that contribute to the formation of the Service System come from multiple domains

including:

• Technology Resources: resources from compute, storage, network connectivity, application

software, middleware, and IT management domains, provided individually or collectively as

an integrated unit, can be part of a Service System

These are often viewed as “the” Service System. However, technology resources alone do not

represent a complete Service System.

• Information Resources: structured and unstructured data, represented by individual records

or collections of records, unstructured content like video, audio, or text are all resources that

can be part of a Service System

• Human Resources: skilled labor with competence in computing and information

management, as well as resources with expertise and competencies in finance, legal, and

administrative functions, contribute to the Service System

• Other Services: Services which are largely an aggregate of existing Services to create a new

Service System

HR on-boarding Services are an example where many existing Services from facilities,

payroll, and IT need to be coordinated to deliver a single personnel on-boarding experience.

• Other Resources: funding for creating and managing Services; facilities like data centers and

support call centers which house the human resources associated with the help-desk; policy,

and strategy are all examples of “other” resources in a Service System

4. Service Offer

Service Offer is a consumable form of a Service which advertises the ability to produce an

outcome, such as a change in the user experience. It is marketed by a Service Owner to potential

Consumers, defined by a Service Contract, and (most importantly) presented in Consumer-

oriented terms.

Service Offers are typically categorized as shown below:

• Professional Services: this category focuses on outcomes that are consultative in nature

where, through human interactions, an outcome can be achieved



Examples might include business analysis and Enterprise Architecture.

• Support Services: this category provides repair and restoration-related outcomes for line of

business and IT employees

Examples might include device repair, security operations, and IT monitoring/management.

• IT Infrastructure Services: this category focuses on outcomes that satisfy the needs of other

IT practitioners and are used in creating other Services (creating or managing Services)

Examples might include computing, storage, mobile connectivity, developer workbench, and

personal storage.

• Application Services: this category represents Services where application software is the

dominant entity of the Service System

Examples include CRM, employee expense management, supply chain planning, sales force

enablement of the automated teller machine Service referenced above. Complex IT systems

that have been branded as “Services” could be placed into this category. As a Service Offer,

the Service should be represented more generically: “HR support services” rather than

emphasizing the technology resources and/or brand name application tooling behind it.

• Information Services: this often overlooked category provides outcomes that facilitate the

production, consumption, and/or exchange of information or content

Examples might include newsfeeds, electronic data interchange, single sign on, and

video/audio content sharing.

• Productivity or Workplace Services: this category focuses on outcomes that aid in employee

productivity

Examples might include collaboration, email, PC lifecycle, printing, and managed mobility

services.

• Machine-to-Machine Services: this category focuses on outcomes for developers and

engineers in the Service creation process

They are predominantly software-based but not considered Application Services. Examples of

Service Offers in this category include web services and APIs which facilitate non-human

interactions between service Consumers and Service Providers.

• Internet of Things (IoT) Services: this category focuses on gathering information about the

product while it is in use by the customer and provides information back to the Service Owner

for improvement or creation of new Services

Examples would be gathering data representing usage of the Service from social media.



Service Roles

1. Consumer

The Consumer is the person or entity deriving value from the Service.

2. Service Broker

A service broker is an entity that manages the use, performance and delivery of any IT service and

negotiates relationships between IT service providers and consumers.

3. Service Owner

The Service Owner (or Product Owner) is responsible for creating the Service Offer and should

have insight into what technical capabilities/functions are available from the Service Provider. The

Service Owner in some cases can also be the Service Provider. The Service Owner creates the

Service Offer, understands the cost charged from the Service Provider for the Service System or

Service components, and then sets the price of the Service Offer. The Service Owner works with

the Service Provider to understand what Service Contracts can exist for the Service Offer and

incorporates that into the Offer details. Service Provider

The Service Provider works closely with the Service Owner to understand how the Service

ultimately will be consumed, but the Service Provider is ultimately responsible to deliver technical

capabilities/functions needed to fulfill the Service. The Service Provider works to understand the

strategic business needs and demand for the Service via the detailing out of the Digital Service and

Conceptual Design. The Service Provider then looks to solution the Service through internal,

external, or hybrid means when creating or enhancing a Service System to meet those needs. The

Service Provider delivers various capabilities or functionality through the Service Release which

delivers full or partial functionality of the Service. Once a Service Offer is requested, the Service

Provider establishes a plan for the Desired Service instantiation to specifically meet the Consumer

needs, and then delivers on that request via the Actual Service.

Service Model

The Service Model provides an architectural framework for the various data objects representing the

Service throughout its lifecycle. Traditionally we have described the state of the Service as being either

conceptual, logical, or physical. In some cases, we have called the physical model the realized model. In

the IT4IT standard, these three models have been what was used as the connection between the four IT4IT

value streams to help differentiate the state of the Service.

The conceptual representation of the Service is described in more detail within Level 2 of the IT4IT

Reference Architecture Service Model Management (SMM) Snapshot in the Change Requests (CRs)

proposed for the IT4IT Strategy to Portfolio (S2P) value stream. It is comprised of the primary data object,

Digital Service, and the secondary data object, Conceptual Design. The Digital Service is easily

recognizable to the business and includes the business definition, demand, and essential features of the



service while incorporating Enterprise Architecture and Policy considerations. It is important to understand

that business can be the business of IT, which extends the IT4IT Reference Architecture to any Services

provided to internal (technology or business) or external customers. Ultimately, there should be no

distinction between business Services and IT Services as the convergence of business and IT is what is

needed to transform to a digital enterprise. The Digital Service and related Conceptual Design are used as

the starting point for developing a Service and its associated Service System in the IT4IT Requirement to

Deploy (R2D) value stream.

The logical representation of the Service is described in more detail within the CRs proposed for the R2D

value stream. It is comprised of the primary data objects, Service System and Service Release, and the

secondary data objects, Logical Design and Release Package. It is the focal point for those responsible for

delivering the Service (i.e., Service Provider or Service Broker) and includes elements to build or provide

the Service to the ultimate Consumer. The Logical Design and Release Package are delivered to the IT4IT

Request to Fulfill (R2F) value stream which is responsible for instantiating the Service.

The physical representation of the Service is constructed in the R2F value stream and is realized in the

IT4IT Detect to Correct (D2C) value stream. It is comprised of the primary data objects, Desired Service

and Actual Service. The Desired Service is based on the Service Release and Release Package which is

then passed to the D2C value stream to become a realized or Actual Service. The D2C value stream ensures

the Actual Service continues to deliver the promised Service to the Consumer.

In addition to the three major abstractions related to the state of the Service, there is a fourth abstraction of

Service: consumable.

The consumable representation of the Service is described in more detail within the R2F and D2C value

streams. It is comprised of the primary data objects, Offer, Subscription, Chargeback Contract, Service

Contract, and the secondary data objects, Offer Catalog and Chargeback Record. It describes the Service in

meaningful ways to the ultimate Consumer including pricing, service scope, and contractual commitments

while also managing the existing consumption and usage of previously subscribed Services.

In the SMM Snapshot of the IT4IT standard, the Service Model focuses on a Digital Service which involves

technology in some way, its lifecycle, and its components. The Service Model depicts how the primary

(purple) data objects (Service Backbone) and secondary (gray) data objects (seen in the Level 2 diagrams of

the IT4IT Reference Architecture) are interrelated and dependent on one another, and how those data

objects and key attributes are managed throughout the lifecycle of a Service. The relationships should not

be viewed as sequential as there are feedback loops throughout the lifecycle which capture aspects of the

various data objects upstream so the lifecycle is truly continuous for the life of the Service.

ServiceService

System

Service

Release

Desired

ServiceActual

Service

Offer

Charge-

back

ContractService

Contract

Sub-

scription

Conceptual

DesignLogical

Design

Release

Package

Offer

Catalog

Charge-

back

Record

Figure 2: IT4IT Reference Architecture Service Model Data Objects



1. Service Backbone

The IT4IT Service Backbone represents the primary (purple) service model data objects critical to

managing the service throughout its lifecycle. The primary Service Model data objects in

aggregation represent the conceptual, logical, and physical aspects of the service which are

represented below as the Service and Service System lifecycle data objects. The primary Service

Model data objects which represent the consumable aspects of the Service are represented below

as the Service Offer lifecycle data objects. The aggregation of the Digital Service, the Service

System lifecycle data objects, and the Service Offer lifecycle data objects represents the service

backbone.

Build Package

Component

Problem

Component

Incident

Component

Offer Consumption Component

Service

Design

Component

Release

Composition

Component

Service

Monitoring

Component

Event

Component

Change

Control

Component

Usage

Component

Diagnostics &

Remediation

Component

Chargeback/Show

-back Component

Request

Rationalization

Component

Offer

Management

Component

Build

Component

Test

Component

Defect

Component

Source

Control

Component

Project

Component

Requirement

Component

Enterprise

Architecture

Component

Service

Portfolio

Component

Portfolio

Demand

Component

Proposal

Component

Policy

Component

Fulfillment

Execution

Component

Configuration

Management

Component

Digital

Service

Service

System

Service

Release

Desired

Service

Service Level

Component

Actual

Service

Strategy to

PortfolioRequirement to Deploy Request to Fulfill Detect to Correct

Offer

Charge-

back

Contract

Service

ContractSub-

scription

Service Backbone Data Objects

Figure 3: IT4ITTM Reference Architecture SMM Snapshot - Service Model Data Objects)

2. Service System Lifecycle Objects

Service System lifecycle objects are the data objects in the IT4IT Reference Architecture typically

owned by the Service Provider which together support the delivery of the Service. They include

the Service System, Service Release, Desired Service, and Actual Service. The Service System

lifecycle begins with the Service System. The lifecycle of the Service System and the Service

Offer do not need to be in sync. The Service System can change while not resulting in a change to

a Service Offer, and a Service Offer can be changed while the Service System remains unchanged.

The Service System and subsequent data objects in the Service System lifecycle create a backbone

for the Service Provider to define, design, and deliver a Service.



Build Package

Component

Problem

Component

Incident

Component


Service

Design

Component

Release

Composition

Component

Service

Monitoring

Component

Event

Component

Change

Control

Component

Usage

Component

Diagnostics &

Remediation

Component

Chargeback/Show

-back Component

Request

Rationalization

Component

Offer

Management

Component

Build

Component

Test

Component

Defect

Component

Source

Control

Component

Project

Component

Requirement

Component

Enterprise

Architecture

Component

Service

Portfolio

Component

Portfolio

Demand

Component

Proposal

Component

Policy

Component

Fulfillment

Execution

Component

Configuration

Management

Component

Service

System

Service

Release

Desired

Service

Service Level

Component

Actual

Service

Strategy to


Service Delivery Lifecycle Objects

Figure 4: IT4ITTM Reference Architecture SMM Snapshot - Service System Lifecycle Data Objects

3. Service Offer Lifecycle Objects

These are the data objects in the IT4IT Reference Architecture typically owned by the Service

Owner that allow the Service to be consumed. In some cases, the Service Owner could be a person

in a line of business, but it could also be a designated IT person. The Service Offer lifecycle data

objects include the Offer, Subscription, Chargeback Contract, and the Service Contract. The

Service Offer lifecycle begins with the Offer. The Offer and subsequent data objects in the Service

Offer lifecycle create a backbone for the Service Owner to provide, govern, and measure a service

focused on the consumption which may be a short-lived single transaction, or may be tracked on

an ongoing basis over a period of time.



Build Package

Component

Problem

Component

Incident

Component


Service

Design

Component

Release

Composition

Component

Service

Monitoring

Component

Event

Component

Change

Control

Component

Usage

Component

Diagnostics &

Remediation

Component

Chargeback/Show

-back Component

Request

Rationalization

Component

Offer

Management

Component

Build

Component

Test

Component

Defect

Component

Source

Control

Component

Project

Component

Requirement

Component

Enterprise

Architecture

Component

Service

Portfolio

Component

Portfolio

Demand

Component

Proposal

Component

Policy

Component

Fulfillment

Execution

Component

Configuration

Management

Component

Service Level

Component

Strategy to


Offer

Charge-

back

Contract

Service

ContractSub-

scription

Service Offer Lifecycle Objects

Figure 5: IT4ITTM Reference Architecture SMM Snapshot - Service Offer Lifecycle Data Objects



IT4IT Service Model

In this section, the Service Model definitions from the previous section will be mapped to the data objects

within the IT4IT Reference Architecture. An example scenario is embedded in each section to provide high-

level details of the key Service Backbone entities, but it will not be comprehensive with respect to all data

objects within the entire Service Model.

Problem

Component

Incident

Component


Service

Design

Component

Release

Composition

Component

Service

Monitoring

Component

Event

Component

Change

Control

Component

Usage

Component

Diagnostics &

Remediation

Component

Chargeback/Show

-back Component

Request

Rationalization

Component

Offer

Management

Component

Build

Component

Test

Component

Defect

Component

Source

Control

Component

Project

Component

Requirement

Component

Enterprise

Architecture

Component

Service

Portfolio

Component

Portfolio

Demand

Component

Proposal

Component

Policy

Component

Fulfillment

Execution

Component

Configuration

Management

Component

Enterprise

Archi-

tecture

PolicyRequire-

ment

Scope

Agree-

ment

IT

Initiative

Portfolio

Backlog

Item

Source

Digital

Service

Service

System

Test

Case

Defect

Service

Release

Build

Desired

Service

Usage

Record

Fulfill-

ment

Request

Request

Problem,

Known

Error

Incident

Event

Service

Monitor

Run

Book

RFC

Shopping

Cart

Service Level

Component

Actual

Service

Build Package

Component

Build

Package

Charge-

back

Record

Strategy to


Offer

Charge-

back

ContractService

Contract

Sub-

scription

Figure 6: IT4IT Reference Architecture Service Model Management Snapshot

Service

Services should evolve as the needs of the organization change over time. They should be easily

identifiable, consumable, and may be provided directly or indirectly by IT. IT must have a solid

understanding of the Service Model data objects and how they are used throughout the lifecycle of the

Service in order to manage them effectively.

Managing a Service in the IT4IT framework has its starting point in the S2P value stream. The Service

Portfolio component tracks every Digital Service an organization plans, develops, provides, and runs for

the business. This includes Digital Services that to most lines of business are “just” internal IT Services

such as an IT infrastructure Service. In this aspect, IT is treated as just another line of business that has

Digital Services that must be managed.



1. Primary Data Objects

a) Digital Service

Digital Service represents the friendly or common name of a Service which is well

understood and meaningful to the business. It is the level suitable for initial planning and

ongoing management by characterizing the Service as a product of technology to include

business value, investment history and outlook, performance, value earned, and return on

investment. It is abstracted away from all technical detail on how it is implemented, the

underpinning Service System, and described in terms that are well understood by those

accountable for the assignment of budget and resources to build and maintain the Service

over time. The business could be a business unit within the organization or could be IT

(business of IT).

The Digital Service is also used to aggregate all financial data related to the Service. The

Total Cost of Ownership (TCO) of the Service System(s) is included in the aggregated

data, along with any pricing information captured from the Offers (via Subscriptions) that

support show-back or charge-back processes. The TCO of the Service System would

include the cost of any direct resources such as dedicated infrastructure and the price paid

for any consumed Services. An example of a Service consumed by a Service System

might be an authentication Service offered by the security organization.

2. Secondary Data Objects

a) Conceptual Design

The Conceptual Design represents a set of Digital Service endpoints that support business

processes/capabilities and provides Service process and delivery visualization from the

Service Owner’s point of view. It also maintains traceability to the Service System(s) and

Offer(s).

Digital Service

Offer 1 Offer 2

Fulfilled by

Figure 7: Service Conceptual Design



3. Example: Service

The US VP of Finance solicits IT for assistance in creating a new Service, Expense

Management. A new Digital Service record is created for the Expense Management

Service within the Service Portfolio system. The VP provides the high-level

requirements for managing expenses which are recorded as Portfolio Backlog Items

associated to the Expense Management Service.

• Ability to allow a staff member to manage job-related expenses

• Ability to allow a staff member to receive reimbursement for any job-related

out-of-pocket expenses

• Ability to interface with the enterprise financial system

The Enterprise Architect reviews the Expense Management Service Portfolio Backlog

Items from the business, reviews relevant standards and Policies, and develops a

Conceptual Design to meet the needs of the finance organization. They know any new

system will need to use the standard Authentication Service. During this process, the

Enterprise Architect determines that the solution must be established in a way that other

countries within the firm could instantiate a local instance of the Service System. This is

a result of a global enablement policy.

The Enterprise Architect identifies two Offers to include in the Conceptual Design. One

Offer would be intended for Service Owners in other countries within the firm who wanted to

Offer an Expense Management Service. A second Offer would be intended for end users within the

firm who would need to manage their expenses. As part of analyzing the possible implementation,

it is determined that there are two alternative ways of delivering expense management: creating an

in-house solution or purchasing a Software as a Service (SaaS) system. These options are included

in the Conceptual Design until a final decision is made upon which the Conceptual Design will be

updated. It is also determined that the expense management systems in general will depend on two

other Services: Finance Service and Authentication Service. Tracking this in the Conceptual

Design allows high-level dependencies among Services to be understood when making plans in

the S2P value stream.

Enterprise

Architecture

Component

Service

Portfolio

Component

Portfolio

Demand

Component

Policy

Component

Enterprise

Archi-

tecture

Policy

Portfolio

Backlog

Item

Digital

Service

Strategy to

Portfolio

Conceptu

al Design



Expense Management Service

Fulfilled by Fulfilled by

Access to manage expenses

Host expense management

system

Fulfilled by

Depends on

Offer

Digital Service

Uses

Authentication Service

Finance Service

Figure 8: Digital Service: Expense Management

The VP seeks out funding approval for this new Service and commits resources to the

implementation effort. The VP of Finance will be considered the Service Owner of the Expense

Management Service.

Service System

The R2D value stream essentially provides the management of the development of a Service System that

delivers the Digital Services in accordance to the Conceptual Design as defined in the S2P value stream

planning activities.


a) Service System

The Service System represents an aggregation of resources from across multiple domains

which together result in the delivery of the Service to the Consumer. Resources could

include infrastructure, software, people, processes, and other Services consumed by the

Service System. The Service System consumes other Services via Subscriptions to those

Services throughout the Service System lifecycle. As the business of IT matures, IT

organizations will continue to package everything they deliver into Services (or Products)

which make it easier to identify how these various resources are providing value to the

business. There may be multiple Service Systems which exist and are used to facilitate a

specific interaction. In these cases, the Service Owner has a contextual choice on which

Service System to fulfill an Offer. The Service System is meaningful to the Service

Provider and the Service Owner but may or may not be known to the Consumer.

A Service System largely delivers technical capabilities. A single Service System may

provide multiple capabilities, and multiple Services Systems may provide the same

capability. These capabilities are packaged and managed as catalog items within the

Service Release of the Service System. The Service Owner can use catalog items from



one or many Service Systems when managing the lifecycle of the Offer, as the catalog

items are the means of understanding what technical capabilities the Service Owner can

make available to the Consumer.

A Service System may be composed of direct resources which are specifically allocated,

such as hardware or software component(s), services provided by others, or a

combination of the two. Whatever the situation, we call these components of the Service

System.

• Service System 1 is an example of a system which is purely an aggregation of

other Services.

• Service System 2 is a hybrid that has its own fully owned components and

Subscription to other Services. Note that in many existing IT implementations,

Service dependencies are not depicted in the design or implementation as

Subscriptions, but simply refer to the relevant Service System. The advantage of

showing dependencies on other Service Systems via Subscriptions allows for

complete traceability to compute Service-Level Agreements (SLAs), financials,

and provides manageable abstractions between dependent Services.

• Service System 3 below is an example where all components are directly

related, and no other services are used.

Service Subscription



Service Component

Digital Service 1 Fulfilled by



Fulfilled by

Service Component

Digital Service 3

Fulfilled by

Digital Service 2

Fulfilled by

Fulfilled byService

Component

Service Component

Figure 9: Service System Data Object

Financial data is captured and maintained at the Service System level, which is then

aggregated at the Digital Service level for the overall service. The TCO at the Service

System level would include any costs related to the resources within the Service System

and would include the price of any consumed Services. (An internally consumed Service

Offer is often set at a price equal to the cost of the Service System and components. As



costs change, the prices will change. If costs go down, the organization is typically

benefiting from the Service, whereas if costs rise, the organization may have to review

the value per cost of that Service.)

b) Service Release

The Service Release represents a planned release of an instance of the Service System. It

relates to a single Service System. It represents the packaging (Release Package) of the

Service source, technical blueprints, and other key artifacts required to fully support the

Service System version, such as requirements and test cases/scripts. It details technical

capabilities in support of the set of features (requirements) which are sufficient to

produce an outcome aligned to the value expectations of the Offer. The technical

capabilities are described as catalog items, and those catalog items include the technical

blueprints and details on how the capabilities would be delivered once requested via the

Offer by the Consumer.

c) Desired Service

The Desired Service is a specification of an instance of a Service System as required to

meet the fulfillment requirements detailed in the Consumer order (request) and supported

by a Release Package. The Release Package contains the catalog item which describes the

relevant parameters that determine how a Service will be deployed/fulfilled.

d) Actual Service

The Actual Service represents the realized deployment of the Service System. It includes

Configuration Items that represent the delivered (implemented) Service System(s) or

interactions. In some cases, this will be an instantiation of environments that run in a data

center. In other cases, it could be a physical resource drop-shipped to the Consumer (like

mobile phones or a PC). It should be kept in sync with the Desired Service while adding

specific implementation characteristics and details.


a) Logical Design

The Logical Design represents the design of the Service System which details the service

components (resources) and how those components relate to one another. It introduces

the “how” details; i.e., technology delivery methods (on-premise versus cloud) and the

technical interfaces necessary to deliver the Service functionality.

There may exist multiple Logical Designs for a single Service System based on changes

to what the Service System delivers over time. The Logical Design is used to identify

what is to be included in a release of the Service System.



b) Release Package

The Release Package includes the packaging of the Service source and other key artifacts

required to fully support the Service System version, such as requirements, test

cases/scripts, and the runbook. It contains technical blueprints for the capabilities or

functions delivered by the Service System which are exposed to the Service Owner via

one or more catalog items. Ultimately, the Release Package delivers features that are

sufficient to produce an outcome aligned to the value expectations of the Offer.

The catalog item contains a technical blueprint which represents a set of technical

capabilities and specific options available from a Service System which can be delivered

by the Service Provider. It provides the details necessary to instantiate the service or to

fulfill an Offer. It provides the planned design/configuration of the components of the

Service System. It contains the description and procedures to activate, deploy, and

operate a Service and its underlying components including applications, monitoring

profiles, and technology.

There may be multiple Release Packages for a given Service Release due to

considerations of environment (development, staging, or production), hosting (on-

premise or cloud), or location (US, UK, other) which would each be specified differently.

Figure10: Release Package Data Object

Release Package

Service System 3 V x.x

Service

Component

Service

Component

Service

Component

Fulfilled byFulfilled by

Source Code

Build Package

Requirements

Test Cases/Scripts

Runbook

Other Artifacts

Catalog Item –

Technical Capability 1

Catalog Item –

Technical Capability 2



3. Example: Service System

The development team reviews the Conceptual Design and collaborates with

the business to further review the Product Backlog Items (requirements/user

stories) for the Digital Service: Expense Management Service.

Upon fully understanding the business needs, and the technical standards and

Policies, the development team looks for existing SaaS or third-party

solutions. The decision is made to build a new in-house solution rather than

extensively customizing a third-party solution. The Service System, In-

House Expense Management System, is recorded in the Service Design

system and related back to the Expense Management Service in the Service

Portfolio system.

The development team creates the Logical Design for the In-House Expense

Management System. They will create a new application which will use an

internal Authentication Service, internal support which is offered as a service

(Support Service), and cloud hosting via a third-party Service Provider

(Hosting Service).

Figure 11: Service System: In-House Expense Management

a) Example: Service Release

The development team works with the business to understand the priorities of the Product

Backlog Items (business needs/requirements) and discovers the ability to track the

expenses is their number one priority. The ability to reimburse for out-of-pocket expenses

was a lower priority as most of the expenses would be charged to corporate cards and

would not require reimbursement.

The development team decided to create two releases of the In-House Expense

Management System to deliver functionality to the business more quickly. The first

release would include the core functionality for tracking expenses. The second release

In-House Expense Management System

Application

Instance

Authentication

Subscription

Support

Subscription

Hosting

Subscription

Service

System

Subscription

Service

Component

Service

Design

Component

Release

Composition

Component

Test

Component

Defect

Component

Project

Component

Requirement

Component

Require-

ment

IT

Initiative

Service

System

Test

Case

Defect

Service

Release

Build Package

Component

Build

Package

Requirement to Deploy



would allow reimbursement for out-of-pocket expenses. Additionally, the development

team would create the means for other countries to host their own expense management

systems.

The development team creates the first release of the In-House Expense Management

System. The Release Package includes the requirements, test cases, source code, build

package, knowledge documents, design documentation, and catalog item with the

technical blueprint describing how to set up an end user to track expenses in the Service

System.

Fulfilled by

Application Instance v 1.0

Authentication Subscription

Support Subscription


Source Code

Build Package

Requirements

Test Cases/Scripts

Runbook

Other Artifacts

Catalog Item- Track Expenses

Figure 12: In-House Expense Management System Release 1.0

After the first release of the In-House Expense Management System is made available to

the business, the development team begins to work on the second release. The team

builds the out-of-pocket reimbursement function into the core product. The development

team also establishes the technical framework which would allow another country within

the firm to deploy the same source code and application in their data center for their

users. A new catalog item, Managing Expenses, is created with corresponding technical

blueprints for how to establish general users in the In-House Expense Management

System who will track and manage their expenses, in addition to how managers are added

to the expense management system to approve their associate’s expenses. A second

catalog item is created to detail how a new instance of the In-House Expense

Management System should be created for the foreign business units within the firm.



Fulfilled by

Application Instance v 2.0


Support Subscription


Source Code

Build Package

Requirements

Test Cases/Scripts

Runbook

Other Artifacts

Catalog Item- Manage Expenses

Catalog Item- Host Instance

Fulfilled by

Figure 13: In-House Expense Management System Release 2.0

b) Example: Desired Service

The Desired Service represents the technical details of instantiating the access or new

Service System once the corresponding Offer is requested. It specifies the instance in

which the access will be granted, or in the case of a new Service System, the technical

details required to implement a new instance of the Service System.

c) Example: Actual Service

The Actual Service consists of the configuration items implemented as depicted in the

Desired Service.

Service Offer

The R2F value stream is where the lifecycle of the Service Offer and its supporting data objects are

managed. Once the Consumer requests an Offer, a Desired Service is created representing the technical

aspects of the fulfillment of the Service which is delivered to the D2C value stream.




a) Offer

The Offer is the means by which a Consumer requests the fulfillment of the Service. It is

the entity that is exposed to Consumers using terms they recognize and value. It is the

trigger for the interaction/outcome.

A Digital Service may provide multiple Offers to its Consumers based on a variety of

options. The Offer is fulfilled by a Service System and can be consumed by a person or

another Service System. Offers can also be comprised of other Service Offers, in which

case they are considered a bundled Offer.

Offers can be displayed in multiple Offer Catalogs and should be made visible to only

those authorized to consume the Offer. The Offer collects various information from the

Consumer to instantiate the Digital Service in a way that meets the request ultimately

described in the related catalog item and respective technical blueprint for that specific

Service Release.

Offer 1 Offer 2Offer 3

(Bundled Offer)Part of bundlePart of bundle

Service Compone

nt

Service Compone

nt

Service Compone

nt

Fulfilled byFulfilled by

Source Code

Build Package

Requirements

Test Cases/Scripts

Runbook

Other Artifacts

Catalog Item – Technical

Capability 1


Capability 2

Service Compone

nt

Service Compone

nt

Service Compone

nt

Fulfilled by

Source Code

Build Package

Requirements

Test Cases/Scripts

Runbook

Other Artifacts


Capability 3

Figure 14: Offer Data Object

b) Subscription

The Subscription represents the rights a Consumer (person or Service System) has to

access a Service. It is created when a Consumer requests an Offer which has been

fulfilled by the Service Provider.



Offer 1Service

SubscriptionRequested by a

Service System or Person

Figure 15: Subscription Data Object

c) Chargeback Contract

The Chargeback Contract details the financial obligations between the Consumer and

Service Provider(s) as defined at the time of the request to fulfill the Offer. It is captured

as part of the Subscription. It defines the billing rule and billing frequency used to price a

given Service.

d) Service Contract

The Service Contract describes the Service characteristics and supports measurement

tracking, governance, and audit associated to an Offer.

Each Service Contract data object is comprised of two main parts: the general contract

definitions (aka the header) and the SLOs (the line items), which also enable nesting

other Service Contracts that define service levels for different aspects of the Service.

These lines may need to be detailed due to the Service being composed of multiple

Services, because there are multiple Service Providers involved, or to cover different

areas of service levels.


a) Offer Catalog

The Offer Catalog is a set or collection of Offers that are grouped together as something

that can be consumed by certain Consumers or Consumer groups.

b) Chargeback Record

The Chargeback Record represents the actual charge to the subscriber based on the usage

of subscribed Services in a given time period. It computes the charge using the billing

rule, with the input being the usage records collected for the period.



3. Example: Service Offer

The business created an offer, Access to Manage Expenses, with the implementation of

the first release of the new In-House Expense Management System. An internal price

was created based on the estimated users for the system and the estimated costs for the

In-House Expense Management System. The Service Owner worked with IT to

determine how long it would take to grant access to the In-House Expense Management

System to establish the Service Contract for the Consumers. The description of the

Offer was written in user-friendly terms.

Figure 1: Offer from Release 1.0

Once the second release was implemented, the Service Owner updated access to the

Manage Expenses Offer to utilize the new features and functionality available. The

Service Owner created an Offer which was only visible to the other Service Owners

within the firm. It would allow those Service Owners in other countries to offer the

Expense Management Service to their associates.

In-House Expense Management System release 1.0

V 1.0 Release Package

In-HouseExpense Management System

V 1.0

Fulfilled by

Application

Instance

Authentication

Subscription

Support

Subscription

Authentication

Subscription

Source Code

Build Package

Requirements

Test Cases/Scripts

Run Book

Other Artifacts

Access to manage

expenses

Catalog Item

- Track Expenses


Usage

Component

Chargeback/Show

-back Component

Request

Rationalization

Component

Offer

Management

Component

Fulfillment

Execution

Component

Desired

Service

Usage

Record

Fulfill-

ment

Request

Request

Shopping

Cart

Offer

Charge-

back

ContractSub-

scriptionOffer

Catalog

Charge-

back

Record



Figure 17: Offer from Release 2.0

a) Example: Subscription

Once a Consumer orders the Access to Manage Expenses offer of the In-House Expense

Management System or a Service Owner orders a new instance, a Subscription is created

to track their entitlement to the system. The Subscription includes the contractual

information and billing information as published in the Offer.

b) Example: Chargeback Contract

The Chargeback Contract is created once the Offer is requested by the Consumer and

fulfilled. The Chargeback Contract represents the ongoing financial commitment by the

Consumer as prescribed in the Offer. Chargeback Records are created periodically to

capture the financial information for the Subscription.

c) Example: Service Contract

The business obtains agreement from the Service Provider to fulfill the Offer in a specific

timeframe as detailed within the Offer. KPIs are tracked to determine if the Service is

running within contractual commitments.

In-House Expense Management System release 2.0

V 2.0 Release Package

In-HouseExpense Management System

V 2.0

Access to manage

expenses

Host expense

management system

Fulfilled by

Application

Instance

Authentication

Subscription

Support

Subscription

Authentication

Subscription

Source Code

Build Package

Requirements

Test Cases/Scripts

Run Book

Other Artifacts

Catalog Item

- Manage Expenses

Catalog Item

- Host Instance

Fulfilled by



Service Interaction

The Service is deemed delivered to the Consumer and the value is deemed realized in the D2C value stream

when the Actual Service has been instantiated based on the technical specifications represented in the

Desired Service within the R2F value stream.


a) Usage

Usage is the measured use of a Digital Service or service component. For example, it can

be composed of (internal) hours, system usage (capacity, CPUs, etc.), or external supplier

usage.


a) Metrics

Metrics are measurements captured on a regular frequency to determine the health of a

Service. They are established to measure various aspects of the Service, such as value

provided to the Consumer, delivery or timeliness of the Service, and overall quality of the

Service.

• Value metrics are established to determine if the business (Consumer) is getting what

they want from the Service; examples include customer satisfaction, risk mitigation,

and cost savings

• Delivery metrics are established to track if the business is getting the value from the

Service when they want it; examples include time to deliver and overall cycle time

• Quality metrics are used to ensure the business is receiving the Service at a level of

quality they expect; examples include measuring items such as rework, incidents, or

complaints



6. Example: Service Interaction

a) Usage

The VP of Finance – who is the initial Service Owner - tracks how

many staff members have subscribed to the new Expense Management

Service, and how many other countries now Offer an Expense

Management Service. The Service Owner reviews operational reports

on a periodic basis to ensure the Service is meeting all contractual

commitments and is operating within stated service levels.

On a monthly basis, the Service Owner extracts Usage and Subscription

data to create Chargeback Records for the monthly service

consumption. The Service Owner also tracks the financial aspects of

the Service to the expected return on investment to determine if

adoption of the Service is at the rate expected. This information allows

the VP of Finance to change the marketing and communication strategy

of the Service month-to-month as needed for the Expense Management

Service to be successful.

b) Metrics

The VP of Finance feels customer satisfaction is the primary value

driving the Expense Management Service and decides to implement a

customer survey to elicit feedback from a percentage of the customers.

As the Service Owner, the VP reviews the cycle time of the Expense

Management Service requests to the time of fulfillment and compares

to the target of fulfilling 90% of the requests within 24 business hours.

The VP also wants to ensure the Service is of high quality and decides

to calculate quality by meeting the SLA commitments and by keeping

rework to less than 5% of the requests.

Detect to Correct

Problem

Component

Incident

Component

Service

Monitoring

Component

Event

Component

Change

Control

Component

Diagnostics &

Remediation

Component

Configuration

Management

Component

Problem,

Known

Error

Incident

Event

Service

Monitor

Run

Book

RFC

Service Level

Component

Actual

Service

Service

Contract



References

(Please note that the links below are good at the time of writing but cannot be guaranteed for the future.)

• Defining “IT Service” for the IT4IT™ Reference Architecture, White Paper (W161), February 2016,

published by The Open Group; refer to: www.opengroup.org/library/w161

• The Open Group IT4IT™ Reference Architecture, Version 2.1, an Open Group Standard (C171), January

2017, published by The Open Group; refer to: www.opengroup.org/library/c171

• Cathy – May we list the Service Model Management Snapshot here?: Then once Snapshots are voted

approved and are rolled into the final standard and approved through Company Review for IT4IT RA

Version 3.0, we could replace this with the IT4IT RA v3.0, yes?

The Open Group Service Model Management Snapshot of the IT4IT™ Reference Architecture, Version

2.1, which entered Forum Review April 2019, published to members of The Open Group IT4IT Forum

only; refer to the Plato “Review Documents” tab of the IT4IT Forum:

https://collaboration.opengroup.org/forums/it4it/protected/revdocuments.php

http://www.opengroup.org/library/w161

http://www.opengroup.org/library/c171



About the Author

Sue Desiderio, JNS Solutions, Inc.

Sue Desiderio has led enterprise tool implementations for several internal IT organizations with a focus on

integration of processes and the supporting data across the IT Value Chain. She has been part of the IT4IT

initiative from the beginning as a key contributor to the service model and the Requirement to Deploy (R2D)

value stream. She has worked to continuously improve the business of IT for internal IT organizations over

the last 19 years.



About The Open Group

The Open Group is a global consortium that enables the achievement of business objectives through

technology standards. Our diverse membership of more than 600 organizations includes customers, systems

and solutions suppliers, tools vendors, integrators, academics, and consultants across multiple industries.

The Open Group aims to:

• Capture, understand, and address current and emerging requirements, establish policies, and share best

practices

• Facilitate interoperability, develop consensus, and evolve and integrate specifications and open source

technologies

• Operate the industry’s premier certification service

Further information on The Open Group is available at www.opengroup.org.

http://www.opengroup.org/