Achieve Infrastructure Change Agility

Transcription

1 USE CASE SCENARIO Using ITinvolve to: Achieve Infrastructure Change Agility

2 The Business Challenge IT infrastructure and Operations organizations are under tremendous pressure to execute changes faster while also minimizing (or even eliminating) risk. As if this objective wasn t challenging enough, IT complexity is increasing at a rapid pace. Making matters worse, IT often relies on scattered and tribal knowledge about their environments, which means critical information can be overlooked and critical stakeholders left out. That s why achieving the objective of infrastructure change agility with low risk is getting harder every year and why most IT organizations can point to the fact that 80% of their service-impacting issues are as a result of well-intentioned changes that have unintended consequences. Through 2015, 80% of outages impacting mission-critical services will be caused by people and process issues, and more than 50% of those outages will be caused by change/configuration/release integration and hand-off issues. R. Colville and G. Spafford, Top Seven Considerations for Configuration Management for Virtual and Cloud Infrastructures, 27 October 2010 Despite a lot of investment in process and automation tools, these challenges remain. We believe that harnessing your people s IT knowledge and combining it with visual analysis and collaboration is the key to avoiding unintended business impacts from changes and reducing unplanned work. How ITinvolve Can Help Only ITinvolve brings together knowledge, analysis and collaboration in one solution to: Visually assess change impact and risk across infrastructure, services, policies, and more Identify and proactively engage all relevant stakeholders and experts Automatically promote key settings, tribal knowledge, and other often overlooked information With ITinvolve, you will: Execute changes faster Identify and minimize business risk Increase change throughput Reduce unplanned work from IT changes Improve IT performance, reliability, and security Increase change success rate 1

3 The Scenario A large enterprise company has hundreds of databases that support their business critical applications. Some of these databases run in company-owned and staffed datacenters while others run in the cloud (especially development and test instances). In this scenario, Microsoft has just recently issued a security patch for MS SQL Server, and the database team has proposed a change to roll out the patch across over a hundred different database instances. Patty McGee is the change planner assigned to manage the change, and John Hopkins is the DBA team lead responsible for MS SQL Server management. While this scenario focuses on a database infrastructure change, the approach and value applies equally to manage other frequent and common infrastructure changes such as updating of firewall settings, rolling out new virtual machines, upgrading or replacing server or storage hardware components. In short, all of the many hundreds or thousands of infrastructure changes that take place in an enterprise IT organization every week and that result in business impacting incidents far more often than IT or the business would like. What Happens Without ITinvolve Following a traditional approach, Patty would likely create a change record in her change process management system. If that system also includes, or works with, a Configuration Management Database (CMDB) she may have also added the Configuration Items (CIs) for each of the SQL Server databases to the change record. Most likely she would have then added John to the change as a stakeholder, and then called a meeting with John and as well as anyone she knew who might have a vested interest in the change (e.g. she knows that the company s business intelligence reporting system uses a MS SQL Server database so she invites the administrator responsible for it as well). In the meeting, Patty, John, and anyone else who was invited (and actually had time to attend) strategize about the change, what they thought the potential impacts were, and then following the meeting she likely updated the change record with the summary from the meeting and added a few more stakeholders to the change record. Perhaps there were several more meetings over the following days or weeks as the group expanded to include others that might have a potential interest with some being able to attend the meetings and some who were not. Patty may have also sent out an blast to an even wider group of potentially interested parties to ask them for their inputs and any risks they might see, and this probably spawned multiple other threads and hallway conversations across the organization. Some of those involved may have even had access to the CMDB to leverage the dependency relationships modeled there when providing their risk assessment. 2

