IT4IT™ Service Model

IT4IT™ Service Model

Proposed Change Summary

A White Paper by:

Sue Desiderio, JNS Solutions, Inc.

<Month> 2019

IT4IT™ Service Model: Proposed Change Summary

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 © 2019, 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.

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®, Open O® logo, Open O and Check® Certification logo, 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-HERA™, O-PAS™, Open FAIR™, Open Platform 3.0™, Open Process Automation™, Open Subsurface Data

Universe™, Open Trusted Technology Provider™, O-SDU™, Sensor Integration Simplified™, SOSA™, and the SOSA™

logo are trademarks of The Open Group.

DXC® is a registered trademark of DXC in the United States and/or other countries.

Micro Focus® is a registered trademark of Micro Focus International plc and its group companies.

ServiceNow® is a registered trademark of ServiceNow, Inc., in the United States and/or other countries.

Raytheon® is a registered trademark of Raytheon Company in the United States and around the world.

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

Executive Summary ...................................................................... 5

Overview ...................................................................................... 6

Proposed Rationalization of Functional Components ................... 7

Proposed Renaming of Data Objects ............................................ 8

Conceptual Service renamed to Digital Service .......................................... 8

Conceptual Service Blueprint renamed to Conceptual Design ...................... 8

Logical Service renamed to Service System ............................................... 8

Logical Service Blueprint renamed to Logical Design ................................. 9

Service Release Blueprint renamed to Release Package and moved to Level 29

Service Catalog Entry renamed to Catalog Item and moved to Level 2 ......... 9

Proposed New Roles ................................................................... 10

Service Owner ....................................................................................... 10

Service Provider .................................................................................... 10

Technical Owner .................................................................................... 10

Support Owner ...................................................................................... 10

Proposed New Data Attributes ................................................... 11

Digital Service ....................................................................................... 11

Conceptual Design ................................................................................. 11

Service System ...................................................................................... 11

Service Release ...................................................................................... 11

Desired Service ...................................................................................... 11

Actual Service ....................................................................................... 11

Logical Design....................................................................................... 12

Release Package .................................................................................... 12

Service Offer ......................................................................................... 12



Subscription .......................................................................................... 12

Proposed Service Backbone Extension........................................ 13

Service Offer Lifecycle Data Objects ....................................................... 13

Service System Lifecycle Data Objects .................................................... 14

Appendix A: Proposed Changes (Graphics) ............................... 15

Proposed IT4IT Reference Architecture Level 1 Proposed Changes ........... 15

Proposed IT4IT Reference Architecture Level 2 Proposed Changes ........... 16

References .................................................................................. 20

About the Author ....................................................................... 21

About The Open Group .............................................................. 22



Boundaryless Information Flow

achieved through global interoperability

in a secure, reliable, and timely manner

Executive Summary

In applying the IT4IT™ Reference Architecture, Version 2.1 within IT organizations,

some significant consistency and usability questions have arisen which this paper

proposes to address. It refers to the forthcoming Snapshot of the IT4IT standard (due

later in 2019), and the associated IT4IT Service Model Guide.

The proposals in this paper come from two primary sources:

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

Reference Architecture (see References), which outlined many key Service

Model concepts not yet incorporated into the IT4IT standard

• The practical experience of several IT organizations which have deployed

the IT4IT Service Model approach

Contributing organizations include Micro Focus®, ServiceNow®, Raytheon®, PwC,

Sykehuspartner HF, DXC®, and CC&C Solutions.

With the proposed changes, the standard will be strengthened and should be more

understandable for IT practitioners wishing to implement the IT4IT standard, thus

supporting The Open Group vision of Boundaryless Information Flow™.



Overview

The proposals detailed below would make the following changes to the IT4IT Reference Architecture,

Version 2.1:

• Rationalization of the Catalog Composition and Release Composition functional components, resulting in

the deletion of the Catalog Composition component

• Renaming of several data objects, including eliminating the term “blueprint” and moving some data

objects from abstraction Level 1 to Level 2

• Addition of role to the normative metamodel

• Adding several new data attributes

• Redefining the service backbone



Proposed Rationalization of Functional Components

Experience in implementing tool chains based on the IT4IT standard strongly suggests that the management

of the catalog item should happen in the Release Composition component as part of the release package.

Moving the management of the catalog item as a system of record entity to Release Composition allows us to

transfer or rationalize the related functional criteria and thus to eliminate a separate Catalog Composition

