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

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

Pre-conditions:

• Service desk application and defect tracking application are linked

Post-conditions

• Tickets are linked to defects

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.
• An Ops Change Management system exists that is an OSLC Consumer for CIs, 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.

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 an OSLC consumer for OpsChange? .
• An Ops Change Management system exists that is an OSLC Consumer
• 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 Manager
  • Use the CMDB system to select a CI.
  • View the list of Change Requests on the CI and filter them by status and other criteria.
  • View the details of the Change Request.

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 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.

Post-conditions:

• Reference to Impacted CIs has been added to the Change Request.

Steps:

Change Analyst:

- Open an existing Change Request.

- Click on a button to view a list of impacted CIs from CMDB.

- Find the details of each CI.

- Filter these CIs.

- Finally, add the list of impacted CIs to the Change Request.

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 a CIs and an OSLC consumer for OpsChange? .
• An Ops Change Management system exists that is an OSLC Consumer of 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.

Post-conditions:

• CI attribute values in CMDB are updated after Change has been implemented.

Steps:

Change Analyst:

• Open an existing Change Request
• View the list of target CIs associated with the Change Request.
• For each CI, get the list of attributes and their values from CMDB. Attach the new values for the CI to Change Request. Save the updated Change Request.
• Once Change is implemented, apply the attribute value changes to the CIs in CMDB.

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 an OSLC consumer for OpsChange? .
• An Ops Change Management system exists that is an OSLC Consumer for a 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. The Change has been approved. 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 an approved Change. A list of tasks to implement the Change has been created.
• Change Manager schedules the task automatically or manually.
• Change Management system queries the stakeholders for the CIs from CMDB 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 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. The Change has been approved. 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:

• For a specific type of Change, the Change Manager wants to perform automated impact assessment.
• Services team develops code that queries CMDB for Configuration Items, analyzes the returned data, and associates a set of CIs with the Change as Impacted CIs.
• Change Manager can run the automated algorithm to identify impacted CIs.

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: Patch a software package on a production system

• Service Requester: Creates a Service Request to deploy a patch. System creates a Change for the Service Request.
• Change Manager: Gets the Change approved. Plans deployment. Links a software distribution task to an existing patch image (?? what is the corresponding repository on dev side)
• Task Owner: Distributes the software package as specified in 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
   • Vijay working on finishing out the scenarios and prioritization. Working with internal stateholders on this.
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 of 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)