4 Finally after many days or even weeks, Patty and John summarize what they found from their research and prepare their findings for the Change Advisory Board (CAB) meeting coming up the following week. The day finally arrives for Patty to present her recommendation on the MS SQL Server patch, the risks, the mitigation strategy, and the planned time for implementation. The CAB thoughtfully considers the request for several minutes, and then one member asks Patty whether a key resource in the storage team has been included in the risk assessment. Patty responds that he has not been and asks why they would be relevant to the decision. The CAB member explains how earlier in the meeting they had just approved a request to upgrade a Storage Area Network (SAN) device for the same day as Patty s change and how that might include one or more SQL database instances with the risk of a conflict if the two changes are performed at the same time. Patty makes a note of this and agrees to follow up with the storage expert, and her change approval gets rescheduled for the next CAB meeting in a week. Meanwhile, the security holes that are closed by the patch remain open. A week later, Patty confirms that the change plan has been adjusted so the SAN upgrade will be completed first before the patch is applied to the dozen or so SQL instances running in the SAN. Finally, after all this effort, the change takes place. Everything appears to go as planned, with the automation of the patches executing on time across all databases. Then an hour later, the head of Service Support calls Patty, Something has gone wrong, he says. We are getting calls from folks in the Finance department that the reports they run daily aren t accessible or are timing out. What changes have you been making recently? he asks with barely muted anger in his voice. Patty replies, We ve recently applied a security patch to our SQL Server databases. We thought we had identified all the risks and accounted for them. Obviously, we haven t. I ll get on this right away and get back to you as soon as I can. How Change Risks are Identified and Avoided with ITinvolve With ITinvolve, Patty still creates the change record in her company s change process management system. However, she now uses ITinvolve to identify the right stakeholders and engage them in a collaboration process to quickly and accurately assess risks and identify mitigation strategies. First, Patty defines a Scenario in ITinvolve for the MS SQL Server patch, and then she works with John to create an initial set of associations with each MS SQL Server instance that s been defined in ITinvolve by John s team. Using this information, and the relationships between the SQL Server instances and other objects in ITinvolve (such as physical servers, SANs, applications, policies and business services) she can instantly see a list of recommended stakeholders. She can then add other stakeholders as needed (including relevant business stakeholders such as the IT point of contact in the Finance departments) and publish the Scenario for collaboration. Figure 1: Visual Impact Analysis in ITinvolve 3

5 Each Stakeholder then is notified through , the ITinvolve application, or their ITinvolve mobile app that there is a new Scenario awaiting their risk assessment. Using the visual impact analysis in ITinvolve, each stakeholder can quickly and easily see the potential upstream and downstream impacts of the patch, they can also investigate pertinent impact factors such as policies that might be affected by the change, relevant knowledge articles, as well as key settings and captured tribal knowledge about non-standard configurations and best practices accumulated in the organization. Everyone s risk assessment is logged in ITinvolve and each stakeholder is automatically notified of what the other stakeholders recommend. If there are questions, they can engage one another for clarification right in ITinvolve helping to keep a log of their discussion for future reference and audit purposes. Using this approach, each stakeholder can engage at a time and place that s convenient for them instead of trying to get everyone together at the same time and place which could take days or weeks to accomplish. What s more all stakeholders are proactively engaged so no key contributors are accidentally overlooked and no one s key input is left out because a meeting was missed. After everyone has provided their risk assessment, Patty and John prepare the consensus recommendation in ITinvolve including the need to schedule the patch to take place after the SAN upgrade. They also document that the Finance department s reporting application requires some nonstandard configuration settings which will need to be reset after the patch because they will be overwritten during the patch process. In the CAB meeting, the committee members review the recommendation Patty and John have prepared as well as the risk analysis and mitigation strategies. No objections are raised and the patch is scheduled for the following day. What would have taken four to eight weeks using their old method (and still resulted in a negative business impact) was accomplished in less than a week using ITinvolve, resulting in no negative business impact and no unplanned work in IT to resolve it. Figure 2: Access to Relevant Impact Factors in ITinvolve Figure 3: Stakeholder Risk Assessment in ITinvolve 4

6 Summary of Benefits BUSINESS Significant reduction in negative business impacts from IT infrastructure changes More reliable IT services IT LEADERSHIP Significant reduction in negative business impacts from IT infrastructure changes Ability to rollout necessary infrastructure changes faster (to improve performance, reliability, and security) Ability to handle more infrastructure changes with same staff Reduction in unplanned work from IT changes (so resources can remain focused on other priorities) IT PROFESSIONALS Easy access to relevant, accurate and trusted information when evaluating the risks from IT changes Ability to collaborate virtually with other stakeholders and at a convenient time and place Reduced time spent fixing problems caused by changes Going Further with ITinvolve for Change Management ITinvolve can also be your change process management system. In addition to the benefits described above, we can record, analyze, assess risk, and handle all approvals for your changes including facilitating virtual CAB meetings to further accelerate your infrastructure change agility. Learn More Explore more resources on the problems we solve at or us at info@itinvolve.com to discuss how ITinvolve can help you improve infrastructure change agility. MAIN FAX WEB info@itinvolve.com 2925 Briarpark Drive Suite 270 Houston, Texas Briarpark Drive Suite 270 Houston, Texas 77042