functional component.

This simplifies the Reference Architecture and removes redundant functionality.



Proposed Renaming of Data Objects

Data objects in the IT4IT standard are used to manage the phases of a service across its full lifecycle (as

described by the IT Value Chain1). Experience applying the IT4IT standard in practical scenarios leads us to

propose changes to the names of some of the normative data objects in Version 2.1.

It is important to have consistency throughout the Reference Architecture, and in particular to have kept the

ability to tie key data objects in the Service Model back to the definition of service. This enhances the ability

of new consumers of the Reference Architecture to understand how the elements fit together.

These proposed renamings emphasize that service backbone objects are meant to be persistent and current

throughout the lifecycle of the service and can act as reliable references for the service provider throughout

the delivery lifecycle.

Note that the term “blueprint” in object names has proved confusing for many and has been replaced.

Conceptual Service renamed to Digital Service

The Service Portfolio functional component was intended to represent the system of record for the entire

service. However, the data object name “Conceptual Service” suggests to many that only a very high-level

description of the service is managed here.

We thus propose to rename this object “Digital Service”.

This change emphasizes that the IT4IT standard is about managing services that have a technology

component and that the Service Portfolio functional component is where responsibility lies for the

management of that service throughout its lifecycle.

Conceptual Service Blueprint renamed to Conceptual Design

For new Digital Services, or proposed changes to Digital Services, there should be a Conceptual Design. This

secondary data object is managed by the Service Portfolio functional component. A single Digital Service

may have multiple Conceptual Designs throughout its life.

Logical Service renamed to Service System

This change supports the initial definition of service and its aspects, and more importantly represents that

Logical Service data is maintained over the life of the Digital Service and does not represent just a point-in-

time logical design.

The Service System includes the people, processes, and technologies required to fulfill the service.

1 IT4IT concepts such as IT Value Chain, key data objects, and functional components are formally defined in The Open Group IT4IT™ Reference

Architecture, Version 2.1 (see References).



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

References) defines an IT4IT service as comprised of three parts: service system, service offer, and service

interaction. A service system is an integrated set of resources, applications, other services and supporting

capabilities, all functioning as a single entity to fulfill the service.

The need to capture all this information as data is critical to a service-centric operating model (or product-

centric operating model, depending on your organization’s choice of vocabulary).

Logical Service Blueprint renamed to Logical Design

A Logical Design maps to an associated Conceptual Design. It must contain sufficient data to enable a

Configuration Management Database (CMDB) or other system of record tool to create and maintain the

association of applications, infrastructure devices, and other services (via subscription to those services) to

the Digital Service itself, and throughout the life of the Digital Service (each of those entities will have its

own lifecycle).

Aspects such as cost will be managed at both the entity level and the Digital Service level. For instance, an

application owner will track costs, roadmap, etc. of their application. If the application is part of a Service

System to deliver a Digital Service, costs will be aggregated as part of the Digital Service as well.

For example, the logical design should specify how a Digital Service composed of other services will inherit

the “price” of those services within the Digital Services cost.

Service Release Blueprint renamed to Release Package and moved to Level 2

“Release Package” is an industry standard term which better represents the intent of this data object.

The technical specification (Service Release Blueprint) is one of the common elements within the Release

Package and will still be delivered.

We propose to move this data object from the Level 1 diagram to Level 2, as it represents technical aspects

and a level of detail more typically aligned to Level 2.

Service Catalog Entry renamed to Catalog Item and moved to Level 2

This is part of the proposed rationalization of the Catalog Composition and Release Composition functional

components.

Service Catalog Entry has often been confused with Service Offer by consumers of the IT4IT Reference

Architecture.

This change should help this data object to be viewed correctly as per the original intent of the IT4IT

standard as it contains the technical implementation details needed to create Service Offers that are ready for

consumption.

We propose to move this data object from the Level 1 diagram to Level 2, auxiliary to the Release Package,

as it represents technical aspects more typically aligned to Level 2.



Proposed New Roles

In the process of implementing the IT4IT Reference Architecture, several practitioners have identified

operational roles that are essential to the effective management of an IT4IT standard-aligned ecosystem.

These roles correspond to proposed new data attributes.

Service Owner

Represents the person or group responsible for the lifecycle of the Service Offer and the Digital Service in its

entirety. The service owner should have a solid understanding of the business purpose of the service, and a

clear understanding of the potential consumers and technical capabilities available from one or many service

