Purpose
This policy establishes the requirements for EventHub to manage changes in digital assets including but not limited to Software, Infrastructure, Databases, Networks, Platforms. Purpose of Change Management policy to ensure that all changes in Event Hub are properly analyzed, approved, completed, and reviewed with minimum impact on business, systems, and customers.
Scope
This policy applies to all components including but not limited to source code, scripts, libraries, and other supporting artifacts including documents and other explanatory material that might help in better understanding of the current codebase.
EventHub uses Software Development Life Cycle (SDLC) as its core development process and all requirements including new features, enhancements and bugs are treated in the same way.
EventHub utilizes industry best practices for the management of changes and thus uses top-of-the-line tools for version control and documentation.
Change management is responsible for managing change process involving:
· Hardware
· Communications equipment and software
· System software
· All documentation and procedures associated with the running, support, and maintenance of live systems.
Terms and Definitions
Change can be
· Any implementation of new functionality
· Any interruption of service
· Any repair of existing functionality
· Any change in networking functionality
· Any removal of existing functionality
Normal Change is a change activity that doesn’t require any immediate actions and is planned well before the time. Normally changes may include the addition of new features and enhancements in existing functionality. Minor bugs that don’t affect the business function or don’t pose any critical impact on the system can also be considered as a normal change.
Emergency Changes are mostly unplanned and require immediate attention. These may include a situation where a security breach is identified or any bug has been highlighted that could possibly impact the business, users, or system. Due to the nature of the Emergency Change Request, verbal approval is also granted to minimize the downtime.
Request for Change (RFC) / Change Request (CR)
Request for Change (RFC) or Change Request is a request that is raised by a user within an organization to carry out an activity in the existing landscape.
Change Owner / Requestor
Requester/Change Owner is the one who raises a Request for Change (RFC). He may or may not perform the activity himself but he’ll act as a point-of-contact (POC) for any communication pertaining to progress, impact, or cancellation of that change request.
Impacted Entities
Impacted entities can be Business Units, System Components, and even Customers who would be impacted as a response to these activities.
Stakeholders
Stakeholders are the people whose support would be needed to carry out the change. Stakeholders should be intimated about the change request. In some cases, stakeholders may also need to approve the change request.
Change Approval Board
Change Approval Board (CAB) is a group of people who’ll be approving the changes after understanding the context, scope, and impact of any change. CAB has the final authority to approve/reject any change request.
For Event Hub, CAB consists of Head of Development (CTO) and COO (Chief Operations Office)
Policy
Classification of Change
Each change should be properly classified in the below categories. This classification should be done on basis of different parameters including (but not limited to), Priority (Urgency) of the Change, Impact on Business, Customers, and Solution.
Together these factors should help in the right classification of a change. Each change should follow a set of predetermined timelines.
Requests for Change must be raised at least at X days before the scheduled change management time.
For Emergency Change Requests, there is no limit to which the request should be raised. But it should require approval from CAB either verbal or in written form.
Request for Change (RFC)
Once the change has been classified, it should be properly logged as a Request for Change(RFC). The request should contain but not limited to
o Details and Scope of Change
o Details of the Changes required (it should contain a reference number for respective features, bugs, or other tasks).
o Classification of Change (Normal, Emergency)
o Impact (None, High, Medium, Low)
o Priority (High, Medium, Low and Normal)
o Expected Date and Time to start the Change
o Expected Date and Time to Finish the Change
o Description of Expected Impact
o Reason for Change
o Support Required
o Any Pre-Requisites
o Rollback plans to ensure that changes can be reverted if things don’t go as planned.
o Change Owner (the one who is accountable for the change, he’ll be the first point of contact in case something goes wrong or to get any updates).
Pre-Requisites and Required Support
It should be ensured to provide enough details in the change request to identify any required support and pre-requisite for the change. If any pre-requisite is not fulfilled that could possibly hinder the completion of the request, the activity should be rescheduled and should also require another approval cycle.
Action Plan
Each change request should contain a plan or set of activities to explain the necessary steps that are to be taken. These steps will help the stakeholders and approvers in making their decision earlier. Any issues in the plan can also be highlighted in the approval cycle and requests can be amended to confirm that all possibilities have been properly analyzed.
Amendment in Change Request
Any amendments in the Change Request should be treated as a new change and would require another approval cycle.
Change Request Approval
Each Change Request should require formal approval before it can be executed. This approval is given by different key stakeholders and the Change Approval Board (CAB).
In some scenarios, where the impact is ‘None’ it may not require any approval from CAB.
If any of the stakeholders/approvers have any concerns, the change shouldn’t be approved until all concerns have been addressed.
Every change requires approval from respective stakeholders and the Change Approval Board (CAB). Change requests should be submitted well before the time to get timely approvals from all stakeholders and CAB.
In case of emergency, when there is no time to get the approval hierarchy and follow the agreed SLA. In such a scenario, a verbal and preferably written approval (email, SMS, or any other form of communication should be taken from the key stakeholder to minimize the risk).
Once the Change has been closed, a proper Change Request should be logged and later approved by respective persons for reporting and documentation purposes.
Communication
Communication should be maintained between different stakeholders to ensure that changes are executed and validated in a streamlined manner.
Notifications for Change
All changes should be communicated before, during, and after their implementation.
For any change, that may directly impact the customer/business, a formal notification SMS/Email or both should be sent to Customers and other business stakeholders.
For changes, that cause a huge impact and were not planned should be intimated to VIP or main customers via Phone Call to inform them in a timely manner. Customers should also be informed about the status of the change till the issue is not resolved.
Logs of Change Request
Logs of change requests should be properly maintained for each step during the planning, approval, execution, verification/review, and closing phases of a change. These logs should contain at least but not limited to
· any additional comments from approvers
· a brief description of steps performed
· supporting documents/ logs or images to show the actual execution status.
Conducting the Change
Once the change is approved, respective stakeholders and impacted users/customers should be notified about an upcoming change.
These notifications should also contain the contact details of Change Owner/ Customer Support to ensure that customers have the right information to report any abnormality.
Fallback (Rollback Plan)
Each change should be complemented with a mandatory fallback or rollback plan. This is needed to ensure that any unforeseen situation could be avoided and to ensure that the impact on business, customers, and systems is minimized.
Reviewing the Change
Once the change has been completed, it should be reviewed or kept under observation before it is marked as Completed.
Any change that requires few days to observe/monitor should also have the status for Review.
This also closely relates with Release Management, where a change is moved to Production after keeping it under observation for a couple of days.
In any case, the status of the Change Request should be properly updated indicating if the activity was fully or partially completed and was it a success or a failure.
Reporting
Reporting is very crucial to see the performance of a change. Once the change has been completed it's important for the Change Manager to confirm and report that proper timelines were followed and there was no impact due to that change.
In case of any impact, that was not foreseen in the initial plan, a proper root cause report should be rendered to impacted business stakeholders and the change approval board to inform and notify them of the exact issue.
Service Level Agreements (SLA)
Each Change Request should have a time window to perform it. In addition, the time taken to raise, approve, and then review the change should also be logged.
Later these timestamps should be available to determine the Service Level Agreements (SLA) between different stakeholders as well as towards customers.