Table of Contents
1
EXECUTIVE SUMMARY..................................................................................................... 5
2
DISA Enterprise Service Management Framework (DESMF) Overview ......................... 5
2.1 DESMF Scope .................................................................................................................................... 5
2.2 DESMF Goal ...................................................................................................................................... 5
2.3 DESMF Purpose ................................................................................................................................ 6
2.4 Benefits of the DESMF ....................................................................................................................... 7
2.5 DESMF Expected Outcomes ............................................................................................................. 7
2.6 DESMF Guidance .............................................................................................................................. 7
2.7 DESMF General Recommendations on Utilizing the Framework for Process Improvement ............ 8
2.8 Critical Success Factors (CSF) .......................................................................................................... 8
2.9 Guiding Principles of the DESMF ....................................................................................................... 9
3
Overview of the DESMF Structure ................................................................................. 11
3.1 Service Strategy Domain.................................................................................................................. 11
3.2 Service Design Domain .................................................................................................................... 14
3.3 Service Transition Domain ............................................................................................................... 14
3.4 Service Operations Domain ............................................................................................................. 14
3.5 Continual Service Improvement (CSI) Domain ................................................................................ 15
3.6 Domain Relationships Table ............................................................................................................ 16
4
Roles & Responsibilities................................................................................................. 18
4.1 Executive Sponsor ........................................................................................................................... 18
4.2 Principal Directors ............................................................................................................................ 18
4.3 Domain Owner ................................................................................................................................. 18
4.4 Process Owner ................................................................................................................................. 18
4.5 Process Manager ............................................................................................................................. 19
4.6 Service Owner .................................................................................................................................. 19
4.7 Service Manager .............................................................................................................................. 20
4.8 Product Owner ................................................................................................................................. 20
4.9 Subject Matter Expert (SME)............................................................................................................ 20
4.10 Other Roles ...................................................................................................................................... 20
DESMF Edition 1.0
Page 1
5
Metric vs. Measurement .................................................................................................. 22
6
Generic Recommended Milestones for DESMF Process Design ................................. 24
6.1 Define Scope and Objectives ........................................................................................................... 24
6.2 Validate the Current Environment .................................................................................................... 24
6.3 Develop High-Level Process Definition ............................................................................................ 24
6.4 Define Roles and Responsibilities .................................................................................................... 24
6.5 Document Detailed Work Flow for Each High Level Activity............................................................ 25
6.6 Build the Process ............................................................................................................................. 25
6.7 Define and Document Knowledge Transfer and Training Requirements ........................................ 25
6.8 Finalize Process Guide .................................................................................................................... 25
6.9 Develop Implementation Plan .......................................................................................................... 25
7
Individual Domain and Process Framework.................................................................. 25
8
Service Strategy Domain ................................................................................................ 26
8.1 Domain Metrics ................................................................................................................................ 28
8.2 Strategy Management (SM) for IT Services ..................................................................................... 29
8.3 Customer Relationship Management (CRM) ................................................................................... 30
8.4 Service Portfolio Management (SPM) .............................................................................................. 31
8.5 Service Catalog Management (SCM) .............................................................................................. 32
8.6 Financial Management for IT Services (FM) .................................................................................... 33
8.7 Demand Management (DM) ............................................................................................................. 34
9
Service Design Domain................................................................................................... 35
9.1 Domain Metrics ................................................................................................................................ 36
9.2 Service Level Management (SLM) ................................................................................................... 37
9.3 Availability Management (AvM) ........................................................................................................ 38
9.4 Capacity Management (CapM) ........................................................................................................ 39
9.5 IT Service Continuity Management (ITSCM) ................................................................................... 40
9.6 Information Security Management (ISM) ......................................................................................... 41
9.7 Design Coordination (DC) ................................................................................................................ 42
10 Service Transition Domain ............................................................................................. 43
10.1 Domain Metrics ................................................................................................................................ 45
DESMF Edition 1.0
Page 2
10.2 Change Management (ChM) ............................................................................................................ 47
10.3 Change Evaluation (Eval)................................................................................................................. 48
10.4 Asset Management (AM).................................................................................................................. 49
10.5 Configuration Management (CfM) .................................................................................................... 50
10.6 Knowledge Management (KM) ......................................................................................................... 51
10.7 Release and Deployment Management (RDM) ............................................................................... 52
10.8 Service Validation and Testing (SVT) .............................................................................................. 53
10.9 Transition Planning and Support (TPS) ........................................................................................... 54
10.10
Supplier Management (Sup) ..................................................................................................... 55
11 Service Operations Domain ............................................................................................ 56
11.1 Domain Metrics ................................................................................................................................ 58
11.2 Incident Management (IM) ............................................................................................................... 58
11.3 Problem Management (PM) ............................................................................................................. 60
11.4 Request Fulfillment (RF) .................................................................................................................. 61
11.5 Event Management (EM) ................................................................................................................. 62
11.6 Access Management (AcM) ............................................................................................................. 63
12 Continual Service Improvement (CSI) Domain .............................................................. 64
12.1 Goal .................................................................................................................................................. 64
12.2 Scope ............................................................................................................................................... 64
12.3 Benefits and Expected Outcomes of CSI ......................................................................................... 64
12.4 Process Relationship Map................................................................................................................ 64
13 Functions ......................................................................................................................... 65
13.1 Service Desk .................................................................................................................................... 67
13.2 Application Management .................................................................................................................. 69
13.3 IT Operations .................................................................................................................................... 71
13.4 Engineering ...................................................................................................................................... 74
13.5 Technical Management .................................................................................................................... 76
14 References ....................................................................................................................... 78
15 Glossary........................................................................................................................... 79
16 Appendix A - “DESMF - A Journey in Managing Service” ............................................ 80
DESMF Edition 1.0
Page 3
DESMF Edition 1.0
Page 4
1
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
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
The goal of the DESMF is to provide the framework to successfully align the delivery of IT services with the
mission of DISA. 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.
DESMF Edition 1.0
Page 5
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

