{"id":2228,"date":"2020-03-01T06:26:13","date_gmt":"2020-03-01T05:26:13","guid":{"rendered":"http:\/\/siff.io\/?p=2228"},"modified":"2020-05-20T20:36:52","modified_gmt":"2020-05-20T18:36:52","slug":"change-management-infrastructure-operations","status":"publish","type":"post","link":"https:\/\/webdev.siff.io\/change-management-infrastructure-operations\/","title":{"rendered":"Change Management & Infrastructure Operations"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

<\/p>\n

Bridging the Two Worlds, Part 1<\/h2>\n

<\/p>\n

<\/p>\n

This is the first in a series of articles in which we will explore the opportunities that can be accomplished by connecting these two related, yet inherently disconnected worlds. The series will navigate the Operational Change Management Maturity Levels to provide a pathway towards reducing incidents and outages, and avoid inflicting unnecessary pain to ourselves.\u00a0\u00a0<\/p>\n

<\/p>\n

<\/p>\n

The series does not cover the change management process itself. There is plenty of content available that explores the change management discipline. We will explore what is limiting the benefits promised by the change management process from directly helping infrastructure operations; and how these challenges can be overcome.<\/p>\n

\u00a0<\/p>\n

<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"Operational-Change-Maturity-Levels\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

<\/p>\n

<\/p>\n

<\/p>\n

explores the change management discipline. We will explore what is limiting the benefits promised by the change management process from directly helping infrastructure operations and how these challenges can be overcome.\u00a0<\/p>\n

Level 1- Unaware<\/b><\/h2>\n

\u201cMore than 80% of all incidents are caused by planned and unplanned changes\u201d – Gartner<\/span><\/h4>\n

\u00a0<\/p>\n

Of all the wild claims we often hear from industry analysts, this particular one rings true. We could\u00a0 debate the percentage value, but the core essence of the statement is accurate. There\u2019s a reason why most industries that are highly dependent on their IT infrastructure and services such as financial services, retail, etc\u2026 go into a \u201clock-down\u201d mode during their seasonal peaks \u2014<\/span>making changes breaks things.<\/span><\/i><\/p>\n

But aren\u2019t we supposed to \u201cfail fast\u201d and \u201cbreak things\u201d now?<\/b>\u00a0<\/span><\/p>\n

Amazon, Google, and Netflix dominate because of their ability to innovate quickly. They adopted the “fail fast” mentality and created a culture that do not adversely penalize mistakes for the sake of innovation. This is often measured by the number of successful change requests. In some ways, the ability to promote changes and improvements directly correlates to their business agility.<\/span><\/p>\n

But how do you do this at scale? How does an organization reduce the risk and make more frequent changes manageable? Many look towards infrastructure as code or software-defined X as the goal. However as many developers can attest, just because it is “code” i.e releases are automated, does not eliminate the underlying issues. O<\/span>rganizations need to revise their perspective on what managing changes means to them, specifically the discipline and process required to reduce the risk. There are light-weight strategies teams can adopt to help avoid causing pain.\u00a0<\/span><\/p>\n

The good news is that software developers have been dealing with quality assurance for a very long time. The opportunity is in applying the lessons to help infrastructure operations.\u00a0\u00a0<\/span><\/p>\n

What does \u201cLevel 1- Unaware\u201d mean?<\/b><\/h2>\n

Here\u2019s the scenario:<\/span><\/p>\n