Change request examples

Service Requests

· Database backup request

· Environment refresh (backflow)

· Account unlocks - database or other

· Application or database server restarts (assumes there is no other change activity attached)

· General inquiries

· Running of SQL scripts

· Application or database investigation or troubleshooting requests

BAU Changes

Criteria:

· Client initiated

· Operational type changes - frequently requested

· Does not meet any of the Normal Change criteria

Examples:

· Run a SQL data update/insert/delete - backup is always required and should be kept for a period of one month

· New access requests (RDC, VPN, etc.) or changes to access rights

· Update a configuration file (e.g. session timeout) - not a code or database change

· Adding a new JMS queue

· Importing a certificate to trust store

· SFTP account request

· Development environment local firewall change

· Environment Refresh/Back flow of database or code (e.g. PROD > TEST)

Normal (Non-BAU) Changes

Key Requirements:

· Approval process must be followed and includes a minimum of 2 levels of approval - Change Manager and CDS Management

· Evidence of testing required

· Lead time is expected for scheduling

· Changes require verification prior to closing

Criteria:

· Non-standard operational change

· Impacts more than 1 client environment

· Changes to IBM® Bluemix (SoftLayer®) infrastructure

· Change to Application (Maximo® or TRIRIGA®) code

· Cost implications - additional servers or capacity

· Security implication

· Shared infrastructure update

Examples:

· Adding disk capacity to a server

· Adding a VPN or NAT/Firewall configuration

· Deploy a custom class file or other code

· Application upgrades or patches

· Installation of add-ons or 3rd party software - confirm license entitlements

· Scheduling system level jobs/crons

· Application or database upgrade (major release such as Maximo Application or TRIRIGA platform upgrade)

· Operating system or middleware patching

· Security vulnerability patching

Emergency / Retrospective changes

An emergency change is one that must be done immediately. It is of a very high priority. An example of an emergency change might be the installation of new antivirus software during a period of severe viral infestation across the data center. Emergency changes are ones that are typically not performed often. An emergency change contains all of the process steps and requirements that are followed for a Normal change but the phases can be expedited outside of the normal change cycle.

Retrospective changes are change records raised after changes have been implemented. Retrospective changes can only be raised to accommodate emergency change in 2 key scenarios:

• With prior approval from the IBM SRE Management Team by SMS text message or email

• In response is incidents where client system availability is impacted and change is required to resolve the issue in a production system.

Increase to system capacity (Disk, CPU or RAM) are included in this scenario

Both the Emergency and Retrospective Changes will follow the same process in the change management system and will have a change type of Emergency. Retrospective changes differ in the fact that they are created after the change is performed. The criteria for an Emergency / Retrospective change is the same as a Normal change.