IT Operations linked with Development Scenario

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.

Terminology (Related to Operations)

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.

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: Creates a new Change Request. While creating the Change Request, the Change Requester is able to select one or more CIs from the CMDB. Ideally, he is also able to get a hierarchical view of Configuration Items. This is a requirement on the CI selection dialog.

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:

• A Change Request has been created in the Ops Change Management system.

Steps:

• Configuration Librarian:
  • Use the CMDB system to select a CI.
  • View the list of Change Requests on the CI from a given 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.

Scenario 4: Perform Impact Analysis for a 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 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.

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.
• Change Management system queries CMDB to find stakeholders for each CIs, 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 algorithms based on CIs and CI Relationships in CMDB.

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 queries CMDB and runs algorithms to find impacted CIs. Finally, the Ops Change 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: Analyze incident from outstanding defects in software package

• 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', ...

References

• Information Technology Infrastructure Library (ITIL) for Operations terminology

Process to developing this scenario

1. Elaborate on the scenario, possibly define a few alternatives and tool specific configurations
2. Identify key resources and their properties
3. Identify gaps in specification and terminology
   1. 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)