providers.

Note: At the time of writing, many organizations are assessing the implications of product versus service for

discussions about developing and delivering value to the business. This service owner role title could be

renamed to product owner for your organization, as needed.

Service Provider

Represents the person or group responsible for the lifecycle of the Service System and ultimately delivering

the technical capabilities to realize the service value. The service provider works closely with the service

owner to ensure that the ultimate needs of the customer are met.

Technical Owner

Represents the person or group accountable to for technical aspects of the Actual Service.

Support Owner

Represents the person or group accountable to remediate issues arising from the running of the Actual

Service.



Proposed New Data Attributes

We propose that the following data attributes should be added to the IT4IT Reference Architecture to clarify

responsibilities, relationships, and lifecycle status. These were identified as needed by various practitioners

implementing the IT4IT standard within their organizations. The proposed new data attributes are listed

under the name of each data object.

Digital Service

• ServiceOwner: group or person accountable for representing the business needs of the Digital Service

Conceptual Design

• DigitalServiceId: unique identifier of the Digital Service to which the conceptual design is associated

From an IT practitioner perspective, several use-cases substantiate this proposal:

• As IT organizations migrate to a service-centric approach, the need to provide a list of all Digital

Services is a standard expectation

• There are requirements to track all financial aspects of a Digital Service back to an actual record in the

CMDB

• Traceability back to the Digital Service across all key IT processes and systems means that the Digital

Service should be a Configuration Item (CI) in the CMDB, so that the DigitalServiceId attribute can be

tracked; for example, in Incident, Change, and Problem tickets

Service System

• ServiceProvider: group or person accountable to create, enhance, or provide the service from a provider

perspective

• ServiceOwner: accountable for representing the business needs of the Service System

• Status: status of the Service System; e.g., planned, retired, etc.

• DigitalServiceId: unique identifier of the related Digital Service

Service Release

• ServiceSystemId: unique identifier of the related Service System

Desired Service

• ReleasePackageId: getting necessary information on the Service System

Actual Service

• TechnicalOwner: group or person accountable to own the Actual Service



• SupportOwner: group or person accountable to remediate issues arising from the running of the Service

System

Logical Design

• ServiceSystemId: unique identifier of the related Service System

Release Package

• CatalogItemId: details required be a service provider (could be internal) to provide the service

Service Offer

• ReleasePackageId: identifies the release package (technical blueprint) to instantiate the Service Offer

• DigitalServiceId: identifier for the Digital Service

• ServiceSystemId: identifier for the Service System

• ServiceOwner: group or person accountable for the lifecycle of the Service Offer

Subscription

• StartDateTime: effective date/time the Subscription is in effect

• EndDateTime: effective date/time the Subscription has ended

• ChargebackContractId: unique identifier of the related Chargeback Contract



Proposed Service Backbone Extension

The service backbone identifies the data objects that are mandatory, whether managed systematically or not,

to fulfill the value of a service. Essentially, you must have a service interaction, a service system, and a

service offer to actually provide the value (outcome) to the consumer. The backbone items represent the

lifecycle data objects of those elements.

In the IT4IT Reference Architecture, the service backbone had previously been defined as the Service and

Service System lifecycle data objects, but the Service Offer lifecycle data objects were excluded from the

backbone definition. A major shift and focus for the IT organization is to understand the value provided to

the consumer, and to design and plan for the consumption of the services. By excluding these objects from

the service backbone, we are minimizing a major transformation aspect of the IT4IT Reference Architecture

itself.

The proposal is to add the Service Offer lifecycle data objects to the service backbone and highlight that there

are two lifecycles we manage to deliver the service:

• The Service Offer

• The Service System

Although there are connections between the two lifecycles, they can run independently (i.e., changes to the

service offer don’t necessarily mean the service system changed, and vice versa). The Service System data

objects are typically managed by the service provider, whereas, the Service Offer data objects are typically

managed by the service owner.

There are no changes to the Service Offer lifecycle data objects other than adding them to the service

backbone.

Digital

Service

Service

System

Service

Release

Desired

ServiceActual

Service

Service

Offer

Charge-

back

ContractService

Contract

Sub-

scription

Service System Lifecycle Objects

Service Offer Lifecycle Objects

Service Backbone Data Objects

Figure 1: Incorporating the Service Offer Lifecycle Data Objects into the Service Backbone

Service Offer Lifecycle Data Objects

