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.
