"What we got here is... failure to communicate."
-- Captain of Road Prison 36, Cool Hand Luke (1967)
I am noticing more and more frequently these days that the term "DevOps" is being used to describe a staff position or department and sets of tasks that can best be described as deployment configuration management and automation. The role seems to have been derived from so much confusion that has come out of a mixing of the heavily related Continuous Delivery, Infrastructure-as-Code, Service Engineering, and DevOps movements that have been swirling around in various forms for the last several years. While it is difficult to talk about any one of them without referring to elements of another, the fact that they have all somehow been combined into a new job family is not only disconcerting, but may potentially represent a general misunderstanding of the larger issues that exist between IT and the rest of the business.
Businesses constantly seem to be struggling to come to grips with the constant changes that are happening across the business, especially in IT. Business leaders barely had come to grips with the whole concept of the Internet, Just In Time manufacturing techniques and multimodal telecommunication methods when suddenly the Agile and Lean movements, Continuous Integration, virtualization, elastic computing, and on-demand software services arose. Each of these innovations has demanded significant changes to interactions, behaviors and understandings of people across the organization. In return they deliver ever faster and ever cheaper ways of innovating and serving the market.
Mainstream businesses have struggled to understand many of these concepts, and are only now beginning to seriously make many of the necessary steps to adopt them. Few have gotten far enough along to really effectively handle them while also absorbing the next wave of change that is already on top of us. This next wave includes not only the significant changes at delivery and run that come with Continuous Delivery, Infrastructure-as-Code, and Service Engineering, but also more advanced topics such as the flows and collaboration required to actually achieve what is aspired to in DevOps, the complete mindset change that comes with Outcome Delivery in the Product Development space, and changes arising in the legal contract and financial spaces. This next wave is building upon the knowledge, learning and expertise created by successful pioneers from the earlier wave.
Anyone who has made significant inroads into these next wave approaches knows that true power in them requires proficiency if not mastery of earlier concepts. Continuous Delivery is not terribly effective if neither Continous Integration or the short iterations of Agile methods are in use. DevOps is really the next step in collaboration. It further blurs the remaining team boundaries to eliminate any remaining friction and gaps in roles and responsibilities that negatively affect service health and continuous improvement. It simultaneously shores up and strengthens the professional rigor that once organizational boundaries tried to uphold. The mindsets that are established in the earlier movements, such as frequent and rapid adaptation to feedback and working collaboratively in cross functional teams, are all important prerequisites.
Businesses are finding themselves in an uncomfortable spot. They are realizing that they need to make massive changes in order to stay competitive. Yet so few people within their ranks properly understand these new ideas enough to effectively implement the changes required by them. There just simply doesn't seem to be a nice and neat place to handle this sort of change in the traditional organization.
So they create one.
In the past some companies simply made the move to outsource their IT in the hopes that the problem can become that of their outsourced partner. Some may still opt for this option in light of these challenges. This often only makes the problem larger by putting entire corporate entities and business profit models between IT and critical business functions. Many of these companies have learned that IT is in fact a critical capability within their business, one that can only effectively be outsourced when doing so neither impedes business change nor lets go of the company's value add in the marketplace in a way that leaves the business completely hostage to the outsourcer.
Perhaps it is worthwhile to look deeper into the industry to see what is going on.
Much like the mess that is "Cloud Computing", the term seems to be pervading ever further across the industry, to the point where it is being used so frequently that otherwise intelligent people are starting to give in and use it to get a point across.
By packaging "DevOps" into a nice compartmentalized role in the organization, many businesses seem to be tipping their hat to the problem and hoping that filling those roles will somehow accomplish what is needed with little additional need for change. This is similar to the relatively recent fallacy that buying VMWare and virtualizing your legacy server estate will allow them to avoid the legacy architecture headaches and somehow give the organization "Cloud Computing". These water down not only the meaning of the movements, but also provide fodder for those who are actively resistant to change by creating compromising stillborn half measures they can point at to say they aren't real.
Having been brought in time and time again to sift through the damage and placate the injured in such poorly implemented change efforts, I hope that this half-baked compartmentalized trend will somehow reverse and not damage yet again another great set of ideas.
Businesses constantly seem to be struggling to come to grips with the constant changes that are happening across the business, especially in IT. Business leaders barely had come to grips with the whole concept of the Internet, Just In Time manufacturing techniques and multimodal telecommunication methods when suddenly the Agile and Lean movements, Continuous Integration, virtualization, elastic computing, and on-demand software services arose. Each of these innovations has demanded significant changes to interactions, behaviors and understandings of people across the organization. In return they deliver ever faster and ever cheaper ways of innovating and serving the market.
Mainstream businesses have struggled to understand many of these concepts, and are only now beginning to seriously make many of the necessary steps to adopt them. Few have gotten far enough along to really effectively handle them while also absorbing the next wave of change that is already on top of us. This next wave includes not only the significant changes at delivery and run that come with Continuous Delivery, Infrastructure-as-Code, and Service Engineering, but also more advanced topics such as the flows and collaboration required to actually achieve what is aspired to in DevOps, the complete mindset change that comes with Outcome Delivery in the Product Development space, and changes arising in the legal contract and financial spaces. This next wave is building upon the knowledge, learning and expertise created by successful pioneers from the earlier wave.
Anyone who has made significant inroads into these next wave approaches knows that true power in them requires proficiency if not mastery of earlier concepts. Continuous Delivery is not terribly effective if neither Continous Integration or the short iterations of Agile methods are in use. DevOps is really the next step in collaboration. It further blurs the remaining team boundaries to eliminate any remaining friction and gaps in roles and responsibilities that negatively affect service health and continuous improvement. It simultaneously shores up and strengthens the professional rigor that once organizational boundaries tried to uphold. The mindsets that are established in the earlier movements, such as frequent and rapid adaptation to feedback and working collaboratively in cross functional teams, are all important prerequisites.
Businesses are finding themselves in an uncomfortable spot. They are realizing that they need to make massive changes in order to stay competitive. Yet so few people within their ranks properly understand these new ideas enough to effectively implement the changes required by them. There just simply doesn't seem to be a nice and neat place to handle this sort of change in the traditional organization.
So they create one.
In the past some companies simply made the move to outsource their IT in the hopes that the problem can become that of their outsourced partner. Some may still opt for this option in light of these challenges. This often only makes the problem larger by putting entire corporate entities and business profit models between IT and critical business functions. Many of these companies have learned that IT is in fact a critical capability within their business, one that can only effectively be outsourced when doing so neither impedes business change nor lets go of the company's value add in the marketplace in a way that leaves the business completely hostage to the outsourcer.
Perhaps it is worthwhile to look deeper into the industry to see what is going on.
Much like the mess that is "Cloud Computing", the term seems to be pervading ever further across the industry, to the point where it is being used so frequently that otherwise intelligent people are starting to give in and use it to get a point across.
By packaging "DevOps" into a nice compartmentalized role in the organization, many businesses seem to be tipping their hat to the problem and hoping that filling those roles will somehow accomplish what is needed with little additional need for change. This is similar to the relatively recent fallacy that buying VMWare and virtualizing your legacy server estate will allow them to avoid the legacy architecture headaches and somehow give the organization "Cloud Computing". These water down not only the meaning of the movements, but also provide fodder for those who are actively resistant to change by creating compromising stillborn half measures they can point at to say they aren't real.
Having been brought in time and time again to sift through the damage and placate the injured in such poorly implemented change efforts, I hope that this half-baked compartmentalized trend will somehow reverse and not damage yet again another great set of ideas.
No comments:
Post a Comment