Define the recommended interfaces between the Domains and the processes

Recommend a set of milestones for process implementations
To better understand the purpose of the DESMF, it is necessary to 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:


Part 1: ISO/IEC 20000-1 – a document with 256 requirements a service provider "shall" adhere to
when seeking certification.
Part 2: ISO/IEC 20000-2 – a document with hundreds of "recommendations" a service provider
should take into consideration when attempting to meet the requirements.
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), 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.
DESMF Edition 1.0
Page 6
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
2.5 DESMF Expected Outcomes




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
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:

DESMF Edition 1.0
Concept of Operations (CONOPS) – CONOPS for processes are developed separately from this
document, but use this framework to align the efforts
Page 7

2.7

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
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.

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

Define Organizational Process Ownership
 Identify areas best suited for ownership of processes
 Identify Process Owners

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:


DESMF Edition 1.0
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
Page 8



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®.
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.
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 Edition 1.0
Page 9
DESMF Edition 1.0
Page 10
3
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
At the center of the service lifecycle is Service Strategy. This is where 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. DISA's Strategic Plan and Campaign Plan
are primary outputs of this stage of the service lifecycle. DISA uses the Service Strategy Domain to set
Agency goals and objectives towards supporting 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 that 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. DISA has also added the business function Agency Governance to the Service
Strategy Domain.
3.1.1 Agency Governance DESMF IT Governance
DESMF governance is aligned with the International standard for IT governance; ISO/IEC 38500, governance
frameworks such as COBIT and guidance from renowned sources such as the IT Governance Institute. The
need for Enterprise IT governance has been an expanding realization within industry and government in the
past ten years. Industry realized during the 1990s that the organization chart (chain of command in DoD)
was sufficient to execute business processes however, it was soon realized that IT needed to be controlled
to reduce the risk and costs associated with developing IT capability and align IT initiatives that drives the
business strategic objectives. The establishment of an IT Governance structure, subordinate and integrated
to the business organization chart addresses those purely IT problems and decisions that directly impact
the strategic focus of the business. Within DoD, there has been steady adoption of IT governance structures
to better direct and control IT initiatives. This has been a direct result of having to control risk, suppliers,
cost, and align IT initiatives to the strategic and tactical mission objectives in support of the Warfighter. IT
Governance exists to solve IT problems by communicating succinct decisions, allocating authority to make
decisions, and controlling IT initiatives. Operating in the DoD IT environment poses special problems that
can only be addressed with a top down integrated IT governance model and IT governance must be
established at many levels to address the IT problems at those levels. IT Governance enhances the SA and
C2 of the chain of command by setting up policies and compliance measures that direct and control ITSM. If
we correctly view the chain of command as the equivalent of the business organization chart, IT
governance is as vital to the DoD as it is in the private sector, DoD has many of the same IT problems, IT is
DESMF Edition 1.0
Page 11
IT no matter if it’s private sector or government, IT governance is always subordinate to the chain of
command. It is hard to find a high performing organization that doesn’t have IT governance established,
large and small businesses, non-profits, universities, health care, and many DoD and government civilian
organizations have established IT governance. In most cases, organizations that are not high performing can
trace one of the major inhibitors to attainment of goals as lack of IT governance. ITSM processes and
services drive business processes and services delivered to the customer and other consumers. Without IT
governance bodies to direct, control, and evaluate the operational IT community, provide conflict
resolution, and set policy, the ITSM processes become ineffective, the services not controlled properly and
both never realize the benefits of increase customer satisfaction, improvements and more important
increased C2 and SA.
3.1.2 Compliance
All IT Governance bodies must ensure compliance with all Federal Government and DoD policies and
regulations. There are also directives and decisions from higher level governance bodies that each
governance body must ensure compliance including standardization. Governance bodies should clearly
communicate and enforce compliance measures. Non-compliance can be reported to the next level
structure as an exception in exception reporting for action.
3.1.3 Risk Management
It’s a core responsibility of IT governance bodies to address risks to the enterprise related to IT initiatives.
Risk always exists whether or not it is detected or recognized. Risks include risk to the mission, operational,
compliance, strategic, service delivery, information assurance, manpower, and others. Risks include
anything that could impact the strategic objectives and operational readiness of the organization the
governance body directs and controls. Risk surveillance, detection, evaluation and response should be
imbedded into the IT governance system. A risk register should be maintained and appropriate personnel
assigned by the governance body to manage IT risk issues within the organization.
3.1.4 Service Execution
One of the important focuses of IT governance should be on the problems of service execution. First the
enterprise must determine the problems that exist and then implement governance structures to address
and govern those identified problem areas. Successful service execution drives mission alignment and
customer satisfaction and the governance structures must allocate decision rights and accountability to
ensure the services are defined in customer terms and successfully communicated to the enterprise and
customers. If services are not clearly defined in customer terms so that they understand what the services
are and are not, expectations are made up of past experience, word-of-mouth and needs/wants of
customers. Chance of satisfaction and needs being met are very low.
3.1.5 Performance Measurement
In any DoD IT organization, the use of measures is necessary to determine if the ship is on course, or if we
need a course correction. Key to any governance framework is measurement reporting because
measurements determine whether IT is meeting the mission objectives through established performance
levels and results. The actual metrics for performance measurements should be determined by the
DESMF Edition 1.0
Page 12
stakeholders and customers of the services based on their specific requirements. Governance ensures
those measurements are transparent, timely and receive the management overview necessary for
successful evaluation of the promised value of ITSM. Performance measures help align the enterprise to a
set of common ITSM goals and produce positive results. The measures should be in common
understandable language and not tech-speak. Measurement reporting is the only method the enterprise
can control the IT initiatives and set course corrections when necessary.
3.1.6 Resource Management
One focus of IT governance is concerned with the effective and efficient management of resources to
achieve strategic goals and objectives – another risk management vector. Areas in scope include ensuring
manpower availability, utilization and skillsets meet the requirements of the mission. Education and
proficiency training of human resources are addressed and progress tracked. In commercial organizations,
IT governance is responsible for IT budgets, for software and equipment, making proposals to higher level
governance bodies and tracking and reporting variance. IT budgets are solely the responsibility of the IT
governance system and aligned with the mission, strategy and objectives of the organization. This may or
may not be the case in DoD organizations.
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.
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. The distinction between Agency Governance and IT Governance at DISA, is not as clear as it
is in industry. What is clear is that IT capability is directly related to the long term consequences of
decisions made by top management. Traditionally, DISA deferred key IT decisions to internal business
units. But, as DoD moves to a Joint Infrastructure Environment, DISA cannot ensure the best interests of all
DESMF Edition 1.0
Page 13
stakeholders unless deliberate action involves all stakeholders. 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.
Within the DESMF, Agency Governance is the highest layer of IT Governance within DISA, the highest
decision making board being the Executive Committee (EXCOM).
3.2
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.
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.
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
serves as the approval authority to introduce new initiatives, ensures standards-based configuration
DESMF Edition 1.0
Page 14
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 15
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:
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
DESMF Edition 1.0
Guidance for change
approval
Specifications for
new services
Financial guidance
for service
implementations
Products to be
deployed
Deployment support
Measurement of Service
Transition processes
ASI Support
Analysis of Knowledge
Deployment and test
Page 16
From:
Service
Strategy (SS)
Service Design
(SD)
Service
Transition (ST)
Service Operations (SO)
Continual Service
Improvement (CSI)
To:
Budget information
support
Management information
Specifications for
evaluation
Access to facilities
SO
Intent of services
Event management
alert criteria
Budget information
Releases
Measurement of Service
Operations processes
Change information
Services operating
procedures
Analysis of performance
issues
Fulfillment of Problem
Management
Governance
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 17
4
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 18

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 19
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 20
4.10.1 Common Control Activities
To enable ITSM process governance, control and process improvement activities, every process includes
common control activities based on guidance from COBIT 5 Governance processes and the Monitor,
Evaluate and Access domain processes. These common control activities provide a standard approach to
process monitoring, reporting, and evaluating process achievement. Based on the evaluation,
improvements for the process can be recommended and part of service improvement initiatives. These
common control activities provide the government with built-in process governance and continual service
improvement for every DESMF process.
There are three common control activities in each process:



Establish Process Framework
Monitor, Manage and Report
Evaluate Process Performance
Figure 1: Common Control Activities
The Establish Process Framework activity is always the first activity, the Monitor, Manage and Report
activity is always the next-to-last activity, and the Evaluate Process Performance activity is always the last
activity. These control activities ensure a continual service improvement loop in every NPRM process. Table
2 details the common control activities.
DESMF Edition 1.0
Page 21
Table XX: Common Control Activities in all DESMF Processes
DESMF Common Control Activities
Control
Activity
Establish Process
Framework
Monitor, Manage
and Report
Evaluate Process
Performance
5
Definition
This activity provides all guidance necessary for
executing the process. This collective guidance is
referred to as the process framework. This activity
defines the specifics of how a process will be carried
out and used as a "control" within the Service
Management System. While the government may
set policies, scope and provide contractual
guidance, the execution of this process will vary
depending on the acquisition approach and the
process.
This activity is the primary activity used by
management to monitor the work taking place in
the process, determine if management intervention
is needed, and obtain reports on process
achievement. Process Manager is continuously
monitoring the normal work of the process. This is a
government retained activity.
This activity evaluates how well the process is
executed and recommends improvements to the
process framework which is a continuous loop. This
is a government retained activity.
Includes
 Process purpose, scope,
