Service Desks traditionally serve the operational and production
aspects of IT organizations and their respective business units. However, business services that consist of
applications typically start their lifecycle as requirements from the
originating business unit, then follow a development lifecycle before entering the
operations realm. This development lifecycle
is commonly a blind spot for service desks manifesting most typically via an
incident logged against an application in production requiring maintenance or
upgrade work to be completed by development.
End-to-End change management removes this
blind spot by linking the development lifecycle - which also widely known as ‘Application
Lifecycle Management (ALM)', with the production environment typically served
by the Service Desk.
The service desk provides the primary window for customer and user contact
with the service organization on a day-to-day basis. Though not a process
itself according to ITIL (it is a function), the service desk may be
responsible for a number of discrete functions within the support organization.
End-to-End Change Management
Change management
has two main objectives. The first is to
provide support for the processing of changes, typically initiated via the service
desk. Such processing includes change
identification, analysis, prioritizing, planning for their implementation,
decisions for their rejection or postponement, and decisions for their
integration in new product releases. The
second objective is traceability (i.e., to make it possible to list all active
and implemented changes). It should also
be possible to track the modifications of different items due to a specific
change. (e.g. Part of the ITIL Knowledge database.)
By extending
the Service Desk into ALM, traceability will not only include configuration
items (CIs) in production, but will also provide the capability to link to all
application development artifacts to be able to perform end-to-end impact
analysis, including the scope of the resolution of the problem under analysis.
When a
change is initiated, an RFC is created to track the change until it is resolved
and closed. The change control board
(CCB) or change advisory board (CAB), a group responsible for operational
aspects of the product/application, analyzes the Request for Change (RFC) and determines the
action to be taken.
If the
change is approved, the RFC is passed to the developer responsible for
implementing the change. When the
developer has performed the change, its status becomes ‘implemented' and
testing can then be performed. The CCB
also decides which changes are to be included in the new product release or if
the change will be included in existing product versions in the form of a
service pack.
For each
RFC, it should be possible, and indeed preferable, to see which versions of the
modified files were created as a result of the RFC. Conversely, it should be possible to answer
the question, "for what reason was this version of the file/product created?" (e.g. against which RFC's and why.)
This is where ALM can help provide
traceability and auditability, for service desks alone do not provide the
capability to ‘see' inside development and test environments to provide true
end-to-end change management visibility and traceability. This linkage would enable "live" status of
the problem resolution for a ticket requiring application developers action and
re-release via the Configuration Advisory Board (CAB). An example of this would be MKS Integrity
driving the workflow for integration of these processes between MKS and a
service desk.
Integration
Points for Traceability & Auditability
The integration points are
where ALM can provide the ability to extend the Service Desk and provide live
information for the operations efforts that reflects current state of all RFC's
and incidents that are in the active state.
Integration points bridge the
gaps between silos created by development, testing and operations-oriented
tools. As an example, application
development utilizes ‘defect management' for bugs, changes, etc., and the
operations group would use the SD to open an incident. Both processes serve the same purpose, but
are not integrated and thus are not visible to the other group.
Key traceability &
auditability points in this scenario, and their value/benefit:
- Incident lifecycle
ownership - The Service desk (SD) is responsible for end-to-end ownership
of incidents. ALM provides value by
providing visibility of the incident status/state by linking the defect
process utilized in the application development process with the incident
ticket.
- Request for
Change - Once a formal RFC is opened in the SD, this integration point
extends to ALM through the MKS workflow to create a defect for the
developers to work against. SBOM Artifacts
would include the application source code, configuration files,
requirements, test data, etc., and thus be visible to the RFC/ticket and
SD as to true application impact, once the RFC has been completed and is
ready for the CAB.
- Communication
of Planned Changes to Customers - This interface provides the
capability for complete visibility into the status of the RFC. As an example, if the RFC has been
assigned to a specific developer and the developer has checked-out the
impacted code and its associated test files, one can rightly assume that
the status is that the change is being tested.
- Evaluate Proposed
Changes for Capacity and Performance Impacts - MKS
Integrity can automate the notification of the capacity planning and
availability management teams whenever any RFC results in changes to
configuration settings that are typically associated with application
performance in a production environment.
- Perform
Impact Assessment of Proposed Changes - Impact analysis information, stored
in the SCM repository, would consist of requirements information, code,
configuration files, test cases, test data, design data, business process
data, etc.
- Provide
Configuration Information to Problem Management to perform Level 1-2-3
Root Cause Diagnosis - The SCM repository, as part of its
capability to adhere to the federated CMDB approach, would have the
ability to provide application configuration information to the SD when
problem management and root cause analysis is being performed.
Trackback(0)
Comments 
Write comment
 |
CM Journal Articles 
TrackBack URI for this entry
Subscribe to this comment's feed