DRAFT - this scenario is currently under development
This scenario outlines possible integration touchpoints between typical help desk applications and development bug trackers. The scenario will be used to identify the key resources involved in the integration, including their properties. The outcome will determine if new properties are needed or any other specification.
Contents
Information Technology Infrastructure Library (ITIL) defines a set of best practices for managing IT. ITIL also defines terminology that has been widely adopted by IT organizations. In this scenario, we use the following ITIL terms: Problem, Known Error, Request for Change (RFC), Change, Configuration Item (CI), Incidents, Configuration Management Database (CMDB).
When a term is already being used in other domains, we use the prefix “ops” for these terms. As we learn more about the similarities and differences in dev and operational environments, these terms may be merged in future.
Examples to Clarify Terminology
Change Request: “Apply an Operating System patch to the server running the database on the Billing Application”.
Configuration Item (CI): Billing Application, Computer Systems, Operating System that is running on the Computer System
Target CI: The CI associated with a Change, Incident, Problem that needs to be updated. For example, the server on which the patch needs to be applied.
Impacted CIs: The CIs that will be impacted because of a given Change. For example, the applications that will be unavailable when an OS patch is applied to a database server.
Scenarios
Scenario 1: Problem results in the creation of a software package fix
Pre-conditions:
- Service desk application and defect tracking application are linked
Post-conditions:
- Tickets are linked to defects
Steps:
- Problem Analyst: Do root cause analysis of a problem and report a defect to development team or link problem to an existing defect.
- Developer: Prioritize the defect. Take into account the operational impact of the problem.
- Developer: Analyze the defect. Take into account the information in the linked problem, and other related artifacts (e.g., incidents and CIs).
- Developer: Collaborate with the reporter of the problem (gather additional trace reports)
- Developer: Fix the defect. Notify the Problem Analyst of the fix. Optionally, create an opsChange and link to the problem.
- Problem Analyst: View the details of the defect fixes associated with a problem.
Alternatives:
- Awareness of fix availability - when a development fix is available (or other important status update, like won’t fix) update the ticket appropriately
- Notification is sent via known techniques: email, feeds etc
- or… Development tool generates notification (event) and publishes to event listeners
- or… Development tool performs operation/update on linked ticket
- Process of deploying the fix.
- Hotfix - critical situation that requires a software patch from the development team
- Incidents linked/transferred to other incident management systems (development teams not involved in this scenario)
Scenario 2: Create a Change Request for one or more Configuration Items
Pre-conditions:
- A CMDB exists that provides information about Configuration Items. This CMDB may federate information from other repositories. This CMDB is an OSLC provider of CIs and CI Relationships.
- An Ops Change Management system exists that is an OSLC Consumer for CIs and CI Relationships, and is an OSLC Provider of OpsChange.
Post-conditions:
- A Change Request has been created in the Ops Change Management system. This Change Request has references to the “target” Configuration Items.
Steps:
Change Requester:
- In OpsChange system, open the dialog to create a new Change Request. Change Requester specifies the description and other fields in the Change Request.
- Click on a button to select CIs.
- If there are more than one CMDBs, select the CMDB.
- The CMDB system presents a dialog that shows the list of available CIs. This dialog may present a hierarchical view of Configuration Items. This is a requirement on the CI selection dialog.
- Change Requester selects one or more CIs and these CIs get associated with the Change Reques as “Target CIs”.
Scenario 3: View Planned and Completed Changes for a Configuration Item
Pre-conditions:
- A CMDB exists that provides information about Configuration Items. This CMDB may federate information from other repositories. This CMDB is an OSLC provider for CIs and CI Relationships, and an OSLC consumer for OpsChange.
- An Ops Change Management system exists that is an OSLC Consumer of CIs and CI Relationships
- The CMDB and Ops Change Management have been linked.
Post-conditions:
- No changes are made to any of the systems.
Steps:
- Configuration Librarian:
- Use the CMDB system to select a CI.
- Click on a button to “View Changes”. If there is more than one OpsChange provider associated with the CMDB system, CMDB prompts the user to select a CMDB provider.
- View the list of Change Requests on the CI from the selected OpsChange provider. The CMDB system may query the OpsChange provider to get this list and display it in a dialog. This may also be done thru enhancements to OSLC (in addition to a selection, creation and preview dialogs, introduce a notion of relatedResources dialog? This may be more effective because the user can do filtering etc).
- Select one Change Request from the list and view its details.
Pre-conditions:
- A CMDB exists that provides information about Configuration Items. This CMDB may federate information from other repositories. This CMDB is an OSLC provider for CIs and CI Relationships and an OSLC consumer for OpsChange.
- An Ops Change Management system exists that is an OSLC Consumer for CIs and CI Relationships, and is an OSLC Provider of OpsChange.
- The CMDB and Ops Change Management system have been linked.
- A Change Request has been opened and assigned to a Change Manager (a human). This Change Request is associated with one or more target CIs. Target CIs represent the CIs that need to be updated as a result of a Change.
- This example assumes that all the Target CIs are from the same CMDB.
Post-conditions:
- Reference to Impacted CIs has been added to the Change Request.
Steps:
Change Analyst:
- Open an existing Change Request using the Ops Change Management system.
- Click on a button to pass the Target CIs of the Change Request to a CMDB. CMDB runs impact analysis algorithms to identify impacted CIs and shows these CIs in a dialog. Change Analyst browses these CIs, and may identify one or more CIs as impacted CIs.
- Change Analyst clicks on the OK button, and the Ops Change Management system associates the selected CIs to the Change Request as impacted CIs.
Comment:
- The basic idea behind this use case is that Impact Analysis should be a feature of the CMDB systems, not Ops Change Management systems. CMDB systems can offer different levels of capabilities in performing impact analysis.
- This feature may require enhancements to OSLC.
Scenario 5: Update CI Attribute Values in CMDB after Implementing Change
Pre-conditions:
- A CMDB exists that provides information about Configuration Items. This CMDB may federate information from other repositories. This CMDB is an OSLC provider for CIs and CI Relationships, and an OSLC consumer for OpsChange.
- An Ops Change Management system exists that is an OSLC Consumer of CIs and CI Relationships, and is an OSLC Provider of OpsChange.
- The CMDB and Ops Change Management have been linked.
- A Change Request has been opened and assigned to a Change Manager. This Change Request is associated with one or more target CIs.
Post-conditions:
- CI attribute values in CMDB are updated after Change has been implemented.
Steps:
Change Analyst:
- Open an existing Change Request in the Ops Change Management system.
- View the list of target CIs associated with the Change Request in the Ops Change Management system.
- For each CI, get the list of attributes and their authorized values from CMDB. Specify the authorized values for the CI attributes. These new values are saved in the Change Request in the Ops Change Management system.
- Once Change is implemented, invoke an API to the CMDB system to apply the attribute value changes to the CIs in CMDB.
Implementation Notes:
- The CI attributes may be specific to this CMDB. The Change Management system should not assume specific attributes on the CI.
- If saving the authorized values in Ops Change Management system proves difficult, these may need to be stored in CMDB.
- It is assumed that the attributes and their values are name/value pairs.
Scenario 6: Schedule Implementation Tasks for a Change and Notify Stakeholders
Pre-conditions:
- A CMDB exists that provides information about Configuration Items. This CMDB may federate information from other repositories. This CMDB is an OSLC provider for CIs and CI Relationships, and an OSLC consumer for OpsChange.
- An Ops Change Management system exists that is an OSLC Consumer for CIs and CI Relationships, and is an OSLC Provider of OpsChange.
- The CMDB and Ops Change Management have been linked.
- A Change Request has been opened and assigned to a Change Manager. This Change Request is associated with one or more target CIs. The Change has been approved. The Change Request is associated with implementation tasks. The Change Manager needs to schedule the tasks for implementing the Change.
Post-conditions:
- Change Management system has the tasks scheduled and the interested parties have been notified.
Steps:
- Change Manager opens the approved Change.
- Change Manager schedules the tasks associated with the approved Change Request. In doing so, he uses the capabilities provided by the OpsChange system.
- Change Management system queries CMDB to find stakeholders for each CI, and notifies them about the scheduled changes.
Scenario 7: Custom Impact Analysis
Pre-conditions:
- A CMDB exists that provides information about Configuration Items. This CMDB may federate information from other repositories. This CMDB is an OSLC provider of CIs and CI Relationships, and an OSLC consumer for OpsChange.
- An Ops Change Management system exists that is an OSLC Consumer for CIs, and is an OSLC Provider of OpsChange.
- The CMDB and Ops Change Management have been linked.
- A Change Request has been opened and assigned to a Change Manager. This Change Request is associated with one or more target CIs.
- Change Management system has sophisticated impact analysis rules and algorithms based on CI types and CI Relationships in CMDB. For example, a rule may be that ‘if a Business Application “runs on” a Computer System, and the Computer Sytem is down, the Business Application will be unavailable’.
Post-conditions:
- Change Management system has associated the impacted CIs with the Change Request.
Steps:
- For a specific type of Change, the Change Manager wants to perform an impact assessment. He opens the Change Request and clicks a button to perform impact analysis.
- The Ops Change Management system performs multiple queries on the CMDB and runs algorithms to find impacted CIs. Finally, the OpsChange Management system displays a list of possible impacted CIs to the Change Manager.
- The Change Manager selects some of the CIs identified by the Change Management system.
- The Ops Change Management system associates these CIs with the Change as Impacted CIs in the Change Management system.
Scenario 8: (TBD) Analyze incident from outstanding defects in software package
Pre-conditions:
- An incident has been opened in the Incident Management system. This incident is associated with a Business Application CI.
- There is a system that documents the known errors in the Business Application.
- Problem Analyst: Start analyzing an incident. Leverage information about Known Errors in the defect tracking application. Apply information in Known Error to the Incident.
Scenario 9: Associate a software patch image with a Change Request
Pre-conditions:
- Ops Change Management system has been linked with a software asset repository.
- A Change Request exists to deploy a patch to one or more CIs. Change Request has been approved.
Post-conditions:
* A task associated with Change Request has been associated with a software asset that resides in software asset repository.
Steps:
- Change Manager opens the Change Request and creates a task for distributing patch.
- He clicks on a button to associate a software patch for the task. He selects a software asset repository and gets a delegated dialog. He selects one patch image. The Change Management system associates the image with the task.
Resources
- Defect - identified change in behavior requested in a software application.
- Ticket - problem reported from an operating application in an IT environment. There are ‘kinds’ of tickets:
- Incident – something wrong happened in operations, it was resolved by the operations team doing something. Examples are: restarting a server, allocating more disk space, resetting password, …
- Change Request - the instance is recurring, it’s a problem & requires a more permanent fix. Examples are: we’ve repeatedly restarted the server but problem persists (such a memory leak), a critical problem such as ‘we have a security breach’, …
TBD
- Add a scenario: As a result of a Change, CI relationships need to be updated.
- Add a scenario: As a result of a Change, new CIs need to be created.
References
Process to developing this scenario
- Elaborate on the scenario, possibly define a few alternatives and tool specific configurations
- Identify key resources and their properties
- Identify gaps in specification and terminology
- Is the definition of the current “CM” domain clear enough or does the ALM definition need to be augmented to include operations?
Possible Specification Needs
This is a collection of possible specification changes or addition in support of the above scenarios.
- The interaction between CMDB and its consumers has largely been focused on data. With OSLC, we can make integrations more usable by introducing integration at the glass. For example, when a Change Manager clicks on a CI in Change Management system, he can view the CI as rendered by CMDB.
- These scenarios will impact the following types of resources:
- Change Request.
- Configuration Items
- Service Request, Incident, Problem Management
- Property for the relationship
- Additional resource types
- A spec written with language familiar to ITIL / IT Operations.
- Notification/event mechanism
- Mechanism to propagate certain important state/property updates across providers (when Defect closes, update Ticket)
Category:Supporting documents
