Table of Contents
Revision History .................................................................... Error! Bookmark not defined.
1
EXECUTIVE SUMMARY..................................................................................................... 5
2
DISA Enterprise Service Management Framework (DESMF) Overview ......................... 5
2.1 DESMF Scope .................................................................................................................................... 5
2.2 DESMF Goal and Alignment with DoD Strategic Documents ............................................................ 5
2.3 DESMF Purpose ................................................................................................................................ 6
2.4 Benefits of the DESMF ..................................................................................................................... 11
2.5 DESMF Expected Outcomes ........................................................................................................... 11
2.6 DESMF Guidance ............................................................................................................................ 12
2.7 DESMF General Recommendations on Utilizing the Framework for Process Improvement .......... 12
2.8 Critical Success Factors (CSF) ........................................................................................................ 13
2.9 Guiding Principles of the DESMF ..................................................................................................... 13
3
Overview of the DESMF Structure ................................................................................. 17
3.1 Service Strategy Domain.................................................................................................................. 17
3.2 Service Design Domain .................................................................................................................... 21
3.3 Service Transition Domain ............................................................................................................... 22
3.4 Service Operations Domain ............................................................................................................. 22
3.5 Continual Service Improvement (CSI) Domain ................................................................................ 23
3.6 Domain Relationships Table ............................................................................................................ 24
4
Roles & Responsibilities................................................................................................. 27
4.1 Executive Sponsor ........................................................................................................................... 27
4.2 Principal Directors ............................................................................................................................ 27
4.3 Domain Owner ................................................................................................................................. 27
4.4 Process Owner ................................................................................................................................. 27
4.5 Process Manager ............................................................................................................................. 28
4.6 Service Owner .................................................................................................................................. 28
4.7 Service Manager .............................................................................................................................. 29
4.8 Product Owner ................................................................................................................................. 29
DESMF Edition 1.0
Page 1
4.9 Subject Matter Expert (SME)............................................................................................................ 29
4.10 Other Roles ...................................................................................................................................... 29
5
Metric vs. Measurement .................................................................................................. 30
6
Generic Recommended Milestones for DESMF Process Design ................................. 31
6.1 Define Scope and Objectives ........................................................................................................... 31
6.2 Validate the Current Environment .................................................................................................... 31
6.3 Develop High-Level Process Definition ............................................................................................ 32
6.4 Define Roles and Responsibilities .................................................................................................... 32
6.5 Document Detailed Work Flow for Each High Level Activity............................................................ 32
6.6 Build the Process ............................................................................................................................. 32
6.7 Define and Document Knowledge Transfer and Training Requirements ........................................ 32
6.8 Finalize Process Guide .................................................................................................................... 32
6.9 Develop Implementation Plan .......................................................................................................... 32
7
Individual Domain and Process Framework.................................................................. 32
8
Service Strategy Domain ................................................................................................ 34
8.1 Domain Metrics ................................................................................................................................ 36
8.2 Strategy Management (SM) for IT Services ..................................................................................... 37
8.3 Customer Relationship Management (CRM) ................................................................................... 38
8.4 Service Portfolio Management (SPM) .............................................................................................. 39
8.5 Service Catalog Management (SCM) .............................................................................................. 41
8.6 Financial Management for IT Services (FM) .................................................................................... 42
8.7 Demand Management (DM) ............................................................................................................. 44
9
Service Design Domain................................................................................................... 45
9.1 Domain Metrics ................................................................................................................................ 46
9.2 Service Level Management (SLM) ................................................................................................... 47
9.3 Availability Management (AvM) ........................................................................................................ 49
9.4 Capacity Management (CapM) ........................................................................................................ 51
9.5 IT Service Continuity Management (ITSCM) ................................................................................... 52
9.6 Information Security Management (ISM) ......................................................................................... 53
9.7 Design Coordination (DC) ................................................................................................................ 55
DESMF Edition 1.0
Page 2
10 Service Transition Domain ............................................................................................. 56
10.1 Domain Metrics ................................................................................................................................ 58
10.2 Change Management (ChM) ............................................................................................................ 60
10.3 Change Evaluation (Eval)................................................................................................................. 61
10.4 Asset Management (AM).................................................................................................................. 63
10.5 Configuration Management (CfM) .................................................................................................... 65
10.6 Knowledge Management (KM) ......................................................................................................... 67
10.7 Release and Deployment Management (RDM) ............................................................................... 68
10.8 Service Validation and Testing (SVT) .............................................................................................. 69
10.9 Transition Planning and Support (TPS) ........................................................................................... 70
10.10 Supplier Management (Sup)........................................................................................................... 71
11 Service Operations Domain ............................................................................................ 72
11.1 Domain Metrics ................................................................................................................................ 74
11.2 Incident Management (IM) ............................................................................................................... 74
11.3 Problem Management (PM) ............................................................................................................. 76
11.4 Request Fulfillment (RF) .................................................................................................................. 77
11.5 Event Management (EM) ................................................................................................................. 78
11.6 Access Management (AcM) ............................................................................................................. 79
12 Continual Service Improvement (CSI) Domain .............................................................. 80
12.1 Goal .................................................................................................................................................. 80
12.2 Scope ............................................................................................................................................... 80
12.3 Benefits and Expected Outcomes of CSI ......................................................................................... 80
12.4 Process Relationship Map................................................................................................................ 80
13 Functions ......................................................................................................................... 81
13.1 Service Desk .................................................................................................................................... 83
13.2 Application Management .................................................................................................................. 85
13.3 IT Operations .................................................................................................................................... 87
13.4 Engineering ...................................................................................................................................... 90
13.5 Technical Management .................................................................................................................... 92
14 References ....................................................................................................................... 94
DESMF Edition 1.0
Page 3
15 Glossary........................................................................................................................... 95
16 Appendix A - “DESMF - A Journey in Managing Service” ............................................ 96
DESMF Edition 1.0
Page 4
1.0 EXECUTIVE SUMMARY
Driving toward service excellence is the virtuous goal for organizations today, in part because it has been
proven that a proactive service environment is less expensive to run than a reactive service environment.
This document is the embodiment of the integration of various best practices, frameworks and standards to
define an Agency-wide service management approach. It is a ‘Service Oriented’ framework with a focus on
creating and managing services across their entire lifecycle. It aligns and integrates processes for service
management and defines processes at a high level, describing the ‘WHAT’ not the ‘HOW’, enabling crossfunctional teams the ability to create and improve processes in the common pursuit of service excellence.
More in-depth process specific guidance will be provided in a supplemental companion publication.
The intent is that this is a ‘living’ document which will be enhanced on an annual basis to continually bring
in new ideas, refresh and mature content and to perpetuate the continued focus on the destination of
service excellence.
2.0 DISA Enterprise Service Management Framework (DESMF)
Overview
In 2004, the Defense Information Services Agency (DISA) commissioned a study from the Open GIS
(Geospatial Information Services) Consortium, Inc. (OGC to define the role of Enterprise Service
Management for DISA. The study recommended the adoption of a recognized framework for guiding
principles in Information Technology Service Management (ITSM) initiatives. Many Department of Defense
(DoD) agencies have been involved in various Enterprise Service Management efforts over the years. There
are many frameworks available for guidance both within DoD and throughout private industry. Up until
this point, however, there has not been an integrated framework designed that encompasses the best
practices from multiple frameworks, that provides guidance on establishing the documentation, structure,
and roles and responsibilities to plan, implement, monitor and improve ITSM. What follows are the
recommendations and guidance from the DISA Information Technology Service Management Office with
regards to this authoritative reference framework, the Agency architect and subject matter expert for
processes and service management in general. The DESMF is in alignment with the Operations Framework
and the Service Assurance Framework. The frameworks together, provide a strong foundational structure
and approach to providing excellent services and support to our mission partners and the warfighter at the
edge.
2.1 DESMF Scope
The scope of the DESMF applies to all the services and capabilities DISA provides, both internally and
externally, and the ITSM processes that support these services. Service implementations and process
efforts should align to the DESMF as the authoritative reference framework.
2.2 DESMF Goal And Alignment With DoD Strategic Documents.
The goal of the DESMF is to provide a framework to successfully align the delivery of IT services required to
support the DoD mission. Successful IT Service Management (ITSM) builds a bridge between people,
processes, and technology that result in a combined effort that promotes new ideas, effectiveness, and
efficiencies by standard methods and practices to deliver value to mission partners. As a means to ensure
DESMF Edition 1.0
Page 5
the DoD DESMF contains the strategic elements necessary to provide a focused and purposeful service
management framework for the department, key DoD Strategic Plans must be considered and referenced
so critical DoD strategic concepts can be embedded throughout the framework. The following DoD level
strategic baseline documents provide the required strategic alignment and baseline of the necessary key
strategic concepts considered throughout this framework.
As depicted in figure 1 below, DoD Strategy Alignment originates from the Executive Branch’s National
Security Strategy (NSS) from which the Chairman of the Joint Chiefs of Staff develops the National Military
Strategy (NMS). Once received, the Secretary of Defense uses the NMS and the Quadrennial Defense
Review (QDR) Report to develop the DoD Strategic Management Plan (SMP) which is then used to produce
the more detailed DoD Information Enterprise Strategic Plan (basis for the JIE), the DoD CIO Campaign Plan,
and the DoD IT Enterprise Strategy and Roadmap. Short descriptions of the DoD IE Strategic Plan, the DoD
Campaign Plan, the DoD ITESR, and the DISA Strategic Plan are provided in the below paragraphs.
Figure 1. DOD Strategic Alignment
DESMF Edition 1.0
Page 6
2.2.1 DoD Strategic Management Plan.
What is it? The DoD Strategic Management Plan (SMP) establishes specific business goals that directly
support the Strategic Goals of the National Military Strategy (NMS).
Why is it important? It articulates the goals and objectives of the DoD business domain, while ensuring
unity of effort across the enterprise.
What are the key concepts? (1) total force readiness, (2) financial management, (3) information security,
(4) agility, and (5) improved processes across the department.
2.2.2 DoD Information Enterprise Strategic Plan & DoD IT Enterprise Strategic
Roadmap (ITESR).
What is it? Together, the DoD IE Strategic Plan and the DoD ITESR form the basis for a broad approach to
achieving the DoD Joint Information Enterprise (JIE).
Why is it important? These plans articulate how the DoD will strengthen its IT enterprise through
integrated and interoperable frameworks to sustain the US military might and status as the preeminent
warfighting organization in the world.
What are the key concepts? (1) information as a strategic asset, (2) interoperable infrastructure, (3)
synchronized and responsive operations, (4) identity and information assurance, (5) optimized investments,
(6) agility and interoperability of the IM/IT/IA workforce.
2.2.3 2.2.3 DoD CIO Campaign Plan.
What is it? The DoD CIO Campaign Plan supports the Department's Strategic Management Plan and
provides the requirements necessary for the DoD CIO, to "build agile and secure information technology
capabilities to enhance combat power and decision making while optimizing value.
DESMF Edition 1.0
Page 7
Why is it important? It provides guidance to operate and defend the JIE, which enables DoD to employ
warfighting and support capabilities. The JIE is a secure environment, comprised of shared IT infrastructure,
enterprise services, and single security architecture to achieve full spectrum superiority, improve mission
effectiveness, increase security, and realize IT efficiencies.
What are the key concepts? Unified IT infrastructure and supporting services which are fully integrated,
interoperable, secure, and centralized approach across all organizations within the department.
2.2.4 DISA Strategic Plan.
What is it? The DISA Strategic Plan target objective state provides for a joint information environment (JIE)
that optimizes the use of the DoD IT assets by converging communications, computing, and enterprise
services into a single joint platform that can be leveraged for all Department missions.
Why is it important? Attainment of the JIE will reduce total cost of ownership, reduce the attack surface of
networks, and enable mission partners to more efficiently access the IT resources for their missions.
What are the key concepts? Provide a collaborative JIE enabling information sharing and interdependent
enterprise services that are seamless, interoperable, efficient, and responsive to Warfighter requirements.
2.3 DESMF Purpose
The purpose of the DESMF is to provide guidance on the application of best practices to planning,
implementing, monitoring, and improving service management initiatives. Process initiatives and service
implementation efforts should align to the framework. Supporting this purpose, this document will:

Define the best practices that drive the implementation of the framework

Define the overall structure to the DESMF, to include Domains and processes covering the entire
lifecycle of IT service management and processes in DISA

Provide a general overview of the recommended processes in terms of its goals and objectives,
scope, benefits, lexicon, and roles and responsibilities

Define the controls framework required to meet compliance with the Agency agreed upon
standards
DESMF Edition 1.0
Page 8

Define the recommended interfaces between the Domains and the processes

Recommend a set of milestones for process implementations
To better understand the difference between a standard and a framework and a standard. . DISA will use
ISO/IEC 20000 as the standard of certification for the DESMF. It consists of a set of minimum requirements
to audit an organization against effective IT Service Management. The standard promotes the adoption of
an integrated process approach to effectively manage numerous linked activities. Launched formally in
December 2005, it was introduced to measure the level of implementation of Information Technology
Infrastructure Library (ITIL) best practices in an organization. The core components of the standard are two
documents are Part 1 and Part 2, the “shalls” and “shoulds,” respectively.
ISO/IEC 20000, Information Technology Service Management comprises several volumes published as part
of a comprehensive overhaul of the standard between 2004 and 2011. Parts 1 – 5 were used for this
edition. They will be collectively referred to as ISO 20000-#, such as ISO 20000-1 for Part 1.

ISO/IEC 20000-1:2011, Information Technology Service Management Part 1: Service Management
System Requirements . Defines the Service Management System. It contains descriptions for
general requirements; design and transition of new or changed services; and the requirements for
service delivery, relationship, resolutions, and control processes. It contains specific “shall
statements, for each topic, such as “All incidents shall be recorded.”

ISO/IEC 20000-2:2005, Information Technology Service Management Part 2: Code of Practice (ISO
20k-2) ISO 20k-2 has a similar structure to ISO 20k-1, but comprises the code of practice. It is a
document with hundreds of "recommendations" a service provider should take into consideration
when attempting to meet the requirements. ISO 20k-2 is similar in intention to ITIL v3, in that it
describes a body of practice.
Other documents from ISO/IEC 20000 that will be used within the DESMF include:

DESMF Edition 1.0
ISO/IEC 20000-3:2009, Information Technology Service Management Part 3: Guidance on Scope
Definition and Applicability of ISO/IEC 20000-1 (ISO 20k-3). ISO 20k-3 describes how to
appropriately scope ISO 20k compliance in a variety of service provider environments. It is
extremely useful in creating “will/shall” accountability statements for use in multi-provider
operations. This is a critical component for generating specific contract language to ensure
Page 9
contractor accountability to ITSM obligations, while allowing them the flexibility to execute tasks
according to their own methods.

ISO/IEC 20000-4:2010, Information Technology Service Management Part 4: Process Reference
Model (ISO 20k-4). ISO 20k-4 is structured similarly to ISO 20k Parts 1 & 2. It contains a series of
tables for each identified process or other area. The contents of each table identifies the context,
purpose, outcomes, and requirements traceability to other ISO 20k documents. It serves as a ready
reference guide for directing and controlling activities within the Service Management System.

ISO/IEC 20000-5:2010, Information Technology Service Management Part 5: Exemplar
Implementation Plan for ISO/IEC 20000-1 (ISO 20k-5). ISO 20k-5 contains detailed guidance for
three-phased approach for implementing the SMS. It contains an extremely useful set of tables
and checklists for the implementation program, and is mapped directly to the overall SMS that ISO
20k describes. It provides a very detailed and pragmatic starting point for ITSM implementation
and improvement efforts.
A framework is used by an organization as a structure in which to align efforts and to establish a minimum
level of competency as well as continually mature and improve. It provides a structure from which an
organization can plan, implement, and measure. The DESMF is based on many frameworks, one of them
being ITIL. The flexibility of the DESMF is the ability to adopt and use the best framework for specific
processes and functions within DISA. Best practices and norms may come from bodies of knowledge such
as the Information Technology Infrastructure Library (ITIL), the Control Objectives for Information and
related Technology (CobiT), the Capability Maturity Model (CMM), Six Sigma, the enhanced Telecom
Operations Map (eTOM), ISO/IEC 27001 and other frameworks. Each framework has a particular area of
emphasis, but each brings consistency and ability to measure performance. A common mistake is to
assume that the frameworks are exclusive of each other and that all the parts of each framework must be
implemented. The DESMF combines aspects of these frameworks that apply, provides a uniform and
common language and is structured to provide guidance to determine which best practices to focus on first
when adopting best practices to improve effectiveness and efficiency.
Additionally, the DESMF, the Management Framework, is only one part of a Defense Service Management
System (Defense SMS. The Defense SMS depicts the major components and normative/authoritative
sources and systems that are employed in a holistic Service Management Lifecycle. The principle
documents within the Defense SMS are ITIL v3 for basic language and process descriptions; ISO 20000 as an
auditable standard; DESMF; and Federal or Department regulations. The Defense SMS is depicted below:
DESMF Edition 1.0
Page 10
2.4 Benefits of the DESMF





Provides a single, definable, repeatable, and scalable documented framework for recommended IT
best practices
Clearly identifies roles and responsibilities for IT Service Management.
Supports ability of IT to measure and improve internal performance and service provisioning
Improved mission partner satisfaction through a more professional, efficient approach to service
delivery and support
Enables better decision-making at all levels by identifying relationships and information items
exchanged by all processes throughout the Service Management Lifecycle.
2.5 DESMF Expected Outcomes




DESMF Edition 1.0
Services will be implemented faster, more efficiently, and with higher quality
The costs associated with the entire service lifecycle are understood
Compliance and subsequent auditing will be stabilized through repeatable processes
Better understanding of the importance of IT services and the value derived from each service both
from the provider as well as the mission partner perspective
Page 11

DoD will adopt the characteristics of a high-performing IT organization; such as providing high
service and availability levels, improved alignment between IT services providers and the mission
areas, and significantly improved management of changes to ensure security and capability of the
information enterprise.
Services will be measured transparently and traceable through the component and agency level
strategies to those of DoD.

2.6 DESMF Guidance
In order to better understand the DESMF, it is necessary to understand a few key terms. A service is
comprised of a range of products, processes and people packaged such that it is perceived by mission
partners and Users as a self-contained, single, coherent entity that enables them to achieve mission
objectives and functions. Policies are formally documented management expectations and intentions.
Policies are used to direct decisions, and to ensure consistent and appropriate development and
implementation of processes, standards, roles, activities, IT Infrastructure etc. A process is a structured set
of activities designed to accomplish a specific objective. A process takes one or more defined inputs and
turns them into defined outputs. A process may include any of the Roles, responsibilities, tools and
management controls required to reliably deliver the outputs. A procedure is a document containing steps
that specify how to achieve an activity. Procedures are defined as a part of processes. As such, a change to
a procedure does not necessarily change a process, just as a change to a process does not necessitate a
policy change. The DESMF is the authoritative reference framework to address services and processes that
are owned and adjudicated by DISA. The DESMF includes:

Processes – Agency wide processes defined at a high level and guidance to establish authoritative
Process Owners and Process Managers
Goal and Scope – The goal and scope of each process in the lifecycle
Metrics – Recommendations on the use of metrics as actionable items
Interfaces – Interfaces are defined at the Domain level



The DESMF is not:

Concept of Operations (CONOPS) – CONOPS for processes are developed separately from this
document, but use this framework to align the efforts
Implementation plan – While this document contains milestones for process design work at a high
level, it is not meant as a detailed project plan or as an overall ITSM implementation plan

2.7

DESMF General Recommendations on Utilizing the Framework for Process Improvement
Define Outcomes for Implementation
 Define Critical Success Factors (CSFs) and Key Performance Indicators (KPIs)
 Create the process implementation roadmap – this is the overall plan to identify the order of the
process implementations and how the implementation should occur.
DESMF Edition 1.0
Page 12

Create the Governance Structure and Align with the Domains




Define the Area of Responsibility (AOR) for each Domain
Define the Governance workflow
Develop the Governance Communications Plan
Develop the architectures for the Pilot, IOC, and FOC support organizations required, and align with
current and future-state organizations for ownership.

Define Organizational Process Ownership
 Identify areas best suited for ownership of processes
 Identify Process Owners
 Create the implementation roadmap to ensure Process Owners are available to give guidance to
other process owners at appropriate phases of the spiral.

Create a Training Plan
 Develop framework training requirements
 Identify required training levels
o Domain Owner
o Process Owner
o Process Manager
o General Staff

Determine Risk Strategy
 Define criteria for decisions
 Identify risk assessment processes
 Identify risk mitigation activities
2.8 Critical Success Factors (CSF)
The following factors are recommended for the successful adoption of the framework in process
improvement initiatives:





Form a guiding coalition – Create a consortium to provide guidance on enhancing and maintaining
the DESMF
Create vision – Clearly identify the gap that DISA is trying to close between the use of current
process frameworks and the future consolidated framework
Communicate the vision – Create a directed training and communications plan for the adoption of
the DESMF
Create short term wins – Identify, mitigate, and report on pain points related to how services are
currently provided
Create Key Performance Indicators (KPIs) to measure each CSF
2.9 Guiding Principles of the DESMF
The basic lexicon for the DESMF will be taken from ITIL®.
DESMF Edition 1.0
Page 13
Rationale: ITIL® is the most widely utilized framework in the world as related to ITSM. A single ITSM lexicon
is necessary to ensure proper communications related to the DESMF.
Implications: The various branches of the DoD should maintain a cooperative approach to defining,
accepting, and socializing this terminology.
The ITIL® Glossary is available online at the Official ITIL® Website: (http://www.itilofficialsite.com/InternationalActivities/ITILGlossaries_2.aspx).
Each Enterprise Service Management Framework process should have a single Process Owner,
accountable for process quality and integrity.
Rationale: Divided ownership creates a less optimized process and increases the likelihood of overlapping
responsibilities and areas of the process being unmeasured.
Implications: The various reporting structures within the agencies should allow for a matrix authority
environment related to the process.
Processes and services should be designed with sufficient flexibility to ensure that not only the current
needs of the Warfighter are addressed, but that future needs in technology and capacity are anticipated
and accounted for as part of the service lifecycle.
Rationale: Warfighter requirements change rapidly in a cyber environment and current processes must
support agile service development and implementation.
Implications: Principles of agile development and understanding of concepts such as capacity on demand
need be applied to all areas of support and development.
With the understanding that particular procedures and work instructions differ between and even within
agencies, there should be consistent processes.
Rationale: In order to provide proper governance and measure the overall effect of implementing the
DESMF, it is necessary to have consistent processes.
Implications: The various branches of the DoD should maintain a cooperative consortium to continually
improve the overall framework.
DESMF should directly support decision making at all levels. Enterprise Architecture is used as a
governance vehicle. Governance ultimately means how decisions are made, how decision rights are allocated,
and how checks on decisions are conducted. Governance is fractal: how decisions are made at the bottom are the
same as how they are made at the top.
DESMF Edition 1.0
Page 14
DESMF should reflect the language of the law. JCIDS/DAMS is specific in the documents, architectural
artifacts and exhibits that support MAIS (Major Automated Information Systems acquisitions. A brief
summary of the laws, statutes, and regulations that exist, and how to apply them at a high level, should be
included. Example: For a ship-based IT system, an organizational chart showing the required help desk
support should be included.
Key viewpoints for ITSM integration into DESMF are Capability, Service, Information, and Program. If
“capability” means “requirement plus solution,” capability descriptions are required. If “capability when
delivered equals service,” service mapping must be performed. If the service is new or is a major
enhancement, the Service Delivery Lifecycle must be planned and executed, thus requiring the Program
viewpoint. Lastly, interfaces and information exchanges are critical, and must be identified and managed.
For those instances where spiral or iterative process development and implementation means that one or
more processes may have to address an external dependency on another process that is not mature
enough to fulfill the requirement, ISO 20k-4 provides some guidance. This language has been revised to
address the DESMF 2.0 environment:
In exceptional circumstances, the ITSMC may propose the publication of Process Interface
Workaround for one of the following types:
o
o
o
Type 1, when the required support cannot be obtained for the publication of a desired
component, despite repeated efforts;
Type 2, when the subject is still under technical development or where for any other
reason there is the future but not immediate possibility of an agreement on an
International Standard;
Type 3, when the responsible body has collected data of a different kind from that which is
normally published as process or function (“state of the art”, for example).
ISO 20000-5, Exemplar implementation plan for ISO/IEC 20000-1, contains detailed instructions, guidelines,
and checklists for phased implementation. It should be used as a critical reference when planning your
development program.
The governance model for these Types will be for the Process Owner with the dependency to present a
request through the ITSMC for relief of the dependency. The ITSMC will use Rapid Improvement Events, or
similar activities, in order to fulfill the requirement. The Process Interface Workaround will contain specific
information to account for ownership, content, and retirement when a permanent solution has been
created by the responsible Process Owner. The dynamic is similar to Problem Management providing
workarounds to Incident Management pending root cause analysis and permanent fix actions.
DESMF Edition 1.0
Page 15
DESMF Edition 1.0
Page 16
3.0 Overview of the DESMF Structure
The DESMF structure is currently made up of processes and functions in close alignment with the ITIL v3
framework, but the DESMF also adds additional functions which are considered significant. Similar to the
ITIL v3 framework, the DESMF aligns the processes and functions to the five stages of the service lifecycle.
These are Service Strategy, Service Design, Service Transition, Service Operations, and Continual Service
Improvement.
3.1
Service Strategy Domain
3.1.1 At the center of the service lifecycle is Service Strategy. This is where
DoD strategic concepts, organizational objectives, and mission partner
needs are aligned. Topics covered in Service Strategy include the
service portfolio and the implementation of strategy through the service
lifecycle. The Service Strategy Domain provides the necessary goals
and objectives to support mission partners and to identify, select, and
prioritize service opportunities. A prime goal of Service Strategy is to
understand why a service is being provided before deciding how to
provide the service. Service Strategy is about ensuring costs and risks
associated with service portfolios are understood. The DESMF differs
from the ITIL v3 framework in that the Service Catalog Management
process, normally found in Service Design has been moved to Service
Strategy. The relationship between the service portfolio, the service
pipeline, and the service catalog is so tightly coupled that for DISA, this
process is considered part of Service Strategy. Customer Relationship
Management, Demand Management, and Financial Management are
other processes within Service Strategy. Agency Governance
Agency Governance is the system—people, process, and technology--by which DISA directs and controls its
equities. It involves regulatory rules and guidance, the roles and relationships between the Agency's
Directors, its high-level decision-making boards, and other stakeholders, External stakeholders are
suppliers, mission partners, or communities affected by the Agency's activities. Internal stakeholders are
the directors, executives, and other employees of the Agency. Much of the focus in Agency Governance is
concerned with mitigation of the conflicts of interests between stakeholders. Ways of mitigating or
preventing these conflicts of interests include the processes, policies, laws, and decision-making bodies
which have impact on the way the Agency is controlled. An important theme of corporate governance is
the nature and extent of accountability and responsibility of different decision-making groups in the
Agency. There has been renewed interest in the corporate governance practices, particularly in relation to
accountability, since the high-profile collapses of a number of large corporations during 2001-2002. Their
demise is associated with the passing of the Sarbanes-Oxley Act in 2002, intending to restore public
confidence in corporate governance. Sarbanes-Oxley has greatly increased regulatory interest and is one of
the reasons why the DESMF is needed. DoD Agencies have regulatory requirements, e.g., 5000 Series
Regulations, Clinger Cohen Act compliance, SAE 116 requirements that industry and ITIL do not address.
DESMF Edition 1.0
Page 17
The DESMF provides guidance for alignment on how to adapt industry best practices without violating
regulatory requirements. Because DISA is composed of multiple business units that combine capabilities
and products to create Enterprise services for our mission partners, many decisions at DISA are made at the
Agency-level to promote integration. Agency Governance provides greater accountability for decisionmaking around the use of IT in the best interest of all stakeholders.
In industry, Agency Governance differs from Information Technology (IT) Governance where IT Governance
is a subset discipline of Corporate Governance focused on IT systems, their performance and risk
management. Governance systematically involves everyone: board members, executive management, staff
and mission partners. It establishes the structure used by the organization to establish transparent
accountability of individual decisions, and ensures the traceability of decisions to assigned responsibilities.
The DoD or the Military Departments have published guidance and instructions regarding the use of
Enterprise Architecture, specifically the Department of Defense Architecture Framework version 2 (DODAF
2) as a primary governance tool.
The Department of Defense Architecture Framework (DoDAF) serves as the overarching, comprehensive
framework and conceptual model enabling the development of architectures to facilitate the ability of
Department of Defense (DoD) managers at all levels to make key decisions more effectively through
organized information sharing across the Department, Joint Capability Areas (JCAs), Mission, Component,
and Program boundaries. It is the Department’s means for standardizing representation of architecture
information. The DoDAF serves as one of the principal pillars supporting the DoD Chief Information Officer
(CIO) in his responsibilities for development and maintenance of architectures required under the ClingerCohen Act. It also reflects guidance from the Office of Management and Budget (OMB) Circular A-130, and
other Departmental directives and instructions. The current version, DoDAF V2.0 focuses on architectural
data, rather than on developing individual products as described in previous versions. In general, data can be
collected, organized, and stored by a wide range of architecture tools developed by commercial sources.
The purpose of DoDAF 2.0 is to support more effective decision-making by using consistent, model-based
architectures that describe the relationships between mission- and operational requirements in terms of
information, data, performers, and actions.
DoDAF is prescribed for the use and development of architectural models. Not all DoDAF-prescribed models
need to be created. DoDAF V2.0 is “Fit-for-Purpose”, based on decision-maker needs. DoDAF concentrates
on data as the necessary ingredient for architecture development. Key process owners will decide which
architecture models are required. However, regulations and instructions from both DoD and Chairman of
the Joint Chiefs of Staff (CJCS) have particular presentation view requirements. In other words, if a model is
created, it must be according to standard.
DESMF Edition 1.0
Page 18
DoDAF V2.0 Viewpoints
In DoDAF V2.0, architectural viewpoints are composed of data that has been organized to facilitate
understanding. To align with ISO Standards, where appropriate, the terminology has changed from Views to
Viewpoint (e.g., the Operational View is now the Operational Viewpoint).
Operational Viewpoint
Services Viewpoint
Articulate the performers, activities,
services, and their exchanges providing for,
or supporting, DoD functions
Systems Viewpoint
Articulate the legacy systems or
independent systems, their composition,
interconnectivity and context providing for,
or supporting, DoD functions
Project Viewpoint
Articulate operational scenarios, processes,
activities and requirements
Describes the relationships between operational and
capability requirements and the various projects being
implemented; Detailed dependencies between capability
management and the Defense Acquisition System process
Standards Viewpoint
Articulate applicable Operational, Business, Technical, and
Industry policy, standards, guidance, constraints, and
forecasts
Data and Information Viewpoint
Articulate the data relationships and significant structures in
the artichitecture content
All Viewpoint
Overarching aspects of architecture context that relate to all
views
Capability Viewpoint
Articulate the capability requirement,
delivery timing and deployed capability
Figure 2 - Diagram of DoDAF V2.0 Viewpoints
Types of viewpoints include the following:

All Viewpoint (AV) - Describes the overarching aspects of architecture context that relate to all
viewpoints.

Capability Viewpoint (CV) (New in DoDAF V2.0) - Articulates the capability requirements, the
delivery timing, and the deployed capability.

Data and Information Viewpoint (DIV) (New in DoDAF V2.0) - Articulates the data relationships
and alignment structures in the architecture content for the capability and operational
requirements, system engineering processes, and systems and services.

Operational Viewpoint (OV) - Includes the operational scenarios, activities, and requirements that
support capabilities.
DESMF Edition 1.0
Page 19

Project Viewpoint (PV) (New in DoDAF V2.0) - Describes the relationships between operational
and capability requirements and the various projects being implemented. The Project Viewpoint
also details dependencies among capability and operational requirements, system engineering
processes, systems design, and services design within the Defense Acquisition System process.

Services Viewpoint (SvcV) (New in DoDAF V2.0) - Presents the design for solutions articulating the
Performers, Activities, Services, and their Exchanges, providing for or supporting operational and
capability functions.

Standards Viewpoint (StdV) (Renamed from Technical Standards View TV) - Articulates the
applicable operational, business, technical, and industry policies, standards, guidance, constraints,
and forecasts that apply to capability and operational requirements, system engineering processes,
and systems and services.

Systems Viewpoint (SV) - Articulates, for Legacy support, the design for solutions articulating the
systems, their composition, interconnectivity, and context providing for or supporting operational
and capability functions.
Consider using the DODAF viewpoints and models as the format for architectural diagrams. The following
viewpoints support the Service Management Lifecycle:

AV-1 Overview and Summary Information

CV-1 Capability Vision

CV-2 Capability Taxonomy

CV-3 Capability Phasing

CV-4 Capability Dependencies

CV-5 Capability to Organizational Development Mapping

CV-6 Capability to Operational Activities Mapping

CV-7 Capability to Services Mapping

OV-1 High-Level Operational Concept Graphic

OV-2 Operational Resource Flow Description

OV-4 Organizational Resource Flow Matrix

OV-5A Operational Activity Decomposition Tree

OV-5B Operational Activity Model

OV-6C Event-Trace Description
DESMF Edition 1.0
Page 20
3.2

SV-2 Systems Resource Flow Description

SV-6 Systems Resource Flow Matrix

StdV-1 (Final IT Standards Profile generated by the DISR online)

StdV-2 Standards Forecast

Svc-5 Operational Activity to Services Traceability Matrix

Svc-7 Services Measures Matrix

Svc-8 Services Evolution Description
Service Design Domain
Service Design ensures that services are designed to align and match current and future requirements.
Service Design as a Domain controls the planning and organizing of the resources, infrastructure,
communication, and physical and logical components of a service in order to improve its quality and the
interaction and understanding between DISA and its mission partners. The Domain needs to ensure
that the goals and objectives of Service Strategy are built and managed in line with the vision and
mission of the Agency. Service Design relies heavily on the Service Owners to understand the
requirements, needs, and service “behavior” of DISA’s mission partners. Service Design is accountable
for changes to existing services, creation of new services, and management of the retirement of
existing services. Service Design coordinates considerably with Service Operations to ensure that the
data necessary for monitoring and responding to service variances is built into every service.
Part of Service Design should include a definition of the intended structure for the support
organizations. The various models, such as GOCO, COCO, multi-provider, Mission Partnering, must be
architected as early in the lifecycle as possible. ISO20k-3, Guidance on Scope Definition and
Applicability of ISO/IEC 20000-1 is an appropriate starting point. While ISO 20000-3 describes
certification accountability and ownership for multi-provider environments, the principles contained in
the standard are directly transferrable and appropriate.
When dealing with multiple providers, or when a tiered service organization is in place (Government
supported by contractors), it is critical to have the relationships and interfaces between operational
entities clearly defined, and a plan in place for managing them.
There is a body of practice named “Seam Management” that gives guidance and instruction on
managing relationships within and between support organizations.
DESMF Edition 1.0
Page 21
One note on defining contract language regarding “process compliance.” While it is not necessarily
true that portions of the FAR at times excludes the government for dictating the manner in which
contractor-internal processes and procedures are followed (e.g., “The contractor shall use the Change
Management Process described in DESMF 2,” there are relatively straight-forward methods of assuring
the desired outcome. One of them is simply to mandate in CDRLs or Deliverables that reports about
the process or service performance follow what is described in the DESMF or related materials. For
example, “The contractor shall use the provided reports for Change Management,” or “the contractor
shall report the following information for Change Management.” As ensuring outcomes is the purpose
of Service Management, ensure that your contract language speaks to the process outcome, and uses
the metrics described in this document.
For further guidance on this topic, COBiT 5 is generally excellent. Many aspects of Financial
Management for IT Service, and Supplier Management, also apply.
Consider using DODAF viewpoints and models as the format for architectural diagrams. The DODAF
viewpoints Service, Data and Information, Operations, Programs, Systems, and Standards all directly
apply.
3.3
Service Transition Domain
The Service Transition Domain assists in the navigation of the design of service as it moves from
concept to production, implements the service, and makes modifications to the service as a result of
required corrective actions or to improve an existing service. As such, it is the responsibility in this
Domain to ensure that the strategic vision of DISA which guided the creation of the service in Service
Design is carried out during the implementation phases. The Domain Owner serves as the guardian of
the production environment, ensuring that the policies and processes designed and executed in the
Service Transition Domain mitigate the risks of changing the production environment. This is
accomplished through analysis and testing, proper scheduling of the modifications, recording significant
attributes of the assets that support the services, and ensuring that the knowledge of the services
provided is properly available to the right person at the right time.
Consider using DODAF viewpoints and models as the format for architectural diagrams. The DODAF
viewpoints depicting Operations, Services, and Programs are of most value in Service Transition.
3.4
Service Operations Domain
The Service Operations Domain controls the full range of matters pertaining to sustaining assured
information delivery, assured system and network availability, and assured information protection for
information technology (IT) capabilities that deliver and support the provided services. The Domain
DESMF Edition 1.0
Page 22
serves as the approval authority to introduce new initiatives, ensures standards-based configuration
and operation of all infrastructure, controls the runtime aspects of services making sure that services
are behaving correctly and within Service Level Agreements (SLAs), administers and controls security
policies, identifies incidents and infrastructure issues, performs problem resolution, and implements
metrics that track the overall progress of the operations Domain. The Domain Owner is also
accountable for ensuring that processes that support the services are executed in a cost-effective
manner. As such, these processes need to have both an internal as well as a mission partner focus. It is
within this Domain that the mission partner determines the ongoing value extended by the Agency.
3.5
Continual Service Improvement (CSI) Domain
While the achievement of the mission is dependent on all organizations aligning their respective
strategies, development and operational efforts, it is imperative to constantly look for ways to improve
the services provided. With technology improving rapidly and outside situations being fluid, it is
necessary to improve services not only to gain a competitive edge, but in many instances to simply
protect DoD data and maintain the status quo.
DESMF Edition 1.0
Page 23
3.6
Domain Relationships Table
The table below gives a brief synopsis of the relationships of the Domains. An excerpt named ‘DESMF – A
Journey in Managing Service’ which depicts one snapshot of Domain and process interaction can be found
in the Appendix A.
From ISO 20K, the Service Management System:
From:
Service
Strategy (SS)
Service Design
(SD)
Service
Transition (ST)
Service Operations (SO)
Continual Service
Improvement (CSI)
To:
DESMF Edition 1.0
Page 24
From:
Service
Strategy (SS)
Service Design
(SD)
Service
Transition (ST)
Service Operations (SO)
Continual Service
Improvement (CSI)
Capacity numbers
Change Information
Feedback on strategy for
production services
Measurement of Strategy
processes
Service Level
Agreements
Effectiveness of
strategy moving into
production
Usage measurements
Cost information related
to efficiency
recommendation
To:
SS
Financial information
from assets
Mission partner
interfaces for
requirements
Financial reporting
SD
Strategic Security
Policy
Configuration Item
(CI) information for
capacity and design
Usage measurements
Performance related
statistics
Service Portfolio
information
Move service to
production
Incidents related to
design failure
Service Catalog
Test services
Measurement of Service
Design processes
Recommendations related
to performance of services
Reports on Service Level
Management information
(SLM)
Financial costs of
services
Collaborative effort on
Service Design
Package (SDP)
Demand Strategy
ST
Guidance for change
approval
Specifications for
new services
Financial guidance
for service
implementations
Products to be
deployed
Budget information
Deployment and test
support
Deployment support
Measurement of Service
Transition processes
ASI Support
Analysis of Knowledge
Management information
Access to facilities
Specifications for
evaluation
DESMF Edition 1.0
Page 25
From:
Service
Strategy (SS)
Service Design
(SD)
Service
Transition (ST)
Service Operations (SO)
Continual Service
Improvement (CSI)
To:
SO
Intent of services
Event management
alert criteria
Budget information
Releases
Measurement of Service
Operations processes
Change information
Services operating
procedures
Governance
Analysis of performance
issues
Fulfillment of Problem
Management
Access management
information
Trending information
OLA/SLA information
CSI
DESMF Edition 1.0
Overall Strategy
SLM information
Targets
Design Specifications
from SDP
Changes in
architecture
Mission partner
satisfaction reports
Changes in services to
measure
Raw data related to
service and
infrastructure
Page 26
4.0 Roles & Responsibilities
Roles, as defined in ITIL, are a set of responsibilities, activities and authority granted to a person or team.
One person or team may have multiple roles. In this section, the roles of the key positions are defined.
4.1
Executive Sponsor
The Executive Sponsor is accountable for the framework implementation, and responsible for securing
spending authority and resources for the project. This role is a vocal and visible champion, legitimizes the
project’s goals and objectives, keeps apprised of major project activities, and is the ultimate decision-maker
for the project, has final approval of all scope changes, and signs off on approvals to proceed to each
succeeding project phase.
4.2
Principal Directors
The Principal Director is a senior manager with demonstrable interest in the outcome of process
implementation, who is ultimately responsible for securing spending authority and resources for the
project. The Principal Director acts as a vocal and visible champion, legitimizes the project’s goals and
objectives, keeps abreast of major project activities, and contributes to the decision-maker for the project,
has approval of scope changes, and signs off on approvals to proceed to each succeeding project phase.
4.3
Domain Owner
The primary responsibility of the Domain Owner is to ensure that the processes within the Domain provide
support to the Service Owners, who have accountability for the services that are provided. The Domain
Owner is accountable for all of the processes in the Domain, the interfaces and process interdependencies
and for process maturity levels. The Domain Owner ensures proper resourcing, the appointment of Process
Owners, and the strategy for each Domain. The Domain Owners work reciprocally to ensure proper
handoffs between the Domains. The Domain Owners represent their Domain on the upper governance
boards, while establishing governance boards to handle Domain specific matters related to policy,
standards, and overall command and control for the Domain.
4.4
Process Owner
The person fulfilling this role is accountable for ensuring that the process is being performed according to
the agreed and documented process and is meeting the objectives of the process definition. There is one
Process Owner per process. The Process Owner has the following responsibilities:

Accountable for the process design

Establish a cross-directorate team to design and define the enterprise process

Document and publicize the process

Define appropriate standards to be employed throughout the process

Define Key Performance Indicators (KPIs) to evaluate the effectiveness and efficiency of the process
and design reporting specifications

Periodically audit the process to ensure compliance to policy and standards
DESMF Edition 1.0
Page 27

Review opportunities for process enhancements and for improving the efficiency and effectiveness
of the process

Ensure that all relevant staff has the required technical and business understanding, knowledge and
training in the process and understand their role in the process

Review integration issues between the various processes

Ensure that the process is “Fit for Purpose”

Attend top-level management meetings to assess and represent the process requirements and
provide management information
4.5
Process Manager
In matters that pertain to the process, the Process Manager is answerable to the Process Owner and
performs the day-to-day operational and managerial tasks demanded by the process activities. The Process
Manager does not necessarily fall within the Process Owner’s chain of command. In addition, the Process
Manager has the following responsibilities:

Ensure that the process is used correctly

Provide management and other processes with strategic decision making information related to the
process

Monitor the process, using qualitative and quantitative Key Performance Indicators (KPIs) and make
recommendations for improvement

Play a key role in developing requirements for the process tools

Function as a point of escalation for questions related to the process

Identify training requirements of support staff and ensure that proper training is provided to meet
the requirements

Provide metrics and reports to management and mission partners in accordance with outlined
procedures and agreements
4.6
Service Owner
The Service Owner is accountable for one or more services throughout the entire service lifecycle,
regardless of where the technology components, processes or professional capabilities reside. The Service
Owner is responsible for continual improvement and the management of change affecting the services
under their care and is a primary stakeholder in all of the underlying IT processes which enable or support
the service they own. This role has the authority and responsibilities that include ensuring that activities
are performed to identify, document and fulfill service requirements. The Service Owner is also
responsible for ensuring that the following controls are built into the service during the Service Design
phase:

DESMF Edition 1.0
Mission partner requirements
Page 28
4.7

Operational requirements related to Event Management, Continuity of Operations (COOP), and
training

Command and control requirements for both normal operations and when on heightened alert

Situational Awareness requirements for required stakeholders

Auditing requirements, both financial and for SLA compliance

Any required information sharing interface points
Service Manager
This role is responsible for managing the end-to-end lifecycle of one or more IT services. The Service
Manager provides leadership on the development of the business case and architecture, service
deployment and lifecycle management schedules, performs service cost management activities in close
partnership with other organizations such as operations, engineering and finance. The Service Manager is
also responsible for the controls built into the service.
4.8
Product Owner
This role is responsible for overseeing the end-to-end lifecycle of one or more IT products. The Product
Owner ensures the product(s) are fit for purpose and meet requirements of all associated services
4.9
Subject Matter Expert (SME)
Subject Matter Experts provide guidance in the provisioning of services to mission partners by providing the
solutions and delivery of process implementation throughout the lifecycle and various maturity levels. The
SME further provides direction and support to integrate the process with other service supporting
processes. Process design SMEs must have ITSM certification.
4.10 Other Roles
For a successful transition, it is necessary to identify other key participants in the process implementation
effort:
Dedicated members – Points of contact from the various directorates and field offices who participate in
the implementation. They act as the contact point for the implementation team from the affected groups
and provide status information to the management of their respective directorates.
Key Stakeholders – Individuals from the Agency who have a stake in the process implementation and
mission partners whose support is needed during the implementation.
Financial support – Someone who understands the funding required for resourcing the implementation
project, and understands Return on Investment (ROI) and Total Cost of Ownership (TCO) concepts, both in
general and in context to the Agency.
Education coordination –As training programs are developed, it will be necessary to have a training expert
to assist in ensuring that employees who take the training can be credited for their time and that
management has a method for tracking.
DESMF Edition 1.0
Page 29
5.0 Metric vs. Measurement
There is a difference between metrics and measurements. A measurement is an indication of the size,
quantity, amount or dimension of a particular attribute of a product, service or process while a metric is a
measurement of the degree that any attribute belongs to a system, service, product or process. For
example, the number of errors in a system would be a measure, while the number of errors per person
hours would be a metric. The fact that a measurement is not used as a metric does not mean resources
should be expended to curtail its collection, only that the data should no longer be manipulated and
reported upon.
Other guidelines for metrics:

Review which metrics to collect on a regular schedule. There needs to be a reason and a decision for
each metric collected. If there are no longer decisions being made, do not expend resources in
collecting and analyzing the metric.

Metrics should show a change in percentages, not simply a change in number. i.e., percent of incidents
categorized incorrectly is more effective then number of incidents categorized incorrectly.
Guidance for metrics can be found in many of the major frameworks (ITIL ®, COBIT ®, eTOM ®, etc.).
Guidance for Metrics from authoritative sources include:

ISO 20000-4: Process Reference Model, Section 5.14 (Measurement) provides a very brief process
definition that identifies context, purpose, outcomes, and traceability within ISO 20000.

Navy Process Reference Model integrates monitoring and reporting activities and tasks into each
defined process.
DESMF Edition 1.0
Page 30
6.0 Generic Recommended Milestones for DESMF Process
Design

ISO 20000-5: Exemplar Implementation Plan for ISO/IEC 20000-1, has an excellent set of guidelines
and checklists for creating and executing a 3-phased approach.
7.0
These milestones should be applied to all processes. The intent is that process
improvement/implementation balances the need for a stronger process foundation with the need to
demonstrate more immediate value from the process in the form of quick wins.
Quick wins have common characteristics:

Lower level of effort than other initiatives while still adding value in a relatively short period of
time

Important to the overall process improvement effort

Eases organizational pain points
An immediate focus on quick wins will help engage key members of the organization to improve the
process. Their involvement will be recognized by others and help establish momentum for additional
improvements that may require more time and commitment. The key is to begin building sponsorship
at all levels of the organization by demonstrating real benefits that add real value.
Generic process milestones are:
7.1
Define Scope and Objectives





7.2
Determine and document business objectives and boundaries of project
Gain necessary concurrence or authority to proceed
Determine the relevance and impact of DoD, Agency, and IT Strategic Plans and related policies
Consider aligning your project schedule to a DAMS/JCIDS acquisition model.
Consider adopting DODAF viewpoints and models, especially for aligning organizations, resources,
and activities into your overall plan for executing your strategy.
Validate the Current Environment






DESMF Edition 1.0
Collect existing process documentation
Identify existing roles & responsibilities
Document ""As-Is"" process environment
Identify pain points for quick wins
Identify supporting tools
Document tool gaps
Page 31

Use industry tools that show the mapping between ITIL, COBiT, and ISO 20000 to help inform your
gap analysis.
Develop High-Level Process Definition




Identify high level CSFs and KPIs
Document high level process definitions
Define high level process inputs and outputs
Consider aligning process definitions and metrics with ISO 20000. Parts 4 and 5 are especially
useful.
Define Roles and Responsibilities



Identify skills and knowledge level
Create RACI matrix mapping activities to process roles
Develop cross-functional relationships
Document Detailed Work Flow for Each High Level Activity


Document detailed procedures for each high level activity
Create communications plan
Build the Process
7.3
7.4
7.5
7.6

Document “To-Be” process environment

Create workflow

Define inputs and outputs at a detailed level

Incorporate control information

Determine appropriate metrics

Document tool requirements, including interfaces to other processes
7.7
Define and Document Knowledge Transfer and Training Requirements

Develop Training Program

Deliver Process and Tool Training
7.8
Finalize Process Guide
7.9
Develop Implementation Plan
8.0 Individual Domain and Process Framework
The Domain sections that follow are divided along the five areas identified within the ITIL® v3 framework.
These are Service Strategy, Service Design, Service Transition, Service Operations, and Continual Service
Improvement. The interfaces between the processes within each Domain are identified.
DESMF Edition 1.0
Page 32
After the Domains, there is a section focused on Functions.
From the perspective the Service Management System as defined by ISO/IEC 20000, an acceptable
approach for describing an operational or management model would be to focus initially on creating the
desired outcomes and requirements for the ITIL v3 functions. This would then allow you to identify the
specific processes, activities, and tasks that must be performed to fulfill the requirements. ISO 20000-4:
Process Reference Model comprises one methodology for depicting the relationships, outcomes, purpose,
and context of the Service Management System.
The Defense Acquisition Management System (DAMS) and the Joint Capabilities Integration Development
System (JCIDS) both describe requirements, artifacts, and an acquisition/program management lifecycle for
Major Automated Information Systems (MAIS). One of the most useful tools within JCIDS is the
Department of Defense Architectural Framework (DoDAF). Comprising a set of viewpoints and models,
DoDAF provides specific guidance on describing operating and management environments as they are
designed, built, and operated throughout the lifecycle. The interaction of the Capability, Service, and
Operational viewpoints in DoDAF provide insight on how to integrate ITIL v3 Functions, ISO 20000 SMS
descriptions, and MAIS program of record requirements.
DESMF Edition 1.0
Page 33
9.0
Service Strategy Domain
The achievement of DISA's mission is dependent on all of the directorates aligning their respective
strategies to the strategic vision. This includes not only the strategy to achieve overall Agency service
capability, but strategies for each of the IT services. In fulfilling this objective, the Service Strategy Domain
has responsibility to determine business model(s) for the Agency, determine priority for service
implementation, manage the Service Portfolio, establish selection, prioritization criteria, arbitration,
supporting policies and procedures for the portfolio of services, and evaluate service requirements.
Figure 8.0 - Service Strategy Process Cross Reference Table
From:
Customer
Relationship
Management
Demand
Management
Financial
Management
(DM)
(FM)
Supplies CRM
with optimal
pricing options
Financial
impacts of
changing
mission
partner
requirements
Governance
(GOV)
Service Catalog
Management
Service Portfolio
Management
Strategy
Management
(SCM)
(SPM)
(SM)
(CRM)
To:
CRM
Compliance
requirements
related to
services
Usage of
services
Requested
services
Provide strategy
for new services,
information on
current services,
decisions to
discontinue
services
Provide mission
objectives.
Ensure
alignment of
resources and
capabilities.
Provide strategy
for new services,
information on
current services,
decisions to
discontinue
services
Ensures forum
for user
requirements.
Provide strategy
for new,
changed and
discontinued
services
Information
related to
Inadequate
funding
Available
services
DM
Identifies
mission
partner need
for usage.
Financial
impacts of
changing
mission
partner usage
variations
Feedback on
mission
partner
satisfaction
Usage of
services
Requested
services
Available
Information
related to
insufficient
capability
services
FM
Provides
number of
users of a
service.
Identifies
value of the
service
Provides
information on
demand of
new services or
changes to
existing
services
Demand
DESMF Edition 1.0
Define
controls for
spend/actual
for programs/
Projects
Usage of
services
Required funding
Define
Page 34
From:
Customer
Relationship
Management
Demand
Management
Financial
Management
(DM)
(FM)
Governance
(GOV)
Service Catalog
Management
Service Portfolio
Management
Strategy
Management
(SCM)
(SPM)
(SM)
(CRM)
Establish
boundaries for
cost
GOV
SCM
SPM
forecasts
auditing
requirements
Provides
conflict
resolution,
when
escalated.
Funding and
accounting
data.
Identifies
mission
partner
changing
landscape
Information
for
spend/actual
Provides
conflict
resolution,
when
escalated.
Funding and
accounting
data.
Identifies
mission
partner
changing
landscape
Information
for
spend/actual
Supplies
mission
partner
requirements
Identifies
mission
partner
changing
environment
Usage of
services
Financial
compliance
data
Cost of
services vs.
income/
appropriated
funds
Information as to
how strategic
objectives will be
achieved
Services
information
Information as to
how strategic
objectives will be
achieved
Requested
services
Available
services
Financial
compliance
data
Provides
information on
demand of
new services or
changes to
existing
services
Services
information
Determines
SPM mission
Usage of
services
Provide
decision for
SPM
Available
services
Identify
conflicting
priorities
Identifies the
correct set of
services in the
Service Portfolio
Ensures
resources for
service
portfolio
DESMF Edition 1.0
Page 35
From:
Customer
Relationship
Management
Demand
Management
Financial
Management
(DM)
(FM)
Governance
(GOV)
Service Catalog
Management
Service Portfolio
Management
Strategy
Management
(SCM)
(SPM)
(SM)
(CRM)
SM
Defines
strategic
relationships
with mission
partners
Information
from business
units for
strategy
decisions
Provides
measurement
and evaluation
information.
Cost of
services vs.
income/
Determine
parameters
under which
SM functions.
appropriated
funds
Demand
forecasts
Information
for resource
alignment
Provides
interpretation
of external
mandates
Identify
constraints of
services.
Information
related to service
investments
Identify
financial
constraints
9.1
Domain Metrics
The metrics for the Service Strategy Domain are meant to be actionable measures for decisions related to
improving the performance of the process and guiding resource allocation. They need to be viewed in an
overall context of the DESMF. As an example, a common metric for Financial Management is “Return on
Investment (ROI)”. This calculation usually stems from a comparison of reduced costs against a monetary
investment. For much of the process work, there may be no measurable cost reduction, but rather cost
avoidance and a decrease in the amount spent on unplanned work. For this, ROI may not be suitable or
actionable. Instead, actionable metrics need to be applied that measures that which is critical to the
services regarding Service Strategy Management.
DESMF Edition 1.0
Page 36
9.2
Strategy Management (SM) for IT Services
9.2.1 Goal
Strategy Management for IT Services is the process used to manage a ‘service’ strategy which is a subset of
the overall IT strategy and Agency strategy. This process defines and maintains an organizations
perspective and plans with regards to its services and the management of those services. It establishes the
mechanisms to decide which services are best suited to meet mission outcomes and the criteria to
effectively manage the services. This process ensures that the services strategy is defined and maintained
and meets mission objectives. The context for the difference between Service Strategy and the Service
Management Strategy:
Service Strategy – The strategy to define and execute services that meet the objectives of the mission
partners. For an IT service provider the service strategy is a subset of the IT strategy.
Service Management (ITSM) Strategy – The plan for implementing and executing the ‘processes’ used to
manage services identified in the Service Strategy. For an IT service provider, this strategy is a subset of the
Service Strategy described above.
9.2.2
Scope
The scope of Strategy Management for IT Services includes a specification of the ‘type’ of services to be
delivered and the mission partners that will receive the services. The strategy of an individual service is
defined in the Service Portfolio Management process. Also note that DoD and Agency level Strategic Plans,
as identified in Chapter 2, are important references/considerations to ensure appropriate scope.
9.2.3 Process Benefits and Expected Outcomes

Clear understanding that IT exists to fulfill the Agency mission

Assurance that IT resources are aligned with mission objectives

Ensure that the Service Owners have the right set of services in the Service Portfolio

Proactive instead of reactive response for demands placed by various stakeholders

Alignment of the mission partner perspective with the IT process framework

A documented understanding of the constraints, and mitigation of these constraints, with regards to
meeting mission partner requirements

A strategy that ensures priorities and resources are aligned in development of appropriate IT services
9.2.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 37
9.3
Customer Relationship Management (CRM)
9.3.1 Goal
The goal of Customer Relationship Management is to establish, maintain and grow affiliations by
understanding mission partner needs, meeting mission partner service needs, and ensuring that both DISA
and the mission partners have a clear understanding of the expectations, capabilities, and potential costs of
the services provided. In short, this process ensures that DISA views its services in a more mission partnercentric fashion.
9.3.2 Scope
The scope of CRM is all of the business outcomes related to mission partner engagement. This relationship
covers the entire lifecycle of the services offered from the agreement to create a service to the retirement
or decommissioning of a service. Also note that DoD and Agency level Strategic Plans, as identified in
Chapter 2, are important references/considerations to ensure appropriate scope.
9.3.3 Process Benefits and Expected Outcomes

A clear understanding of how to meet both the mission partner and mission needs

Facilitation of the communication with mission partners

Expedition of the cultural focus on mission partner satisfaction

Reduced breaches in Service Level Agreements

Measurable improvement in mission partner satisfaction levels

Decreased response time to mission partner inquiries resolution to mission partner concerns

Ability to respond to mission partner requests and to anticipate their needs through the greater
combined understanding of their goals with DISA capabilities

Increased trust between DISA and mission partners
9.3.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 38
9.4
Service Portfolio Management (SPM)
9.4.1 Goal
The goal of Service Portfolio Management is to position the IT organization as a strategic partner by
facilitating the creation of a wide offering of comprehensive, value-added services. It is involved with the
entire lifecycle of the services, from the time services are requested, until it is decided that they will be
discontinued and are decommissioned. Service Portfolio Management also ensures that DISA has the right
set of services to meet the mission at the appropriate cost level.
9.4.2
Scope
The scope of Service Portfolio Management is all of the IT related services offered to mission partners, both
internal and external. Also note that DoD and Agency level Strategic Plans, as identified in Chapter 2, are
important references/considerations to ensure appropriate scope.
These services can be in one of three phases:



Service Pipeline – Services being considered for investment or that have entered the Service Design
Domain or Service Transition Domain
Service Catalog – Services currently available to the mission partner base, normally considered to be in
the Service Operations Domain and candidates for Continual Service Improvement
Retired – Services that are no longer deployed and are unavailable to the mission partner
9.4.3 Process Benefits and Expected Outcomes

Identified relationship between IT assets and their associated costs into services

Improved productivity of IT staff through focus on those services that offer the most mission value

Cost efficiency through elimination of duplicative efforts related to managing services

Focus on managed services will increase efficiency in bringing new services to realization

Allocation of resources for changes and additions to the portfolio are mission based

The Service Portfolio should reflect mission partner expected outcomes

Risk assessment for creating services should be handled in a consistent, measured process

Services should be continually and consistently evaluated for their value to mission partners
9.4.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 39
DESMF Edition 1.0
Page 40
9.5
Service Catalog Management (SCM)
9.5.1 Goal
The primary goal of Service Catalog Management is to provide a single, definitive source of DISA’s service
offerings for mission partners. The information must be current and accurate. The Service Catalog itself
has relevant information about all live operational IT Services and those in transition and includes
information about deliverables, service levels, points of contact, ordering and service request processes. It
also provides information such as service definitions and support windows.
9.5.2
Scope
The scope of Service Catalog Management is to provide and maintain accurate information on all active
services and all that are being transitioned into production. These services may be represented
individually, or as packages defined in Service Strategy. Because of the possible packaging, the catalog
needs to show the relationships/dependencies of the services offered. Also note that DoD and Agency level
Strategic Plans, as identified in Chapter 2, are important references/considerations to ensure appropriate
scope.
9.5.3 Process Benefits and Expected Outcomes

A single source of information on services offered

Provides mission partners a “menu” of services, without concern for the supporting IT elements and
solutions

A process for maintaining the information for the services provided by DISA in a controlled fashion

IT services offered match mission partner requirements

There should be an automated interface to DISA’s service offerings

Mission partners should be offered solutions, not the elements to build a solution

Demand for services should be measured quantitatively, allowing for better resource alignment

Better prioritization of resources resulting in lowered costs and quicker delivery of services
9.5.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 41
9.6
Financial Management for IT Services (FM)
9.6.1 Goal
The goal of Financial Management for IT Services is to control budgeting, accounting, and chargeback for
the Agency services. From the IT standpoint, Financial Management needs to secure the funding to create
and maintain the enterprise architecture necessary to support the services that the Agency has strategically
determined it will provide, as determined in conjunction with Service Portfolio Management. Finally, FM
should provide transparency into the spending and cost recovery of the IT environment in providing
services.
9.6.2 Scope
Financial management for IT Services covers aspects of the three sub-processes associated with the overall
process: budgeting, accounting, and charging. This includes all aspects of assets and software licenses used
to provide the services, shared resources, overhead (general and administrative costs), capital and
operating expenses, contracted services, human resources, and facilities, both building and maintaining.
This includes both Defense Working Capital Fund (DWCF) and appropriated funds. Also note that DoD and
Agency level Strategic Plans, as identified in Chapter 2, are important references/considerations to ensure
appropriate scope.
9.6.3 Process Benefits and Expected Outcomes

Increased confidence in setting and managing budgets

Accurate cost information to support IT investment decisions

Accurate cost information for determining cost of ownership for ongoing services

More efficient use of IT resources throughout the organization

IT is understood in concepts of “Return on Value” (ROV) and ROI as related to services provided

Cost and spend are better understood by the IT staff

Investment decisions are made as part of the overall strategy

Controls demonstrating compliance to congressional mandates are recognized and built in during
strategy
9.6.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 42
DESMF Edition 1.0
Page 43
9.7
Demand Management (DM)
9.7.1 Goal
The primary goal of Demand Management is to assist in the understanding of the mission partner demand
for a particular service to plan early for provisioning of capacity and other aspects of support for the
service. This process can also help in influencing mission partner demand for services and seeks to
proactively understand the mission partner workload (demand) with the available resources (supply).
9.7.2
Scope
Demand Management process interacts with the mission partners in order to identify patterns of business
activities (PBA) and future IT demands, especially with regards to IT capacity. Also note that DoD and
Agency level Strategic Plans, as identified in Chapter 2, are important references/considerations to ensure
appropriate scope.
9.7.3 Process Benefits and Expected Outcomes

React more quickly to changing needs

Accurate cost information to support IT investment decisions

Accurate cost information for determining cost of ownership for ongoing services

Enables planning for a more efficient use of IT resources

Service demand is a key factor in prioritization of resources

PBAs are formally documented

Better understanding of PBA’s better defines the information required for Service Portfolio
Management

Contingency plans should be in place for demand variances
9.7.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 44
10.0 Service Design Domain
Service Design is about ensuring that services are designed to align and match the current and future
requirements of the Agency. Service Design as a Domain controls the planning and organizing of the
resources, infrastructure, communication, and physical and logical components of a service in order to
improve its quality and the interaction and understanding between DISA and its mission partners. This is
culminated in a comprehensive Service Design Package (SDP). The Domain needs to ensure that the goals
and objectives of Service Strategy are built and managed in line with the vision and mission of the Agency.
Service Design relies heavily on the Service Owners to understand the requirements, needs, and service
“behavior” of DISA’s mission partners. Service Design is accountable for changes to existing services,
creation of new services, and management of the removal of existing services. Service Design coordinates
closely with Service Operations to ensure that the data necessary for monitoring and responding to service
variances is built into every service.
Figure 9.0 - Service Design Process Cross Reference Table
From:
Service Level
Management
Availability
Management
Capacity
Management
(SLM)
(AvM)
(CapM)
Information
Security
Management
IT Service
Continuity
Management
(ISM)
(ITSCM)
Security
parameters for
services
Recovery plans
for all services
Design
Coordination
(DC)
To:
SLM
Availability
plan
Service
availability
metrics
Capacity Plan
Performance
statistics
Support for
OLAs
Overall security
management
policy
Standards and
practices
Analysis of
service outages
Service breach
data
AvM
Agreed
availability
levels
OLAs to support
availability
Available
capacity for
services and
components
Security test
schedules
Recovery
timelines
Standards and
practices
Risk analysis
Service Level
Requirements
(SLRs)
DESMF Edition 1.0
Page 45
From:
Service Level
Management
Availability
Management
Capacity
Management
(SLM)
(AvM)
(CapM)
Information
Security
Management
IT Service
Continuity
Management
Design
Coordination
(ISM)
(ITSCM)
Data security
classifications
and
requirements
Information as
for capacity
requirements for
services
Standards and
practices
Recovery plans
to incorporate
security failover
options.
Standards and
practices
(DC)
CapM
Agreed capacity
levels
SLRs
Availability
information
and
component
requirements
ISM
Agreed security
levels
Business
required
security levels
Data to allow
for security
upgrades and
patches
Requirements
for tuning
services,
requiring root
accesses
Test results of
security
Information for
auto responses
ITSCM
Agreed
continuity
levels
Business
required
continuity
levels
OLAs for
recovery
Recovery
requirements
for services
Current
capacity data
for services
Service and
component
availability
requirements
Projected
capacity data
for services
Security breach
failover
parameters
Standards and
practices
Assist in
service impact
risk
DC
SDP
requirements
SDP
requirements
SDP
requirements
SDP
requirements
SDP
requirements
10.1 Domain Metrics
The metrics for this Domain are meant to be actionable measures for decisions related to improving the
performance of the process and guiding resource allocation. They need to be viewed in an overall context
of the DESMF. As an example, a common metric for Availability Management is “% of time network is
DESMF Edition 1.0
Page 46
available”. This metric means nothing unless it is broken down and applied to service availability, and thus
provides no useful information for decision making. More correctly, actionable metrics need be applied
that measure that which is critical to DISA’s services regarding design management.
10.2 Service Level Management (SLM)
10.2.1
Goal
The goal of Service Level Management is to provide a framework where services are defined, service levels
to support business processes are agreed upon, Service Level Agreements (SLAs) and Operational Level
Agreements (OLAs) are developed to meet the agreements, and costs of services are developed. The
process should be designed to ensure that the partners in the agreements, the provider (DISA) and the
mission partner, understand each other’s drivers and requirements ensuring that they share responsibility
for the success of the service provision. SLM documents, negotiates, reports on and strives to improve
services.
10.2.2
Scope
The scope of Service Level Management is to represent the Agency to the mission partner and business and
to represent the mission partner and business to the Agency. This is true for all services. SLM is then
responsible for establishing the Service Level Agreements (SLAs) to document these understandings. Also
note that DoD and Agency level Strategic Plans, as identified in Chapter 2, are important
references/considerations to ensure appropriate scope.
10.2.3
Process Benefits and Expected Outcomes
The culture will establish a business-value, service-oriented attitude

Financial savings through improved service quality and better resource usage in resolving outages

Provider and mission partner will better understand each other’s responsibilities related to services

A mutually beneficial relationship will be developed between provider and mission partner to deliver
services that are relevant, thus improving mission partner satisfaction

Improved planning by basing commitments on user agreements

Improved management through a focus on service delivery

IT focus will be on business goals

Services will be continually and consistently measured both quantitatively and qualitatively
DESMF Edition 1.0
Page 47
10.2.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 48
10.3 Availability Management (AvM)
10.3.1
Goal
The Availability Management process ensures that the level of availability delivered in all IT services meets
the availability needs or agreed service level targets in a cost effective manner. The goal of Availability
Management, as described in ITIL, is to optimize the capability of the IT Infrastructure and supporting
organization to deliver a cost effective and sustained level of availability that enables the business to satisfy
its business objectives, and to meet or exceed availability requirements as defined in the SLAs.
10.3.2
Scope
The scope of the Availability Management process covers the design, implementation, measurement,
management and improvement of IT service and supporting infrastructure availability. Availability
Management needs to understand the service and supporting infrastructure availability requirements from
SLAs. Also note that DoD and Agency level Strategic Plans, as identified in Chapter 2, are important
references/considerations to ensure appropriate scope.
10.3.3
Process Benefits and Expected Outcomes

Ensure that there is an Availability Plan that matches business goals and agreements

Resources are better utilized as services are placed on infrastructure based on availability requirements

The Availability Plan will help identify service availability issues prior to outages

Mission partner satisfaction rises as availability increases and incidents decrease

SLAs are met, with regard to uptime and availability

There is a quantitative approach and plan to addressing availability


IT services are initially designed and engineered to meet availability requirements
Issues with availability are viewed holistically, not service by service

Frequency and duration of service interruptions are reduced over time

SLAs are written with achievable availability goals
10.3.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 49
DESMF Edition 1.0
Page 50
10.4 Capacity Management (CapM)
10.4.1
Goal
The goal of Capacity Management is to ensure that IT capacity meets current and future business
requirements in a cost-effective and timely manner. Capacity Management ensures that proactive
measures to improve IT service performance are implemented wherever it is cost justifiable. Capacity
Management must maintain a balance between cost and capacity, between supply and demand and
ensures that agreed performance service levels are met.
10.4.2
Scope
The scope of the Capacity Management includes almost all configuration items. Also note that DoD and
Agency level Strategic Plans, as identified in Chapter 2, are important references/considerations to ensure
appropriate scope.
The following resources are taken into consideration within the process:
- Computer hardware, network resources
- Software
- People
- Other environment resources like warming/cooling equipment, furniture for staff Basically, anything that
is a contributing factor to the performance of the services.
10.4.3
Process Benefits and Expected Outcomes

Uninterrupted availability and performance levels during peak periods

Unnecessary expenses caused by "last minute" purchases or re-allocation of resources are avoided

Proactive management of capacity reduces performance and capacity related incidents

Mature Capacity Management is essential to cloud computing

Business and IT alignment, focusing greater attention and resources in business-critical services

Infrastructure growth is planned to meet business needs



Reduction to overall risk of running the production environment
Limited over-capacity
Overall infrastructure budget is spent more effectively
10.4.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 51
10.5 IT Service Continuity Management (ITSCM)
10.5.1
Goal
ITSCM addresses IT services that support critical business processes. It identifies risks and minimizes the
impact of service disruptions. The goal for ITSCM is to support overall business continuity by ensuring that
the required IT technical and services facilities can be recovered within required, and agreed, business
timescales, and to provide agreed upon levels of service in exceptional circumstances. ITSCM is the
technical component of the overall Business Continuity Plan (BCP). ITSCM is both proactive in supporting
the plan in avoiding disaster situations and reactive in executing the plan after major events.
10.5.2
Scope
The scope of the ITSCM includes all of the vital business functions and any other business services that
cause a regulatory compliance breach, and services deemed important that cannot be supported through
the Incident Management process. Also note that DoD and Agency level Strategic Plans, as identified in
Chapter 2, are important references/considerations to ensure appropriate scope.
ITSCM is primarily concerned with the Configuration Items (CIs) that support these services. This includes:





IT components
Documentation
Facilities
Communications
Human resources
Basically, anything that is a contributing factor to the performance of the identified services.
10.5.3
Process Benefits and Expected Outcomes

Controlled recovery of systems

Better understand the weaknesses that can affect the mission, and address them before a disaster
occurs

Prioritization of services allow for better utilization of resources during recovery

Tested plans reduce downtime in the event of a disaster

Confidence that the mission can be fulfilled under less than ideal conditions

Identification of critical services and functions

The ITSCM Plan will set procedures that are regularly tested and updated to prevent, deal with and
recover from major disruptions and loss of critical services for extended periods


Reduction to overall risk of failures in the production environment
Mission partner confidence in ability to provide support in a crisis
DESMF Edition 1.0
Page 52
10.5.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
10.6 Information Security Management (ISM)
10.6.1
Goal
The goal of Information Security Management is to realize the security requirements defined in the Service
Level Agreement (SLA) and other external requirements which are specified in legislation (such as FISMA)
and other policies as defined in Service Strategy. Information Security Management must align IT security
with business security and ensure that information security is effectively managed for all services. This is
done by preserving the confidentiality, integrity, and accessibility of the data transported over DISA’s
network. These terms mean:



Confidentiality: information must only be accessible to its predefined recipients
Integrity: the information must be correct and complete
Availability: information must be accessible when it is needed
10.6.2
Scope
The scope of ISM includes all the use (and misuse) of all IT systems that support DISA’s mission and services
Also note that DoD and Agency level Strategic Plans, as identified in Chapter 2, are important
references/considerations to ensure appropriate scope.
ISM s is done from four aspects:




Personal – Define security policies as related to human resources and staff awareness and
responsibilities related to security
Procedural – Procedures to control security that flow from the security policy and process
Facilities – Controls used to protect any physical sites against security incidents
Technical – Controls used to protect the IT infrastructure against security incidents
10.6.3
Process Benefits and Expected Outcomes

Security awareness is heightened in all Agency personnel




Both assets and processes are more productive
Data provided to serve the Warfighter is protected, accurate, and available when needed
Effective access to information by authorized personnel
Proactive management identifying potential security vulnerabilities before they cause a security-related
incident

All information exchanges can be trusted

In conjunction with Incident Management, incidents are detected and managed in a controlled fashion
DESMF Edition 1.0
Page 53
10.6.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 54
10.7 Design Coordination (DC)
10.7.1
Goal
The goal for Design Coordination is to ensure the consistent and effective design of new or changed IT
services and that all service design objectives are met by providing a single point of contact for the efforts
in this lifecycle stage.
10.7.2
Scope
Design Coordination includes all new or changed services that enter the design phase. This is primarily as
part of a project, and requires coordination with the Transition Planning and Support counterpart. Also
note that DoD and Agency level Strategic Plans, as identified in Chapter 2, are important
references/considerations to ensure appropriate scope.
10.7.3
Process Benefits and Expected Outcomes

Reduced costs associated with reworking design issues

Accountable individual for the Service Design Package (SDP)

Ensured architectural consistency

Consistent design approach and coordination of all design activities

Ensures all service models and service solution designs conform to security policies

Reusable design practice
10.7.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 55
11.0 Service Transition Domain
The Service Transition Domain holds the responsibility of assisting in the navigation of the design of services
as they move from concept to production, implementing services, and making modifications to services as a
result of required corrective actions or to improve an existing service. As such, it is the responsibility in this
Domain to ensure that the strategic vision of DISA which guided the creation of the services in Service
Design is carried out during the implementation phases. The Domain Owner serves as the guardian of the
production environment, ensuring that the policies and processes designed and executed in the Domain
mitigate the risks of changing the production environment through analysis and testing, proper scheduling
of the modifications, recording of all aspects of the assets that support the services, and ensuring that the
knowledge of the services provided is properly available to the Agency.
Figure 10.0 - Service Transition Process Cross Reference Table
From:
Knowledge
Management (KM)
Asset
Management (AM)
Configuration
Management
(CfM)
Change
Evaluation
(Eval)
Service
Validation and
Testing (SVT)
Release &
Deployment
Management
(RDM)
Transition
Planning and
Support (TPS)
Release plans
Artifacts from
projects
Change
Management
(ChM)
Supplier
Management
Policy and
process
documents
Supplier
(Sup)
To:
KM
Description
of Assets
Description of
all CI’s
Post –
implementation results
Test plans
Test results
Policy and
process
documents
Policy and
process
documents
Policy and
process
documents
Policy and
process
documents
Policy and
process
documents
Policy and
process
documents
performance
Policy and
process
documents
AM
Access to
various
federated
databases
related to
KM and
CfM
DESMF Edition 1.0
Descriptions
of all CI’s
Post –
implementation results
Test results
Release plans
Overall planning
for the service
change
Changes to
environment
May
provide
assets
Planned
changes
Contract
information
Page 56
From:
Knowledge
Management (KM)
Asset
Management (AM)
Configuration
Management
(CfM)
Change
Evaluation
(Eval)
Service
Validation and
Testing (SVT)
Release &
Deployment
Management
(RDM)
Transition
Planning and
Support (TPS)
Change
Management
(ChM)
Supplier
Management
Changed status
of CIs
Status of CIs
during transition
phase
Changes to
environment
May
provide CIs
Release
schedules for
approved
changes
Changes to
CMS
(Sup)
CfM
Access to
various
federated
databases
related to
KM and
CfM
Description
of Assets
Service
related
information
after releases
Service related
information
after initial
testing
Contract
CI details
Planned
changes
Eval
Expected
test results
Previous
results of
the service
evaluation
Assets
related to
the service
requiring
evaluation
CIs related to
the service
requiring
evaluation
Test results of
install
Scope of
service change
Expectations
from release
management
Identification of
release package
to be evaluated
SDP
Intended
effect of
the change
acceptance
criteria
Risk evaluation
SVT
Feedback
on new
security
accesses
Asset
information
CI information
for testing
Verification
and feedback
for testing
Verification and
feedback for
testing
Oversees SVT
Provides SDP for
testing
Change
information
Coordinate
move to
production
after SVT
Identifies
approved
CI changes
RDM
Requirements for
releases
Policies
related to
releases
DESMF Edition 1.0
Asset
information
Provide CI
information
for release
Validation of
the functional
aspects of the
release
Method for
implementation
Overall planning
for the service
change
Logical
approval
and expectations of
the change
Expected
results
Page 57
information
From:
Knowledge
Management (KM)
Asset
Management (AM)
Configuration
Management
(CfM)
Change
Evaluation
(Eval)
Service
Validation and
Testing (SVT)
Release &
Deployment
Management
(RDM)
Transition
Planning and
Support (TPS)
Change
Management
(ChM)
Supplier
Management
(Sup)
TPS
Supporting
data
Asset
information
Provide CI
information
Validation of
the functional
aspects of the
release
Validation of
the testing
aspects of the
release
Validation of
the entire
process
Validation of
the change
management
process
Control point to
planned
releases and
changes
Physical
implementatio
n of the change
Approval
for all
aspects of
the project
Information
for impact and
risk analysis
ChM
Documenta
tion related
to the
service
affected by
the project
Asset
information
Impact
analysis
data
Sup
CI Attributes
CI data
Oversight into
the changes
Accountability
for the changes
Information
for impact
analysis
Information as
needed
11.1 Domain Metrics
The metrics for this Domain are meant to be actionable measures for decisions related to improving the
performance of the process and guiding resource allocation. They need to be viewed in an overall context
of the DESMF. As an example, a common metric for change management is “# of incidents caused by
changes”. This number often goes up if testing is done poorly, if release documentation is not well
publicized or if there are failures in the design package. More correctly, actionable metrics need be applied
that measure that which is critical to DISA’s services regarding transition.
DESMF Edition 1.0
Page 58
DESMF Edition 1.0
Page 59
11.2 Change Management (ChM)
11.2.1
Goal
Change Management is to ensure that any modification to the IT environment, whether it involves an
addition, maintenance, or deletion of a service or service component is in line with the overall mission
strategy. Per ITIL®, this process is to ensure that standardized methods and procedures are used for
efficient and prompt handling of technical changes, in order to minimize the impact of change-related
incidents upon service quality, and to improve the day-to-day operations of the organization.
11.2.2
Scope
The scope is any asset or configuration item (CI) that supports a service provided by DISA, either internally
or externally. Thus, Change Management is responsible for managing change process involving hardware
(all infrastructure), software and all documentation associated with running, supporting and maintenance
of production systems. Also note that DoD and Agency level Strategic Plans, as identified in Chapter 2, are
important references/considerations to ensure appropriate scope.
11.2.3
Process Benefits and Expected Outcomes

Consistent tracking and scheduling of modifications to CIs and their documentation: Change
Management processes ensure that DISA receives all documentation related to services in a timely
fashion, ensuring that mission partner interfaces are maintained at a highly supportive level.

Early identification of risk: Part of the process should include the submission of a risk analysis with
every major change. This allows DISA to act in a more proactive manner, and mitigate risks in a manner
which causes the least impact to mission partner service.







Prioritizing and responding to business and mission partner change proposals
Implementing changes that meet mission partner agreed service requirements while optimizing costs
Contributing to meet governance, legal, contractual and regulatory requirements
Reducing failed changes and therefore service disruption, defects and re-work
Tracking changes through the service lifecycle
Aiding productivity of staff through minimizing disruptions due to high levels of unplanned or
‘emergency’ change and hence maximizing service availability
Reducing the Mean Time to Restore Service (MTRS), via quicker and more successful implementations
of corrective changes
Reduce the risk associated with introducing change to the environment

Reduction in unplanned work due to reduction in incidents caused by change

Increased number of standard changes, allowing for more efficient and timely implementations

Mission partners will have transparency, where security is not an issue, into the status of changes

DESMF Edition 1.0
Page 60
11.2.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
11.3 Change Evaluation (Eval)
11.3.1
Goal
Change Evaluation is a formal evaluation process that should be utilized when significant changes are to be
executed. The organization determines the threshold of changes which should invoke this process. The
goal of Change Evaluation is to provide accurate information to the Change Management process as to the
impact and effect the change may have on service capability prior to the change being accepted.
11.3.2
Scope
The scope of the changes that should be formally evaluated is determined by the organization. As a
guideline, this can include any change that introduces a new service, causes a substantial change to an
existing service, or retires a service. It may also be determined by impact, or a project that impacts
support, such as a reorganization or Service Desk consolidation. Resources, in time, equipment or money,
may also be a consideration. When the Change Evaluation process ends, the Change Management process
takes responsibility for further change activities. Also note that DoD and Agency level Strategic Plans, as
identified in Chapter 2, are important references/considerations to ensure appropriate scope.
11.3.3
Process Benefits and Expected Outcomes

Additional focus and governance of significant changes

Proper command and control of major changes



Multiple risk analysis with each significant change
Better allocation of resources
Significant changes may undergo multiple risk analysis as they move through the change lifecycle

All factors will be considered prior to making a major change, including Agency capability, tolerance for
risk, organizational structure, resources, modeling, people, and all other projects and changes

Major changes will be viewed through service filters, not simply as IT projects

Transparency into the status of major changes, where security is not an issue
11.3.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 61
DESMF Edition 1.0
Page 62
11.4 Asset Management (AM)
11.4.1
Goal
The goal of Asset Management is to manage the finances, contracts and usage of IT assets throughout their
lifecycles in order to balance service requirements, total costs, budgeting, and compliance. This lifecycle
ranges from procurement to deployment to use (and upgrades) to decommissioning (or reuse) to disposal.
In an environment such as DISA, where asset management is treated differently than Configuration
Management, the Asset Management database becomes part of the Configuration Management System.
As such, the relationship of assets to services is covered under Configuration Management.
11.4.2
Scope
The scope is any physical or software asset that supports a service provided by DISA, either internally or
externally. Also note that DoD and Agency level Strategic Plans, as identified in Chapter 2, are important
references/considerations to ensure appropriate scope.
Asset management is responsible for managing:



11.4.3
Hardware (including maintenance)
Software (including maintenance)
Facilities (and related, such as desks, etc.)
Process Benefits and Expected Outcomes

Creates improved procurement processes through centralization of all assets and asset related
financial information

Simplifies inventory and auditing processes through centralization of all assets and asset related
financial information


More accurate risk assessments due to better financial tracking
Understanding of the real cost of assets

Single database to record financial information for inventory

Valid information for risk assessments involving assets

Increased insight into the Total Cost of Ownership of the IT services by providing complete and detailed
asset information
11.4.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 63
DESMF Edition 1.0
Page 64
11.5 Configuration Management (CfM)
11.5.1
Goal
The goal of Configuration Management (CfM) is the control, identification, recording, and reporting of IT
components, including their versions, constituent components, states and relationships to other IT
components and their relationships to services. Items that should be under the control of Configuration
Management include hardware, software, systems, services, and associated documentation.
11.5.2
Scope
The scope is any asset that supports a service provided by DISA, either internally or externally. Also note
that DoD and Agency level Strategic Plans, as identified in Chapter 2, are important
references/considerations to ensure appropriate scope.
Thus, Configuration Management is responsible for controlling:
 Hardware

Software (including licenses)



Facilities
Documentation (including SLAs)
Entries from other processes (changes, incidents, etc.)
11.5.3
Process Benefits and Expected Outcomes

Accurate information on CIs and their documentation: This information supports all other Service
Management processes, such as Release Management, Change Management, Incident Management,
Problem Management, Capacity Management, and any necessary contingency planning. Configuration
Management can provide information for upgrade planning and replacements.

Facilitates adherence to legal obligations: Configuration Management maintains an inventory of all
software and hardware within an IT infrastructure.

Improves security by controlling the versions of CIs in use: This makes it more difficult for these CIs to
be changed accidentally, maliciously, or for erroneous versions to be added.
Allows the organization to perform impact analysis and schedule changes safely, efficiently, and
effectively: This reduces the risk of changes affecting the live environment.


Unified view into Asset, Configuration, Change, and Incident Management

Better risk assessment for approving changes

Better Incident Management, since failing components are traceable to services
11.5.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 65
DESMF Edition 1.0
Page 66
11.6 Knowledge Management (KM)
11.6.1
Goal
The goal of Knowledge Management is to improve DISA’s ability to execute its core processes more
efficiently by ensuring that the right people have the right knowledge, at the right time to deliver and
support the services as defined by DISA’s mission. This delivers:

more efficient services with improved quality

clear and common understanding of the value provided by services

relevant information that is always available
11.6.2
Scope
The scope is information required for making decisions throughout the service lifecycle, with the exception
of the data controlled by the Configuration Management process. Also note that DoD and Agency level
Strategic Plans, as identified in Chapter 2, are important references/considerations to ensure appropriate
scope.
11.6.3
Process Benefits and Expected Outcomes




Improved efficiency through reducing the need to rediscover knowledge
Reduced incident and problem solving time through sharing of workarounds and previous resolutions
Reduced design time through sharing of information related to current and past design projects
Better strategic decisions based on captured and categorized knowledge, rather than institutional
memory

Improved decision making across the board, based on common knowledge

Improved project management

Gain overall efficiency through reuse of previous plans, documents, etc.

Better sharing of internal best practices
11.6.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 67
11.7 Release and Deployment Management (RDM)
11.7.1
Goal
The goal of Release and Deployment Management is to ensure that the integrity of the live environment is
protected and that the correct components are released. This must be in a time frame that meets both the
mission partner’s service needs and does not cause a SLA breach. The deployment must provide value to
the mission partner and be supported until such time as operations can effectively provide support. To
accomplish this goal, Release and Deployment Management is responsible for planning the rollout of
software and hardware changes, designing and implementing procedures for the distribution and
installation of changes to IT systems, and, in conjunction with the service manager, communicating and
managing expectations of the mission partner during the planning and rollout.
11.7.2
Scope
As defined in ITIL v3 2011 ® the scope of Release and Deployment Management includes the processes,
systems and functions to package, build, test and deploy a release into live use, establish the service
specified in the Service Design Package, and formally hand the service over to Service Operations. The
scope includes all configuration items required to implement a release. Also note that DoD and Agency
level Strategic Plans, as identified in Chapter 2, are important references/considerations to ensure
appropriate scope.
11.7.3




Process Benefits and Expected Outcomes
Minimized disruption of service to the mission partner, due to synchronization of Releases involving
hardware and software components from different platforms and environments
Releases are performed with a business/service purpose
Early life support becomes part of the process
Effectively communicate and manage expectations of the mission partner during the planning and
rollout of new releases



Reduction in errors through the controlled release of hardware and software to the live environment
Enhanced use of resources because of combined efforts when testing new releases
Overall reduction in configuration variance

Reduction in unplanned work due to better control of releases
11.7.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 68
11.8 Service Validation and Testing (SVT)
11.8.1
Goal
Service Validation and Testing is to provide evidence that the new/changed service meets the mission
partner and mission requirements, including any documented SLAs, thus limiting risk as changes are
introduced into the production environment.
The service is tested explicitly against all parameters in the service design package, including functionality,
availability, continuity, security, usability and regression testing.
11.8.2
Scope
The scope of Service Validation and Testing is all approved releases, and those components as defined in
Release and Deployment Management. The scope includes all configuration items required to implement a
release, and the congruent and tangent systems that make up the production environment. Also note that
DoD and Agency level Strategic Plans, as identified in Chapter 2, are important references/considerations to
ensure appropriate scope.
11.8.3
Process Benefits and Expected Outcomes




Ensures that releases meet the criteria for both utility and warranty
Mission partner confidence on the success of releases
Testing is done from an overall service perspective, not just component or system
Reduction in mission partner resources to test releases



A structured validation and test process that provides evidence that the new or changed service
supports the mission requirements as set in service strategy
Ensures that mission partner requirements are met as set forth in the Service Design Package
Overall reduction in incidents

Higher mission partner satisfaction
11.8.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 69
11.9 Transition Planning and Support (TPS)
11.9.1
Goal
The goal of Transition Planning and Support is to plan and coordinate the resources to take a new or
changed service or service to be decommissioned from the decision of Service Portfolio Management
through Release and Deployment into the production environment, ensuring that the effort is
accomplished within predicted cost, quality, time estimates, and acceptable levels of risk. In addition, this
process has the goal of meeting all requirements in the Service Design Package.
11.9.2
Scope
The scope of Transition Planning and Support is all projects defined by Service Strategy which require either
a significant change to an existing service, the implementation of a new service, or the removal of an
existing service. Also note that DoD and Agency level Strategic Plans, as identified in Chapter 2, are
important references/considerations to ensure appropriate scope.
11.9.3
Process Benefits and Expected Outcomes







Ensures integrity of all mission partner and service assets
Coordinate activities across projects, suppliers and service teams
Single point of communication related to service activities in scope
Reduction in variation from requirements to production
Ability to deliver more volumes of change at higher success rates
Reduced variation in release schedule adherence due to standardized, holistic planning
Improved integration of services with the mission partner’s needs



Consolidated deployment process
Better planning and resource allocation
Improved risk management, and thus reduced adverse impact due to increased predictability of quality
of service

Better integration of supporting processes
11.9.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 70
11.10 Supplier Management (Sup)
11.10.1
Goal
The goal of Supplier Management is to ensure that the prime suppliers and the services provided are
managed to support DISA’s mission and IT service targets. Objectives include:


Obtain maximum value for the money spent on suppliers
Ensure that the contracts are aligned with Agency strategy and support the various aspects of
Service Level Management
11.10.2
Scope
The scope of Supplier Management takes into account the management of all suppliers and their contracts
in relation to services offered to DISA and, in limited instances for the underpinning contracts that support
services provided by DISA. In all situations, the Federal Acquisition Regulation/Department of Defense
Federal Acquisition Regulation Supplement (FAR/DFARS) will take precedence. Note that limited instances
exist where DISA could manage below the prime contractor level. Limited instances would include costtype contracts for non-commercial items. Also note that DoD and Agency level Strategic Plans, as identified
in Chapter 2, are important references/considerations to ensure appropriate scope.
The scope includes:

Implementation and enforcement of a supplier policy

Maintenance of a Supplier and Contract Database (SCD)

Supplier and contract categorization and risk assessment

Supplier and contract evaluation and selection

Development, negotiation, and agreement of contracts

Contract review, renewal, and termination

Management of suppliers, supplier performance and contractual dispute resolution

Agreement and implementation of service and supplier improvement plans

Maintenance of standard contracts, terms and conditions
11.10.3
Process Benefits and Expected Outcomes

Ensures that underpinning contracts and agreements with suppliers support and align with mission
needs, Service Level Requirements (SLRs), and Service Level Agreements (SLAs)

Obtain maximum value for supplier services

Manage relationships with suppliers

Measured supplier performance
DESMF Edition 1.0
Page 71

Creation and management of supplier and contract information
11.10.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
12.0 Service Operations Domain
The Service Operations Domain controls the full range of matters pertaining to sustaining assured
information delivery, assured system and network availability, and assured information protection for
information technology (IT) capabilities that support the provided services. The Domain Owner serves
as the approval authority to introduce new initiatives, ensures standards-based configuration and
operation of all infrastructure, controls the runtime aspects of services making sure that services are
behaving correctly and within SLAs, administers and controls security policies, identifies incidents and
infrastructure issues, performs problem resolution, and implements metrics that track the overall
progress of the operations Domain. The Domain Owner is also responsible for ensuring that processes
that support the services are executed in a cost-effective manner. As such, these processes need to
have both an internal as well as a mission partner focus. It is within this Domain that the mission
partner determines the ongoing value extended by the Agency. There are two key definitions whose
difference is more prominent in the operations Domain than the other Domains:
Function: A team or group of people and the tools they use to carry out one or more processes or
activities.
Process: A structured set of Activities designed to accomplish a specific objective.
This difference is notable, since in addition to processes, the Service Operations Domain has several
functions (Service Desk, Applications Management, Technical Management, and IT Operations
Management). These functions are described in the Functions section of this document.
Figure 11.0 Service Operations Process Cross Reference Table
From:
Event Management
(EM)
Incident Management
(IM)
Problem
Management (PM)
Access
Management
(AcM)
Feedback on EM
incident triggers
Corrective actions for
EM triggers
Notification of
new Accesses for
security triggers
Feedback on required
Feedback on EM
To:
Request Fulfillment (RF)
EM
DESMF Edition 1.0
Provides information
about changes to CI’s
Page 72
From:
Event Management
(EM)
Incident Management
(IM)
events for monitoring
Problem
Management (PM)
reports related to
PM
Access
Management
(AcM)
Problem data, status
and Workarounds
Notification of
new Accesses for
security events
Request Fulfillment (RF)
IM
Incident data
Relationship of RFC to
incident (if applicable)
User information
Know error data
Escalated incidents to
proper groups
Documentation and
procedures for
diagnosis
Method to
resolve security
events
Automated solutions
triggered
Reports on major
problem review
PM
Feedback on
workarounds
Information related to
repeated events
Create links to problem
records
Create new problem
records
Incidents matched to
problems or known
errors
Notification of
new Accesses for
security events
Unmatched Incidents
details
Method to
resolve security
events
Relationship of RFC to
problem (if applicable)
Major incidents
Resolution details
Feedback on
workarounds,
temporary solutions
Impact, urgency and
priority of changes to
correct known errors
Errors that can be
analyzed for recurring
issues (problems)
DESMF Edition 1.0
Page 73
From:
Event Management
(EM)
Incident Management
(IM)
Problem
Management (PM)
Feedback on new
security accesses
Notification of
incidents caused by
access issues
Feedback from
problem resolved
related to security
incidents
Events that indicate an
incident has occurred
associated with
fulfillment of a request
Incidents that
occurred during the
fulfillment of a request
Problems caused by
request
AcM
Access
Management
(AcM)
Request Fulfillment (RF)
RFC access inquiry
RF
Access
information for
RFC
12.1 Domain Metrics
The metrics for this Domain are meant to be actionable measures for decisions related to improving the
performance of the process and guiding resource allocation. They need to be viewed in context of an
overall context of the DESMF. As an example, a common metric for Incident Management is “% of first call
resolution”. This number often goes up if incidents are repeated and the same workaround can be applied
a number of times. If Problem management supplies a permanent fix for the root cause of the incidents,
and change management chooses to apply it, these incidents no longer occur, reducing the % of first call
resolution. More correctly, metrics need be applied that measure that which is critical to DISA regarding
Incident Management.
12.2 Incident Management (IM)
12.2.1
Goal
The goal of Incident Management is to restore normal service operation as quickly as possible and
minimize the adverse impact on mission partner operations, thus ensuring that the best possible levels of
service quality and availability are maintained.
12.2.2
Scope
The scope is any disruption or potential disruption of service. The process must allow for three different
paths: Normal, Major, and Security related. Defining a major incident is an important aspect of Incident
Management process definition. There needs to be a separate sub-process for those incidents that have
the highest impacts and are most disruptive to the affected service components. Additionally, there needs
to be a separate sub-process for security incidents, since these have different reporting criteria and may or
may not adversely affect any service. All other incidents should be considered normal. Also note that DoD
and Agency level Strategic Plans, as identified in Chapter 2, are important references/considerations to
ensure appropriate scope.
DESMF Edition 1.0
Page 74
12.2.3
Process Benefits and Expected Outcomes

Ability to detect and resolve incidents more efficiently, which results in higher availability of the service
to the mission partner.

Ability to align IT activity to real-time business priorities. Incident Management includes the capability
to identify mission partner priorities and dynamically allocate resources as necessary.

Identification of potential improvements to services. This happens as a result of understanding what
constitutes an incident and from being in contact with the activities of business operational staff.

During the handling of incidents, the identification of additional service or training requirements

Improved information flow to mission partners regarding service restoration

Basis of information for Problem Management. With standard recording techniques, there is better
management of resources for problem resolution.

A consistent flow for IM based on mission, policy, and process

A single Incident Management process for use across the Agency

Better focus on restoring service as opposed to just performing root cause analysis

A searchable base of incidents and workarounds to better resolve service outages

A standard method of prioritization and categorization of incidents

Incident models to allow for more efficient resolution of incidents

Mission partners will have transparency, where security is not an issue, into the status of incident
resolution
12.2.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 75
12.3 Problem Management (PM)
12.3.1
Goal
The goals of Problem Management are to prevent problems and resulting incidents from happening, to
eliminate recurring incidents and to minimize the impact of incidents that cannot be prevented. Problem
Management includes the activities required to diagnose the root cause of incidents and to determine the
resolution to those problems, to provide workarounds to Incident Management, and to spearhead the
Major Incident process.
12.3.2
Scope
Problem Management includes the activities required to diagnose the root cause of Incidents and to
determine the resolution to those problems. Problem Management will also maintain information about
problems and appropriate workarounds/resolutions, in order to reduce the number and impact of incidents
over time. In this respect, Problem Management has a strong interface with Knowledge Management, and
tools such as the Known Error Database (KEDB) should be used for both. Although Incident Management
and Problem Management are separate processes, they are closely related and typically use the same tools,
have similar categorizations, impact and priority coding systems. This ensures effective communication
when dealing with incidents and problems that are related. It is also responsible for ensuring that the
resolution is implemented through appropriate control procedures, especially Change Management and
Release and Deployment Management. Also note that DoD and Agency level Strategic Plans, as identified
in Chapter 2, are important references/considerations to ensure appropriate scope.
12.3.3









Process Benefits and Expected Outcomes
Higher availability of IT services
Higher productivity of business and IT staff
Reduced expenditure on workarounds or fixes that do not work
Reduction in cost of effort in fire-fighting or resolving repeat incidents
Reduces the chance of having to invoke the business continuity plan
A Known Error Database (KEDB) will reduce time to resolution and allow learning from historical data
A structured process based on prioritization schemes to allocate resources for solving problems
Ability to distinguish between restoring service (IM) and root cause analysis (PM) which will create
higher availability of services
Better integration of supporting processes
12.3.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 76
12.4 Request Fulfillment (RF)
12.4.1
Goal
The goal of Request Fulfillment is to ensure that fulfillment of a service request is expedient, consistent,
and effective, occurs in a repeatable fashion, and is accomplished with standardized services (those that
have been pre-approved by Change Management). Request Fulfillment is responsible for the entire lifecycle
of the request.
12.4.2
Scope
Request Fulfillment includes any instance when a mission partner, either by direct communication or by an
automated menu system, requests the Service Desk to either fulfill a request that has been supported by a
standard change, or is of such low impact as to not require approval. These low impact requests include
mission partners asking questions, providing comments and making complaints, or, in conjunction with
Access Management, providing security access. Also note that DoD and Agency level Strategic Plans, as
identified in Chapter 2, are important references/considerations to ensure appropriate scope.
12.4.3

Process Benefits and Expected Outcomes





Increased mission partner satisfaction through quicker fulfillment by separating request fulfillment
from release and deployment
Higher productivity of business and IT staff
Service improvement through repeatable and measured fulfillment
Better staff utilization by separating request fulfillment from release and deploy
The Service Desk will better prioritize requests by separating incidents from service requests
Mission partners will have quick and easy access to standard services

Standard process for financial approvals of standard services requests
12.4.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 77
12.5 Event Management (EM)
12.5.1
Goal
The goal of Event Management is to monitor, filter, and notify of actions and occurrences that have an
effect on the services that DISA provides in fulfilling its mission. The goals are both proactive and reactive.
Proactively, the goal is to notify operations of those events that may cause service degradation and outages
enabling operations to take steps necessary to avert any SLA breach. Reactively, Event Management
interfaces with operations and Incident Management to provide information and corrective actions for
these events.
12.5.2
Scope
Event Management includes occurrence or action that affects the ability to provide services. These may be
related to: security, performance of CIs, component failure, facilities, capacity, or issues related to
compliance and contracts or licensing. Tool sets should be pre-engineered to support automated
monitoring and responses to events, including pre-populating an alarm event. Also note that DoD and
Agency level Strategic Plans, as identified in Chapter 2, are important references/considerations to ensure
appropriate scope.
12.5.3








Process Benefits and Expected Outcomes
Decreased labor costs due to automated responses to events
Higher productivity staff through reduction of monitoring non-consequential events
Ability to preclude incidents, increasing availability of services
Quicker return to service due to notification coming from the source of the event
Have a basis for automated operations
There should be standardization in event notification, enabling better responses from operations
Monitoring of IT should be service and mission focused
Reduction in the TCO for monitoring resources
12.5.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 78
12.6 Access Management (AcM)
12.6.1
Goal
The goal of Access Management is to enable users to use a service or group of services while protecting
against unauthorized access, and to control the execution of policies and actions defined in Information
Security Management. This includes levels of access to the service catalog for requesting services, access to
data, and access to facilities.
12.6.2
Scope
The scope of Access Management is the enforcement of all policies set forth in Service Strategy and
Information Security Management. Also note that DoD and Agency level Strategic Plans, as identified in
Chapter 2, are important references/considerations to ensure appropriate scope.
12.6.3




Process Benefits and Expected Outcomes



Decreased labor costs due to automated responses to events
Access to services is aligned with strategy
Data is protected from accidental and intentional attempts
It is more controlled when access needs to be revoked, such as job changes, retirements, and
discontinuation of services
Employees have the right access to perform their jobs
Access to data and services is controlled
Consistent enforcement of service, data, and facilities access

Processes should be in place to demonstrate compliance with DoD and other outside policies
12.6.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 79
13.0 Continual Service Improvement (CSI) Domain
While the achievement of DISA's mission is dependent on all of the directorates aligning their respective
strategic plans, development efforts, and operational efforts, it is incumbent upon DISA, in providing the
capabilities and services needed to share information and enable joint war fighting, to constantly look for
ways to improve the services provided. With technology ever improving and outside situations being fluid,
it is necessary to improve services not only to gain a competitive edge, but in many instances simply to
protect DoD data and maintain the status quo.
13.1 Goal
The goal of Continual Service Improvement is to ensure that services provided by DISA remain aligned with
DISA’s mission and the ever-changing needs of those that DISA services, and to ensure that these services
maintain and improve their quality and performance. This is done though two cooperative objectives.
First, DISA should measure and plan for improvement in the performance of current services. Second, DISA
should measure and plan for the improvement of the service management processes that support the
strategy, design, transition, and operations of these services.
13.2 Scope
The scope of Continual Service Improvement is all the services DISA provides, both internally and externally,
and the service management processes that support these services. Also note that DoD and Agency level
Strategic Plans, as identified in Chapter 2, are important references/considerations to ensure appropriate
scope.
13.3 Benefits and Expected Outcomes of CSI








Service Owners and Process Owners will have a process for understanding ways to improve their areas
of accountability
Improved ROI and ROV
Quality of services improves
Quicker recognition of performance issues, allowing for less costly resolutions
Ensures that services remain aligned to mission
Better information for planning
A standardized method for measuring services and processes
Standardized process for monitoring and reporting on technology metrics, process metrics and
service metrics
13.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 80
14.0 Functions
A function is a group of people and the tools they use to carry out multiple processes. The function is
responsible for defining the standards and procedures to be followed when operating within the function.
The table below identifies the functions, their primary and secondary Domains, and the processes with
which they are most closely associated. There is a major challenge in including functions in this framework,
that being that all of these functions already exist, have been in existence for some time, and already have
processes and procedures that have some level of effectiveness. In addition, there are many standards that
exist to guide these individual functions outside those most commonly referenced in this document. The
benefit gained in this document by the functions, is the understanding of standardized integrated processes
and how functions fit into the overall service management framework as they provides service to DISA’s
mission partners.
Roles and Responsibilities in Functions
While all functions have roles and responsibilities, they all have two roles in common: Function Owner and
Function Manager.
The Function Owner has the following responsibilities:

Make sure the functions design includes the policies of the processes that are performed as part of
the function

Ensure that the function follows the governance guidelines of the EXCOM and other governing
bodies

Ensure the integration of the various processes utilized in the function

Coordinate with the various Domain Owners with relation to their processes

Coordinate with Process Owners to suggest improvements to their processes
Since DISA is not organized along service management lines, either by function or process, it is suggested
that the Function Owner be a senior level manager. This is due, in part, to the need to direct members of
the functions across Domains.
The Function Manager is responsible to the Function Owner and performs the day-to-day operational and
managerial tasks demanded by the function. The Function Manager does not necessarily fall into the
Function Owner’s chain of command. The Function Manager has the following responsibilities:

Monitor the function, using qualitative and quantitative Key Performance Indicators (KPI) and make
recommendations for improvement

Play a key role in developing requirements for and maintaining the function’s tools

Function as a point of escalation for questions related to the function

Identify training requirements of all support staff and ensure that proper training is provided to
meet the requirements
DESMF Edition 1.0
Page 81

Provide metrics and reports to management and mission partners in accordance with outlined
procedures and agreements
Figure 13.0 - Functions Relationship Table
Function
Primary
Domain
Primary Domain
Processes
Secondary
Domain(s)
Secondary Domain
Processes
Service Desk
Operations
1. Incident
Management
2. Request Fulfillment
Transition
1. Configuration
Management
2. Change Management
Technical
Management
Operations
1. Incident
Management
2. Problem
Management
3. Event
Management
Design
1. Capacity Management
2. Availability Management
Transition
1. Test & Validation
2. Knowledge
Management
IT Operations
Management
Operations
1. Event
Management
2. Incident
Management
3. Problem
Management
4. Access
Management
Design
1. Service Level
Management
2. IT Service Continuity
Management
3. Security Management
Application
Management
Operations
1. Request Fulfillment
2. Incident
Management
3. Problem
Management
Transition
1. Release Management
1. Service Level
Management
2. Capacity
Management
Operations
1. Event Management
2. Problem Management
Transition
1. Test & Validation
Engineering
DESMF Edition 1.0
Design
Strategy
1. Service Portfolio
Management
Page 82
14.1 Service Desk
14.1.1
Goal
The Service Desk has three primary goals:

Primary contact point for all calls, questions, service requests, complaints, and remarks

Primary provider of ongoing monitoring and management of mission partner satisfaction through
proper communication

To manage the incident lifecycle
As other processes mature, the Service Desk becomes more involved in areas such as Configuration
Management, but the primary goals remain the same.
14.1.2
Scope
Even while acting as the primary mission partner contact for support, the Service Desk is still required to act
within their defined scope. The scope of the Service Desk is determined by the Service Level Agreements
(SLAs) that have been defined specifically through mission partner negotiation. Also note that DoD and
Agency level Strategic Plans, as identified in Chapter 2, are important references/considerations to ensure
appropriate scope.
14.1.3
Benefits and Expected Outcomes of a Service Desk

Mission partner satisfaction – the mission partner is generally better served and better satisfied
through the establishment of a single point of contact for all incidents and service requests.

Decreases in overall business impact of incidents – Incidents are handled more efficiently through the
Service Desk due to consistent use of process, procedures, and tools for resolution.

Cost reduction – Service Desk construct reduces duplicative efforts through better communication and
shared knowledge during incident resolution.

Better C2 – Single point of information flow ensures consistency in reporting to decision makers during
service outages.

Reduction in redundancy and better implementation of global solutions through greater knowledge
sharing.

DISA will increase mission partner satisfaction though quicker resolution, better communication, and
stricter adherence to SLAs.

Reduction in service outages and overall time to restore services.
14.1.4

DESMF Edition 1.0
Relationship to other Functions
Technical Management – Provides second level support during incident resolution, especially as it
relates to the IT infrastructure
Page 83

IT Operations Management - Provides second tier support during incident resolution, especially as
it relates to the services being monitored through operations. Will relay to Service Desk any issues
related to productions activities, job scheduling, and operational failures.

Application Management - Provides second tier support during incident resolution, especially as it
relates to the business applications and systems.

Engineering - Provides third tier support during incident resolution, especially as it relates to the IT
infrastructure and systems.
14.1.4.1
Relationship to Processes

Access Management - Provides support in granting access to mission partners and users.

Incident Management – Primary executer of the incident management process and procedures.
Takes ownership of all incidents.

Problem Management – Participates in problem resolution and trend analysis

Request Fulfillment – Primary point of contact for coordinating mission partner requests for
services as well as informational requests

Configuration Management – Service Desk personnel often fill the role of Configuration
Management Librarian

Change Management – Participate in CABs and track changes against incidents

Service Level Management – Performs requests in conjunction with established SLAs and OLAs
DESMF Edition 1.0
Page 84
14.2 Application Management
14.2.1
Goal
Application Management’s primary goal is to support the lifecycle of applications (requirements,
development, build, deployment, operation, optimization, and retirement) that enhance DISA’s ability to
provide services in support of its mission.
14.2.2
Scope
The scope of Application Management covers the lifecycle of all applications, either provided by a vendor
or developed in-house, from understanding the strategic goals of DISA and its mission partners to the
discontinued use of the application, while ensuring that the applications sustain the services in the
production environment. Basically, any software, other than operating systems and firmware, that resides
on the IT Infrastructure in support of DISA’s services. Also note that DoD and Agency level Strategic Plans,
as identified in Chapter 2, are important references/considerations to ensure appropriate scope.
14.2.3
Benefits and Expected Outcomes of Application Management

Much greater focus on software and software development in support of service

More efficient incident resolution related to applications issues

Reduced cost of service implementations through better control of application configuration items

Better visibility into the Application Management processes resulting in lower risks and higher quality

DISA will have a standard set of processes for deployment of software

Centralized control of software licensing, control of software versioning, and the management of a
definitive software library

Better applications portfolio management through centralization and consistent analysis of software
options and consolidation of software options

DISA will be better at meeting cost, quality, schedule, and performance goals.
14.2.4
Relationship to other Functions

Engineering – Application Management provides specifications and maintenance information for
the new or changed services

Service Desk – Coordinates with Application Management on any issues related to application
incidents

Technical Management – provides specifications to Technical Management for applications
performance configuration and storage requirements.

IT Operations - Provides event management requirements to IT Operations, and guidance on
operational management of the technology.
DESMF Edition 1.0
Page 85
14.2.4.1
Relationship to Processes

Service Management - Provides requirements, needs and wants from stakeholders

Capacity Management – Determines resources required from infrastructure components for
Capacity Management

Service Portfolio Management – provides requirements and prioritization of application
development efforts

Service Level Management – Provides performance throughput information

Supplier Management – supports and often manages suppliers of software

Event Management – Provides required alerts for IT Operations

Configuration Management – Responsible for recording applications CI’s and changes to CI fields as
they relate to deployment

Information Security Management – Identifies security information for access to vendor software,
and for any security bypasses used by purchased software, especially software used for monitoring

Test and Validation – Provides testing of changes and services as related to applications, as part of
the required segregation of duties.

IT Service Continuity Management – Plans for recovery services as related to applications

Incident Management – provides resources for resolution of application incidents

Problem Management – provides resources for resolution of application problems
DESMF Edition 1.0
Page 86
14.3 IT Operations
14.3.1
Goal
IT Operations has the goal of ensuring that the three primary areas of responsibility belonging to them are
aligned with DISA’s mission and services the Agency provides. These areas are:

Management of the day-to-day activities supporting the IT infrastructure

Operations Control

Facilities Management
These areas are further delineated in the scope section
14.3.2
Scope
The scope of IT operations covers (1) Management of the day-to-day activities supporting the IT
infrastructure, (2) Operations Control, and (3) Facilities Management as detailed below. Also note that DoD
and Agency level Strategic Plans, as identified in Chapter 2, are important references/considerations to
ensure appropriate scope.



14.3.3
Management of the day-to-day activities supporting the IT infrastructure
 All hardware owned by DISA
 All software that runs on the infrastructure
 All network components
 Monitoring all of the above areas
 Event Management for all of the above components
 Maintenance contracts with outside vendors
Operations Control
 Job Scheduling
 Backups and restores
 Print and output management
 ITSCM activities
Facilities Management
 Command centers
 Data centers
 Outsourced contracts
Benefits and Expected Outcomes of IT Operations

Continuous monitoring of services - Outages and performance degradation of services can be
mitigated more efficiently through earlier detection

Better conflict resolution – Centralized operations eliminates conflicting computer resources through
holistic scheduling of events in the environment
DESMF Edition 1.0
Page 87

Cost reduction – IT Operations construct reduces duplicative efforts

Better C2 – Single point of information flow ensures consistency in distribution of changing operational
priorities

DISA will better align IT Operations to mission goals

IT Operations should have SLAs, recognized cost of services, and agreement of requirements for moving
new and changed services into production

IT Operations will be represented throughout the service lifecycle
14.3.4
Relationship to other Functions

Technical Management – Provides technical knowledge and expertise related to managing the IT
infrastructure

Service Desk – Coordinates with IT Operations on any issues related to productions activities, job
scheduling, and operational failures

Application Management - Provides guidance to IT operations about how best to carry out the
ongoing operational management of applications

Engineering - Provides event management alerts. Assists in establishing monitoring and
documentation for services
14.3.4.1
Relationship to Processes

Access Management - Provides support in granting access to mission partners and users as it relates
to facilities.

Incident Management – Monitors for, records, and coordinates with the Service Desk for all
infrastructure and job scheduling incidents.

Problem Management – Participates in problem resolution and trend analysis

Event Management – Primary human responder to alerts

Configuration Management – Responsible for recording new infrastructure CIOs and changes to CI
fields, such as location

Change Management – Coordinate maintenance and modifications to infrastructure components

Service Level Management – Monitors and reports on events as related to SLAs. Owns recovery of
infrastructure within SLA parameters. Function is prominent in OLAs.

IT Service Continuity Management – Primary executer of ITSCM plans. Primary tester of ITSCM
plans
DESMF Edition 1.0
Page 88

DESMF Edition 1.0
Information Security Management – Assigns facilities and physical security processes and policies.
Designs event management parameters related to security breaches.
Page 89
14.4 Engineering
14.4.1
Goal
While taking a holistic view of the enterprise architecture, Engineering has the goal of designing, building,
and maintaining the services and products, along with their supporting systems and infrastructure, both
hardware and software, that is the foundation that allows DISA to successfully accomplish its mission. The
systems and services need to perform and function as required by the mission partner, allow for
standardized integration into the architecture, meet agreed levels of reliability and availability, and be
secure and maintain data integrity.
14.4.2
Scope
The scope of Engineering covers the entire lifecycle of the enterprise architecture, from understanding the
strategic goals of DISA and its mission partners, to the design, construction, and testing of the new and
changed services, to the deployments into production, while ensuring that the services are maintainable in
the production environment. Engineering may also need to take a role in the event a service is
discontinued. Also note that DoD and Agency level Strategic Plans, as identified in Chapter 2, are important
references/considerations to ensure appropriate scope.
14.4.3
Benefits and Expected Outcomes of Engineering

Improved management - By defining processes for all of engineering projects to follow, schedules and
budgets are better controlled, and higher quality is achieved

Reduction in turnover impact – Standardized processes lessens the impact of staff turnover, and
handing projects off to different teams

Quality Assurance – Standardization of engineering processes ensures quality and compliance to
various internal and external regulations

Better C2 – Information flow is consistent with other functions through the service lifecycle

Engineering projects should have governance and Domain phase gates for more consistent approvals
and communication

All engineering projects should have a holistic view of DISA’s services

Through understanding of the standard processes used by other DISA roles and functions, Engineering
will be able to better meet requirements up front in the planning and design phases
14.4.4

DESMF Edition 1.0
Relationship to other Functions
Technical Management – Engineering provides specifications and maintenance information for the
new or changed services in order to allow Technical Management to perform their custodial duties
related to the infrastructure. Technical Management provides current configuration data to
Engineering.
Page 90

Service Desk – Coordinates with Engineering on any issues related to changes to productions
services and projected support related items from new and changed services.

Application Management - Provides the software development and ongoing activities related to
software that support the services designed in Engineering.

IT Operations - Provides event management requirements to engineering. Reports back to
engineering on performance and trending analysis for service related issues.
14.4.4.1
Relationship to Processes

Customer Relationship Management - Provides requirements, needs and wants from stakeholders

Service Portfolio Management – Determines strategy and priority for engineering projects

Service Level Management – Provides engineering with requirements related to availability,
capacity, and disaster recovery

Event Management – Provides required alerts for IT Operations

Configuration Management – Responsible for recording new infrastructure CIs and changes to CI
fields as they relate to the new and changed services

Change Management – Approval of the service design package triggers engineering activities

Test and Validation – Provides testing of changes and services, as part of the required segregation
of duties.

IT Service Continuity Management – Plans for recovery of new and changed services

Security Management – Defines event management parameters related to security breaches.
Defines security requirements for services.
DESMF Edition 1.0
Page 91
14.5 Technical Management
14.5.1
Goal
The goal of Technical Management is to supply expertise and knowledge to build and maintain the
infrastructure throughout the lifecycle of services including design, testing, implementation, operations,
and retirement. Technical Management ensures that DISA has access to the right resources to manage
technology in alignment with mission objectives and strategic goals.
14.5.2
Scope
The scope of Technical Management covers the lifecycle of the infrastructure, from understanding the
strategic goals of DISA and its mission partners, to the design, construction, and testing of changes in
support of the mission, to the deployments into production, while ensuring that the infrastructure supports
the services in the production environment. Technical Management will take a role in the event a service is
discontinued, or the infrastructure to maintain service levels requires upgrades or replacement to
infrastructure components. Also note that DoD and Agency level Strategic Plans, as identified in Chapter 2,
are important references/considerations to ensure appropriate scope.
14.5.3
Benefits and Expected Outcomes of a Technical Management
Function

Individual infrastructure service components can be managed more effectively because staff with the
correct training and skills manage them

More efficient incident resolution related to infrastructures issues

Reduced cost of service implementations through better control of infrastructure configuration items

Better Financial Management and understanding of the relationship of high cost infrastructure to
service.

Structure should exist to set goals and plans for the technical department both in business expertise
and technology

Establishment of training program to move technicians into management
14.5.4
Relationship to other Functions

Engineering – Technical Management provides specifications and maintenance information for the
new or changed services

Service Desk – Coordinates with Technical Management on any issues related to infrastructure
incidents

Application Management – provides specifications to technical management for infrastructure
support requirements.
DESMF Edition 1.0
Page 92

IT Operations - Provides event management requirements to IT Operations, and guidance on
operational management of the technology.
14.5.4.1
Relationship to Processes

Customer Relationship Management - Provides requirements, needs and wants from stakeholders.

Capacity Management – Determines resources required from infrastructure components for
capacity management

Service Level Management – Provides performance throughput information.

Supplier Management – supports and often manages suppliers of infrastructure components

Event Management – Provides required alerts for IT Operations

Configuration Management – Responsible for recording new infrastructure CIs and changes to CI
fields as they relate to infrastructure upgrades.

Service Test and Validation – Provides testing of changes and services as related to infrastructure,
as part of the required segregation of duties.

IT Service Continuity Management – Plans for recovery of new and changed services as related to
infrastructure

Information Security Management – Identifies security information for access to infrastructure
components and firmware.

Incident Management – provides resources for resolution of infrastructure incidents

Problem Management – provides resources for resolution of infrastructure problems
DESMF Edition 1.0
Page 93
15.0 References
ISO/IEC 20000® – an international standard that promotes the adoption of an integrated process approach
to effectively deliver managed services to meet business and mission partner requirements; ISO/IEC 20000
is well recognized as the world-wide standard for IT Service Management.
COBIT® (Control Objectives for Information and related Technology) - a business-oriented set of standards
for guiding management in the sound use of information technology; COBIT® originates from the
Information Systems Audit and Control Association (ISACA).
ITIL® (Information Technology Information Library) – a globally recognized framework representing the
most widely accepted best practices approach to IT Service Management in the world.
LSS (Lean Six Sigma) - a business management strategy focusing on the reduction of errors and variation
through the use of quality management and statistical methods.
CMM (Capability Maturity Model) – a standard used to identify relative process maturity; the standard is
used to benchmark process maturity and is used to aid organizational process-improvement
DESMF Edition 1.0
Page 94
16.0 Glossary
In most cases, the definitions provided in the ITIL V3 glossary are used. The definitions in this
glossary supersede those in the ITIL glossary.
Configuration Item: Any component or other service asset that needs to be managed in order to deliver
an IT service. Information about each configuration item is recorded in a configuration record within
the configuration management system and is maintained throughout its lifecycle by service asset and
configuration management. Configuration items are under the control of change management. They
typically include IT services, hardware, software, products buildings, people and formal documentation
such as process documentation and service level agreements. (Source: ITIL V.3 2011)
Feature: A configuration or add-on to a product, something that may be selected from that products
list of characteristics to enable functions or capabilities, often associated with additional cost for the
service or product. (Source: HP Cloud Support Model, DISA ITSM Instruction)
Product: A CI or collection CI’s that have physical characteristics are manufactured and are used to
deliver a capability or function or series of capabilities and functions. A product is often a subset of a
service, but never vice versa. In addition to this a product may be utilized by one or more services and
must be fit for purpose for all services utilizing the product. (Source: HP Cloud Support Model, DISA
ITSM instruction)
Service: A service is comprised a range of products, processes and people packaged such that it is
perceived by Mission partners and Users as a self-contained, single, coherent entity that enables them
to achieve mission objectives and functions. (Source: ITIL V.2 & 3)
Vital Business Function: A Function of a Business Process which is critical to the success of DISA. Vital
Business Functions are supported by critical business services -- those services the business depends
upon. Vital Business Functions are an important consideration of Business Continuity Management, IT
Service Continuity Management and Availability Management.
DESMF Edition 1.0
Page 95
17.0 Appendix A - “DESMF - A Journey in Managing Service”
A framework this involved, intermingled and complex is difficult to articulate and illustrate pictorially. This
excerpt provides dialogue and a graphical representation of one snapshot of the interaction between ITSM
Service Domains and between ITSM processes. This supporting verbiage and the illustrations are not meant
to be an all inclusive rationalization of the framework, but rather a substantiation of the dichotomy that
exists between the simplicity of process to process interaction and the multi-process orchestration that is
paramount when implementing this framework. The circled numbers correlate to graphics.
Table 16.1 – A Journey in Managing Service
1
Leading up to:
DESMF Edition 1.0
Page 96
(A) Mission partner needs and requirements are the driving forces from which DISA garners strategy
and allocates investments to support. The Service Portfolio is the repository of all services. Services
that are available to mission partners are shown on the Service Catalog. The remainder of services
are under consideration to either be provided or to retired.
The Change Management process can launch the Service Portfolio Management process if and
when there’s a request for a major change to an existing service. When the decision has been
made to create a new service or make a major change to an existing service, Design Coordination is
initiated and is responsible for coordinating all service design activities, processes and resources.
1
(B) Design Coordination is accountable for ensuring the consistent and effective design of the new or
changed service. This is achieved through engaging Integrated Project Teams (IPT) which consists
of members from all business units, i.e., Networking, Computing, Applications, Information
Assurance, etc., as required, to complete the initial service design analysis.
Design Coordination activities include coordinating with other Service Design processes (Service
Level Management, Availability and Capacity Management, IT Service Continuity and Security
Management, etc.) and service and product owners to gather information about the infrastructure,
technology stack, required resources, and functional area requirements for the service.
DESMF Edition 1.0
Page 97
Table 16.2 – A Journey in Managing Service
2
(C) The Design Coordinator is responsible for presenting the initial design analysis or service solution to
appropriate decision gates, i.e. Chief Engineering Panel (CEP) and Change Management, in order to
ensure it conforms to strategic, architectural, governance and other Agency requirements.
Change Management is engaged from the aspect that information is accumulated and recorded
which enable management reporting and phased documentation as the change progresses through
its lifecycle. Congruently, Customer Relationship Management, Demand Management and
Financial Management processes have concepts about what the mission partner will pay and what
the potential demand is for the service.
DESMF Edition 1.0
Page 98
Service Portfolio Management assesses this information and recommendations are made to the
EXCOM. The EXCOM approval results in the Service Portfolio and perhaps the Service Catalog
(based on Service Catalog Management process) being updated.
3
(D) Once the Service is chartered, Design Coordination reengages with required IPT members to fully
design the service and produce a detailed Service Design Package (SDP). Details are fleshed out in
great depth across the spectrum of needed support, ensuring the resources are considered and will
be in place, when the service is deployed. This culminates in a very thorough and comprehensive
Service Design Package (SDP) which has been vetted with processes from the other Domains.
DESMF Edition 1.0
Page 99
Table 16.3 – A Journey in Managing Service
4
(E) Design Coordination presents the completed SDP to appropriate decision gates, i.e. Chief
Engineering Panel (CEP) and prior to Service Transition Planning and Support. These two processes
should be interfaced to ensure consistent overall plans and resource schedules.
Prior to releasing the service into the testing environment and employing the Service Validation
and Testing process, various aspects of the service are refined through engaging other processes,
such as Asset and Configuration Management, Financial and Supplier Management and Change
Management.
DESMF Edition 1.0
Page 100
5
(F) Test results are supplied to appropriate decision gates, i.e. Change Management. If testing of the
service renders positive and expected outcomes and meets the design specification and mission
partner needs, the service is deployed into the production environment. Post implementation
activities include a formal assessment of the new or changed service through the Change
Evaluation process.
Service sustainment is accomplished through the Service Operations Domain which coordinates
and carries out activities to deliver and manage the service at the agreed service levels.
All information about the service including the SDP is incorporated into the overall Service
Knowledge Management System (SKMS).
In Conclusion:
This excerpt is one pathway in the ‘Journey in Managing Services’. Process relationships and
integrations have many permutations and levels of abstraction, juxtapositions based on the
uniqueness of the organization (size, culture, core competencies, process maturity level etc.) and
service provided (number and/or complexity of services).
DESMF Edition 1.0
Page 101