The Service Offer lifecycle data objects are important to highlight as being part of the service backbone as

they make sure we have control over the service instances being consumed and allow us to show/trace back



the consumption to the Digital Service and Service Release. The proposal is to add the key data objects

representing the lifecycle of the Service Offer to the service backbone including Service Offer, Subscription,

Chargeback Contract, and Service Contract.

Service System Lifecycle Data Objects

The Service System lifecycle data objects are already included in the Reference Architecture as part of the

service backbone.



Appendix A: Proposed Changes (Graphics)

Proposed IT4IT Reference Architecture Level 1 Proposed Changes

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

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

PortfolioRequirement to Deploy Request to Fulfill Detect to Correct

Offer

Charge-

back

ContractService

Contract

Sub-

scription

Figure 2: IT4IT Reference Architecture Level 1 Proposed Changes



Proposed IT4IT Reference Architecture Level 2 Proposed Changes

Requirement Component

Requirement to Deploy

1:n

n:1

PortfolioBacklog

Item

Portfolio BacklogItem (rationalized/

prioritized)

Competency(availability)

Assets(availability)

Policy

Portfolio Backlog Item

Policy

Requirement

1:n

ConceptualService

PortfolioBacklog

Item

Digital Service

Conceptual Design

n:m

Scope AgreementScope Agreement

Service Design Component

Service System

Portfolio Demand

Component

Service Portfolio

Component

n:m

Business Process

Portfolio Backlog Item

n:1Policy

Component

Proposal

Component


IT Asset Management

Labor Management

Problem Component

Problem, Known ErrorDetect to Correct

Enterprise Architecture

Enterprise Architecture

Component

n:m

1:1

Supporting Function

1:n

Business

Strategy

(External to IT)

Budget for Run & Operate

IT Budget Request

Approved IT Budget

Scoping & Investment Decisions

ActualSpend

Scoping &InvestmentDecisions

IT Investment Portfolio

Component

ITFM Supporting Function

IT Budget Item

n:1

1:n

Project Component

IT Initiative


Offer Management

Component

Request to Fulfill

1:n

Estimated Labor & Asset Configuration

Estimated Labor & Asset Cost

Proposed ITInvestments

EstimatedBudget

Development Scope & Budget

Development Spend

Cost Modeling Component

ITFM Supporting Function

IT Cost Model

Chargeback/Showback

Component

Request to Fulfill

n:1

Finance

(external to IT)

ChargebackRecord

Service Model

Data Object – Key

Functional Component – Key

Functional Component – Auxiliary

Data Object – Auxiliary

IT4IT Reference Architecture, Version 2.1

Record Fabric Integration

Entity Relationship

Engagement Dataflow

Current Practice

Figure 3: Strategy to Portfolio Proposed Changes



Fulfillment Execution Component

Portfolio Demand Component

Strategy to PortfolioPortfolio Backlog Item

Policy Component

Source Control

Component

Problem Component

Detect to Correct

IT Initiative

Requirement

1:n

1:n

Source

1:n

Defect

1:n

RFC (Normal)

1:n

Logical Design

Policy

Defect

Defect

1:n

n:m

RFC

n:m

Requirement

Component

Test Case

Test Component

Incident Component

Project Component Change Control

Component

1:n 1:n

1:1

Scope Agreement

1:n 1:1ServiceSystem

Service Release

CatalogItem

Defect Component

Problem, Known Error

1:1

n:1

1:n

Defect

1:1

Incident

ITInitiative

Requirement

Defect

1:n

Service Design Component

Release Package

Release

Composition Comp.

Strategy to Portfolio

1:n

RFC

ReleasePackage

Service Contract (Template)

n:m

DesiredService

Fulfillment Request

1:n

Build Component

Build

Build Package

Component

Build Package

n:1n:m

n:m

Service Level Component

Service Contract

n:m

1:n

Detect to Correct

Detect to Correct

Request to Fulfill

Proposal Component

Scope Agreement

Strategy to Portfolio1:n

Request

DevelopmentSpend

Development Spend

DevelopmentScope & Budget

Service Portfolio Component

DigitalService


Chargeback/Showback Component

Request to Fulfill

Request Rationalization Component

Request to Fulfill

1:n

ChargebackRecord

Service Model

Data Object – Key






Entity Relationship

Engagement Dataflow

Current Practice

Figure 4: Requirement to Deploy Proposed Changes



ChargebackRecord

CatalogItem

