Change management (CM) is the end-to-end process that governs the lifecycle of a change from the initial request for change to the final deployment and communication of the change. As you consider which changes in your Splunk implementation warrant CM oversight, use CM guidelines to define the steps, activities, and the roles and responsibilities involved in making changes. Using CM to govern changes in your Splunk environment may provide the following benefits:
- A documented, defined process to authorize and deploy changes in your Splunk environment
- An awareness and a common and visible method to address changes
- An ability to respond to issues by providing a record of change to support platform health and troubleshooting
These best practices are for users with the following roles. See Setting Roles & Responsibilities for a Splunk deployment for more details.
- Executive sponsor
- Program manager
- Project manager
Because every organization is unique, how they implement CM can vary. CM guidelines provide a best-practices framework and tools to help define and develop the CM processes that fits unique needs and requirements.
Differentiate between change management and change control
Change management (CM) encompasses the entire change lifecycle. Change control is a procedure within change management that focuses on specific steps and activities to ensure that releases and deployments do not conflict with production components. Critical and time-sensitive platform changes, such as security patches, often lead directly to change control. As a result, change control has a higher level of risk that organizations typically accept.
Change management framework
The change management (CM) framework is a set of components to help design and implement change management. This framework design allows for structure and flexibility so you can build a new CM process or incorporate into an existing CM process.
However, with flexibility comes the opportunity for an endless cycle of variation. Consider a moderate or limited approach that can evolve with use and experience. The CM framework includes guidelines to define these elements of the change lifecycle:
- CM scope
- CM process
- Responsibility assignment matrix
- CM pathways
- Change guidance examples
Know the scope of your change
Because a change management (CM) process deals with the management of changes, you must have a common understanding of which changes are in the scope of the process. This section describes areas that are both in and out of the CM process scope. The examples are intended to spur thought so that you can engage in conversations to define what scope is best for your organization.
The scope of the CM process covers all production systems and platforms in your organization.
The primary functional components covered in the CM process can include the following examples:
- Changes handled through the formal software development lifecycle
- Installing, modifying, removing, or relocating computing hardware equipment
- Installing, patching, upgrading, or removing software products, including operating systems, access methods, commercial off-the-shelf (COTS) packages, internally developed packages, and utilities
- Changes to system configuration, including moves, adds, changes, and deletions
- Promoting application changes to production, integrating new application systems, and removing obsolete elements
- Changes to system configuration, including moves, adds, changes, and deletions
- Creating, deleting, or revising job schedules, back-up schedules, or other regularly scheduled jobs managed by the company's IT organization
Out of scope
Routine operations and the administration of your Splunk environment are outside the scope and governance of the CM process. Identify and document these activities as out of scope to maintain operational efficiency.
Out-of-scope operations can include the following examples:
- Contingency or disaster recovery
- Changes to non-production elements or resources, such as changes in test environment
- Changes under the governance of large-scale projects or initiatives that have a separate CM process
- Changes made within the daily administrative process
Out-of-scope daily administrative tasks can include the following examples:
- Password changes or resets
- User adds or deletes
- Adding, deleting, or revising security groups
- Rebooting machines when there is no change to the configuration of the system
- File permission changes
Define your change management process
Change management (CM) is a sequence of process steps with associated activities that you follow to govern a change and ensure an intended outcome. The primary goal of the CM process is to ensure that organizations follow standardized methods, processes, and procedures to efficiently and promptly handle changes. The CM process is grouped into two distinct phases: the approval phase and the execution phase.
Define the process steps and associated activities you want to include in your CM process. Use the CM pathways to select which CM process steps and activities you want to implement for a given change. Think of the CM process as the checklist for defining each change pathway.
The approval phase has steps and activities you must do to support the decision-making and authorization activities for the change. Review the purpose for each step in the following table and download the change management process template at the bottom of this article to see example activities you can use to fit the CM needs in your organization.
|1.0||Identify change||Identify the change and the reason for the change.|
|1.1||Qualify change||Provide the information and details needed to allow the change to move forward in the CM process.|
|1.2||Request change||Formalize the change request and capture all information and details to allow all downstream participants to complete the required activities.|
|1.3||Triage change||Determine how the change request needs to proceed. For example, if there is not enough information, request more details from the individual that initiated the change request.|
|1.4||Analyze request||Review all information and details needed to make an informed decision. This step includes participation from subject matter experts for both business and technology.|
|1.5||Request approval||Approve or reject the change request. This step includes participation from the appropriate stakeholders and groups.|
|1.6||Request implementation||Send the approved change requests to the execution phase.|
|1.7||Request close out||
Communicate the decision to the individual that initiated the change request. Also update and archive the related documentation.
The execution phase has steps and activities that you must do to build and deploy the change. Review the purpose for each step in the following table and download the change management process template to see example activities you can use to fit the CM needs in your organization:
|2.0||Planning||Estimate the people, effort, timing, expertise, and costs required to support the change.|
|2.1||Analysis||Review the change request and documentation to determine the technical requirements to support the change.|
|2.2||Design||Identify the best technical approach and design to fulfill the change.|
|2.3||Implement||Complete the change.|
|2.4||Test||Verify the change works properly.|
|2.5||Deploy||Apply the change to the production environment.|
|2.6||Close out||Communicate the status of the change to all stakeholders and appropriate groups. Also update and archive the related documentation.|
Develop your change management RACI matrix
The Responsible, Accountable, Consulted, and Informed (RACI) matrix defines the participation requirements for various roles to complete tasks or deliverables in a change management (CM) pathway.
The individuals who do the work to complete the task. At least one takes on the responsible role, although others can assist in the work required.
The individual who is accountable for the outcome. The accountable role ensures all prerequisites are met and delegates the work to the individual in the Responsible role. Assign only one Accountable role for each task or deliverable.
The individuals whose opinions are sought. Individuals in the Consulted role are typically subject matter experts engaged in two-way communication.
The individuals who are kept up to date about the task. Individuals in the Informed role are alerted to the completion of the task or deliverable, and generally engage in one-way communication.
A role and an individually identified person are two different things. A role has an associated set of tasks that can be performed by many people. An individually identified person can perform many roles. For example, an organization may have 10 people who can perform the role of system administrator, and one person who can perform the role of system administrator can also perform the role of developer. Assign only one participation type for every task or deliverable per role in the CM pathway. For more information, see Managing data based on role.
Define your change management pathways
A change management (CM) pathway identifies the steps and activities from the CM process and defines the roles from the CM RACI matrix. For example, changing a source type definition can have a significant impact on data ingestion, which can impact many business processes, so multiple parties need to analyze and approve this type of change. In contrast, a change to a dashboard panel doesn't require the same level of analysis or approval because it doesn't affect business processes.
Keep the quantity of CM pathways to a manageable number. Start with a smaller set and expand as you learn how your organization addresses change. Define default CM pathways to use for multiple scenarios.
Do the following items to define your CM pathways:
- Create change guidance examples for a set of change categories
- Use the CM process to identify the process steps for each change category
- Use the CM process to select the appropriate activities within each process step
- Use the CM RACI matrix to define the roles and select the responsibilities for the participants for each change category
- Identify your deployment requirements, for example Dev-Test-Prod promotion, and segregation of duties
CM pathways provide the flexibility to address various change scenarios and improve overall efficiency. Define several CM pathways to accommodate all change categories in your organization.
Consider defining a CM pathway for situations when a user submits a change request, but they are unsure of the change category or the request is in or out of the CM scope.
Timing can be critical to a business situation, so it's important to maintain a flexible CM framework. You need to be comfortable with temporarily altering an existing CM pathway to fit a business need instead of defining a new CM pathway. For example, to expedite a change request, you may need to streamline the approval phase to get to the execution phase.