outcomes
 Policies and standards
 Conceptual models
 Process interfaces
 Workflows
 Roles and responsibilities
 Organizational mappings
 Procedures and work instructions
 Data requirements
 Tool information and guidance
 Metrics
 Process monitoring activities
 Management intervention
 Reporting
 Feedback from customers and
stakeholders
 Metrics
 Lessons learned
 Process execution assessments
 Assessments & Audits
 Documentation reviews
 Industry trends and best practices
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:
DESMF Edition 1.0
Page 22

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.).
DESMF Edition 1.0
Page 23
6
Generic Recommended Milestones for DESMF Process Design
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:
6.1
Define Scope and Objectives


6.2
Determine and document business objectives and boundaries of project
Gain necessary concurrence or authority to proceed
Validate the Current Environment






6.3
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
Develop High-Level Process Definition



6.4
Identify high level CSFs and KPIs
Document high level process definitions
Define high level process inputs and outputs
Define Roles and Responsibilities


DESMF Edition 1.0
Identify skills and knowledge level
Create RACI matrix mapping activities to process roles
Page 24

6.5
Develop cross-functional relationships
Document Detailed Work Flow for Each High Level Activity


6.6
Document detailed procedures for each high level activity
Create communications plan
Build the Process

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
6.7
Define and Document Knowledge Transfer and Training Requirements