Usage

Usage

Subscription

Request

User Profile

n:m

1:1

Shopping Cart

Chargeback Record

n:m

1:n

1:n

ServiceMonitor

Request

Knowledge

Status

Fulfillment

Engine & Deploy/

Provision Systems

RFC

Request

Composite/Compound Request

Sourcing &

Vendor

Management

(External to IT)

Engagement

Experience Portal


1:n

Service Catalog Entry (Bound)

Actual Service

Release Package

ServiceContract

(Template)

Service Level Status

ServiceContract

(Instance)

Self-Service

SupportKnowledge Collaboration

Conversation

Service Catalog

Shopping Cart

Estimated Labor& Asset

Configuration

EstimatedLabor &

Asset Cost

ChargebackRecord

Request

ChargebackRecord

Proposal Component


Invoice

CostRelease

Composition

Component

Release Package


Change Control

Component

RFC

Detect to Correct

DesiredService

Fulfillment Request

Fulfillment Execution

Component

n:1

Incident

Component

Detect to Correct

Service Monitoring

Component

Detect to Correct

n:m

1:n

1:1

Configuration

Management

ComponentActual Service

Detect to Correct

1:1

1:n

n:1

Offer Catalog

n:m

Offer

Offer Mgmt.

Component

Request Rationalization

Component

Subscriptionn:m

Request

Service Level

Component

Detect to Correct

Service Contract

1:1

Project Component


Incident

IT Asset

Management

Supporting Function

Finance

(External to IT)

1:n

Knowledge &

Collaboration

Component

Supporting Function

Service Portfolio

Component


Chargeback/Showback

Component

ChargebackContract

Chargeback Record

1:n

Usage

Component

Usage Record

1:n

1:n

Service Model

Data Object – Key






Entity Relationship

Engagement Dataflow

Current Practice

Figure 5: Request to Fulfill Proposed Changes



Knowledge & Collaboration

Component

n:m

Self-Service Support

Defect Component


Defect

Portfolio Demand Component


Portfolio BacklogItem

IncidentEvent

Actual Service

RFCService Monitor

1:n

1:n n:m

n:m

Problem, Known Error

n:m

n:m

n:m

Event Incident

RFC

RFC

Problem RFC

IncidentRequest to Fulfill

Fulfillment Execution Component

PortfolioBacklog

Item

n:m

Usage

1:n

Run Book

Run Book

Run Book

n:m

Service DiscoveryActual Service

Defect

Knowledge

n:m

1:n

1:n

Supporting Function

ServiceMonitor

KnowledgeRun Book

Interaction

n:m

DesiredService

1:1

1:1

Usage Component

Request to Fulfill

Defect

1:1 1:1


Request to Fulfill

Status

Service Monitoring

Component

Incident

Component

Change Control

Component

Problem

Component

Diagnostics &

Remediation

Component

Configuration

Management

Component

Event

Component

RFC

1:n

Request to Fulfill

Actual Service

Fulfillment Request

Service Contract

Service Level

Component

KPI

n:m

Release Composition Component

Requirementto Deploy

Service ReleaseBlueprint

n:m

Offer ManagementComponent

Service Contract (Template)ServiceContract

(Template)

Service Level Status

Business / ITMeasurement

Business Measurement (Incident)

Request to Fulfill

1:1

Request Rationalization

Component

Request to FulfillSubscription

Service Contract

(Instance)

1:1

Conversation

n:1

Service Model

Data Object – Key






Entity Relationship

Engagement Dataflow

Current Practice

Figure 6: Detect to Correct Proposed Changes



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, a Standard of The Open Group (C171),

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

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.

The author would also like to acknowledge significant contributions from:

• Mark Bodman

• Sukumar Daniel

• Keith Jahn

• Stephanie Ramsay

• Lars Rossen

• Jan Stobbe

• Christian Verstraete

• Dan Warfield



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 mission of The Open Group is to drive the creation of Boundaryless Information Flow™ achieved by:

• Working with customers to capture, understand, and address current and emerging requirements,

establish policies, and share best practices

• Working with suppliers, consortia, and standards bodies to develop consensus and facilitate

interoperability, to evolve and integrate specifications and open source technologies

• Offering a comprehensive set of services to enhance the operational efficiency of consortia

• Developing and operating the industry’s premier certification service and encouraging procurement of

certified products

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

http://www.opengroup.org/

Documents

IT4IT™ Service Model