Develop Training Program

Deliver Process and Tool Training
6.8
Finalize Process Guide
6.9
Develop Implementation Plan
7
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.
After the Domains, there is a section focused on Functions.
DESMF Edition 1.0
Page 25
8
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
Establish
DESMF Edition 1.0
Define
controls for
spend/actual
for programs/
Projects
Usage of
services
Required funding
Define
Page 26
From:
Customer
Relationship
Management
Demand
Management
Financial
Management
(DM)
(FM)
Governance
(GOV)
Service Catalog
Management
Service Portfolio
Management
Strategy
Management
(SCM)
(SPM)
(SM)
(CRM)
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 27
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
8.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 28
8.2
Strategy Management (SM) for IT Services
8.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.
8.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.
8.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
8.2.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 29
8.3
Customer Relationship Management (CRM)
8.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.
8.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.
8.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
8.3.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 30
8.4
Service Portfolio Management (SPM)
8.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.
8.4.2
Scope
The scope of Service Portfolio Management is all of the IT related services offered to mission partners, both
internal and external. 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
8.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
8.4.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 31
8.5
Service Catalog Management (SCM)
8.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.
8.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.
8.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
8.5.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 32
8.6
Financial Management for IT Services (FM)
8.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.
8.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.
8.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
8.6.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 33
8.7
Demand Management (DM)
8.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).
8.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.
8.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
8.7.4
Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 34
9
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 35
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
9.1
SDP
requirements
SDP
requirements
SDP
requirements
SDP
requirements
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 36
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.
9.2
Service Level Management (SLM)
9.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.
9.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.
9.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
9.2.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 37
9.3
Availability Management (AvM)
9.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.
9.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.
9.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
9.3.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 38
9.4
Capacity Management (CapM)
9.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.
9.4.2
Scope
The scope of the Capacity Management includes almost all configuration items. 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.
9.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
9.4.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 39
9.5
IT Service Continuity Management (ITSCM)
9.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.
9.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. 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.
9.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
9.5.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 40
9.6
Information Security Management (ISM)
9.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:



9.6.2
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
Scope
The scope of ISM includes all the use (and misuse) of all IT systems that support DISA’s mission and
services. This 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
9.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
9.6.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 41
9.7
Design Coordination (DC)
9.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.
9.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.
9.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
9.7.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 42
10 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)
Change
Management
(ChM)
Supplier
Management
(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
Release plans
Policy and
process
documents
Policy and
process
documents
Artifacts from
projects
Policy and
process
documents
Policy and
process
documents
Supplier
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 43
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 44
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)
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
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 change management is “# of incidents caused by
changes”. This number often goes up if testing is done poorly, if release documentation is not well
DESMF Edition 1.0
Page 45
Supplier
Management
(Sup)
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 46
10.2 Change Management (ChM)
10.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.
10.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.
10.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

10.2.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 47
10.3 Change Evaluation (Eval)
10.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.
10.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.
10.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
10.3.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 48
10.4 Asset Management (AM)
10.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.
10.4.2 Scope
The scope is any physical or software asset that supports a service provided by DISA, either internally or
externally. Thus, asset management is responsible for managing:



Hardware (including maintenance)
Software (including maintenance)
Facilities (and related, such as desks, etc.)
10.4.3 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
10.4.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 49
10.5 Configuration Management (CfM)
10.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.
10.5.2 Scope
The scope is any asset that supports a service provided by DISA, either internally or externally. Thus,
Configuration Management is responsible for controlling:
 Hardware

Software (including licenses)



Facilities
Documentation (including SLAs)
Entries from other processes (changes, incidents, etc.)
10.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
10.5.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 50
10.6 Knowledge Management (KM)
10.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
10.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.
10.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
10.6.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 51
10.7 Release and Deployment Management (RDM)
10.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.
10.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.
10.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
10.7.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 52
10.8 Service Validation and Testing (SVT)
10.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.
10.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.
10.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
10.8.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 53
10.9 Transition Planning and Support (TPS)
10.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.
10.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
10.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
10.9.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 54
10.10 Supplier Management (Sup)
10.10.1Goal
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
10.10.2Scope
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. 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
10.10.3Process 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

Creation and management of supplier and contract information
DESMF Edition 1.0
Page 55
10.10.4Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
11 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
events for monitoring
Feedback on EM
reports related to
To:
Request Fulfillment (RF)
EM
DESMF Edition 1.0
Provides information
about changes to CI’s
Page 56
From:
Event Management
(EM)
Incident Management
(IM)
Problem
Management (PM)
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
DESMF Edition 1.0
Page 57
From:
Event Management
(EM)
Incident Management
(IM)
issues (problems)
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
Access
Management
(AcM)
Request Fulfillment (RF)
AcM
RFC access inquiry
RF
Access
information for
RFC
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 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.
11.2 Incident Management (IM)
11.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.
11.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
DESMF Edition 1.0
Page 58
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.
11.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
11.2.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 59
11.3 Problem Management (PM)
11.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.
11.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.
11.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
11.3.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 60
11.4 Request Fulfillment (RF)
11.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.
11.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.
11.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
11.4.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 61
11.5 Event Management (EM)
11.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.
11.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.
11.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
11.5.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 62
11.6 Access Management (AcM)
11.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.
11.6.2 Scope
The scope of Access Management is the enforcement of all policies set forth in Service Strategy and
Information Security Management.
11.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
11.6.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 63
12 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.
12.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.
12.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.
12.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
12.4 Process Relationship Map
(Process relationship map will be inserted in the Second Edition)
DESMF Edition 1.0
Page 64
13 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 65

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 66
13.1 Service Desk
13.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.
13.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.
13.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.
13.1.4 Relationship to other Functions

DESMF Edition 1.0
Technical Management – Provides second level support during incident resolution, especially as it
relates to the IT infrastructure
Page 67

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.
13.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 68
13.2 Application Management
13.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.
13.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.
13.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.
13.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 69
13.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 70
13.3 IT Operations
13.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
13.3.2 Scope
The scope of IT operations covers the following three items:



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
13.3.3 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

Cost reduction – IT Operations construct reduces duplicative efforts

Better C2 – Single point of information flow ensures consistency in distribution of changing operational
priorities
DESMF Edition 1.0
Page 71

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
13.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
13.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

Information Security Management – Assigns facilities and physical security processes and policies.
Designs event management parameters related to security breaches.
DESMF Edition 1.0
Page 72
DESMF Edition 1.0
Page 73
13.4 Engineering
13.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.
13.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.
13.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
13.4.4 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.

Service Desk – Coordinates with Engineering on any issues related to changes to productions
services and projected support related items from new and changed services.
DESMF Edition 1.0
Page 74

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.
13.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 75
13.5 Technical Management
13.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.
13.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.
13.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
13.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.

IT Operations - Provides event management requirements to IT Operations, and guidance on
operational management of the technology.
DESMF Edition 1.0
Page 76
13.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 77
14 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 78
15 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 79
16 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 80
(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 81
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 82
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 83
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 84
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 85