DevOps is not a technology issue. DevOps is a business issue. (transfer)
Damon Edwards / November 8, 2010
From the moment Patrick Debois organized the first DevOps Days conference and revealed to the world the term “DevOps” there can be no doubt that DevOps has evolved to the level of a global movement.
Of course, the DevOps movement has its detractors. Negative opinions vary from erroneous (“DevOps is a new name for system administrators”) and disparaging (“DevOps are just some crazy developers (Devs) who are trying to get rid of admins (Ops)” or “DevOps are some crazy admins who want to appear as developers to be loved more ”) before hurt expressions (as a rule, with arguments that are not logic).
')
About the last nine months, I had to overcome the resistance of the DevOps movement both in public forums and within client companies. And during this time, I began to notice a common misconception, and it seems to me that it feeds most of the negative reaction to DevOps ideas. And now I want to try to clarify this common misconception:
DevOps is not a technology issue.
Technology plays a key role in creating solutions to the problems that DevOps is trying to solve. However, DevOps, by definition, is a business problem.
What does business have to do with DevOps?
The underlying business process in any company is to take the idea from the moment of its birth in your head and bring it to the place where it will bring money.
Within this business process, many kinds of different activities take place that are needed for the idea to be realized. Some of these activities are driven by technology, and some are dependent on people. At this point, IT begins to play its role: developers, testers, architects, release engineers, security specialists, people from service, and others — they all do their part in this general process of implementing an idea.
But if you remove the context of the business process, what will you have in the end? You have a bunch of people and different groups doing something on their own and living their own lives. You lose a real incentive to deal with inefficiency, unnecessary processing, conflicts, and lack of communication between these groups. In a literal sense, we get a situation where everyone is for himself.
Do you know what else will happen if you remove the context of the business process? Over time, you lose your job. Only due to the fact that we give an opportunity to work to a business, we get a salary and the opportunity to do what we do.
If there is no business itself or we do not allow this business to implement its ideas, all our work turns into nothing more than a simple hobby. And, by its definition, it is quite difficult to get a salary for a hobby.
The whole point of DevOps is precisely to enable businesses to respond to market forces as quickly, efficiently and reliably as possible. Without a business, we have no other reason to talk about DevOps problems, and there’s no point in addressing them at all.
Doesn't this look like an agile target?
If the goals of DevOps look similar to Agile goals, it is because they are actually similar. But Agile and DevOps are different things. You can perfectly build Agile development, but, nevertheless, have a lot of DevOps problems. On the other hand, you can cope well with eliminating DevOps problems without using the development according to Agile principles at all (although this is rather unlikely).
I like to describe Agile and DevOps as two related ideas that take common roots from the Lean methodology, but work at different levels. While Agile focuses on improving one IT function (software delivery), DevOps is working to improve the interaction and operation of all IT functions (covering the entire product life cycle: from development to maintenance).
But I thought DevOps was about cool tools?
Technology makes it possible to make almost any business process more efficient, scalable and reliable. However, we must remember that the tools themselves are just tools.
With the same probability you can use a tool to improve your organization, you can use a new tool to reinforce bad habits and old non-working processes. The best way to use a tool is determined by the effect its use will have on the business process you support.
When people clearly understand what their DevOps problems are and what particular improvements in workflows must occur in order to fix these problems, then talking about tools becomes quite simple (if not obvious).
Since the nascent DevOps movement mainly consists of engineers, it is easy to understand where such excitement comes from immediately immerse into the discussion of tools. But maybe we need to make more efforts to make sure that everyone has sufficiently understood and understood why these or other tools are needed and what are the desired improvements in the business process before plunging into the usual disputes “Puppet vs. Chef or Files Centric vs. Package Centric.
If DevOps is about business processes, then why is it called “DevOps” at all?
In my opinion, one of the mistakes of the early talks about DevOps was that it was not immediately clear how large the scale of the problem was about. Now that we have a year of experience behind our shoulders, it becomes clear that we are working on one of the biggest business problems: how to give businesses the opportunity to respond to market forces as quickly as possible.
This conversation was supposed to begin somewhere, and, alas, it was to the discussion of the general problem of conflict and the lack of communication between the developers (Dev) and exploitation (Ops). The organizational structure of each company is different, but, nevertheless, one can quite easily caricaturely divide the world into a Dev-camp and an Ops-camp and, thus, have common guidelines for discussion (although we understand that the world is much more complicated and not black -white).
In this caricature Dev / Ops example, the main focus of the DevOps methodology at an early stage was on improving the deployment process. And, since the change process makes up the lion's share of work in IT organizations, it was also a logical and natural place to start.
Perhaps Patrick should have called the first conference “BizDevQASecurityOpsCloudUsers Days” or “SolvingABroaderProblemThanAgile Days” ... But I doubt that someone would come.
From the moment Patrick Debois organized the first DevOps Days conference and revealed to the world the term “DevOps” there can be no doubt that DevOps has evolved to the level of a global movement.
Of course, the DevOps movement has its detractors. Negative opinions vary from erroneous (“DevOps is a new name for system administrators”) and disparaging (“DevOps are just some crazy developers (Devs) who are trying to get rid of admins (Ops)” or “DevOps are some crazy admins who want to appear as developers to be loved more ”) before hurt expressions (as a rule, with arguments that are not logic).
')
About the last nine months, I had to overcome the resistance of the DevOps movement both in public forums and within client companies. And during this time, I began to notice a common misconception, and it seems to me that it feeds most of the negative reaction to DevOps ideas. And now I want to try to clarify this common misconception:
DevOps is not a technology issue.
Technology plays a key role in creating solutions to the problems that DevOps is trying to solve. However, DevOps, by definition, is a business problem.
What does business have to do with DevOps?
The underlying business process in any company is to take the idea from the moment of its birth in your head and bring it to the place where it will bring money.
Within this business process, many kinds of different activities take place that are needed for the idea to be realized. Some of these activities are driven by technology, and some are dependent on people. At this point, IT begins to play its role: developers, testers, architects, release engineers, security specialists, people from service, and others — they all do their part in this general process of implementing an idea.
But if you remove the context of the business process, what will you have in the end? You have a bunch of people and different groups doing something on their own and living their own lives. You lose a real incentive to deal with inefficiency, unnecessary processing, conflicts, and lack of communication between these groups. In a literal sense, we get a situation where everyone is for himself.
Do you know what else will happen if you remove the context of the business process? Over time, you lose your job. Only due to the fact that we give an opportunity to work to a business, we get a salary and the opportunity to do what we do.
If there is no business itself or we do not allow this business to implement its ideas, all our work turns into nothing more than a simple hobby. And, by its definition, it is quite difficult to get a salary for a hobby.
The whole point of DevOps is precisely to enable businesses to respond to market forces as quickly, efficiently and reliably as possible. Without a business, we have no other reason to talk about DevOps problems, and there’s no point in addressing them at all.
Doesn't this look like an agile target?
If the goals of DevOps look similar to Agile goals, it is because they are actually similar. But Agile and DevOps are different things. You can perfectly build Agile development, but, nevertheless, have a lot of DevOps problems. On the other hand, you can cope well with eliminating DevOps problems without using the development according to Agile principles at all (although this is rather unlikely).
I like to describe Agile and DevOps as two related ideas that take common roots from the Lean methodology, but work at different levels. While Agile focuses on improving one IT function (software delivery), DevOps is working to improve the interaction and operation of all IT functions (covering the entire product life cycle: from development to maintenance).
But I thought DevOps was about cool tools?
Technology makes it possible to make almost any business process more efficient, scalable and reliable. However, we must remember that the tools themselves are just tools.
With the same probability you can use a tool to improve your organization, you can use a new tool to reinforce bad habits and old non-working processes. The best way to use a tool is determined by the effect its use will have on the business process you support.
When people clearly understand what their DevOps problems are and what particular improvements in workflows must occur in order to fix these problems, then talking about tools becomes quite simple (if not obvious).
Since the nascent DevOps movement mainly consists of engineers, it is easy to understand where such excitement comes from immediately immerse into the discussion of tools. But maybe we need to make more efforts to make sure that everyone has sufficiently understood and understood why these or other tools are needed and what are the desired improvements in the business process before plunging into the usual disputes “Puppet vs. Chef or Files Centric vs. Package Centric.
If DevOps is about business processes, then why is it called “DevOps” at all?
In my opinion, one of the mistakes of the early talks about DevOps was that it was not immediately clear how large the scale of the problem was about. Now that we have a year of experience behind our shoulders, it becomes clear that we are working on one of the biggest business problems: how to give businesses the opportunity to respond to market forces as quickly as possible.
This conversation was supposed to begin somewhere, and, alas, it was to the discussion of the general problem of conflict and the lack of communication between the developers (Dev) and exploitation (Ops). The organizational structure of each company is different, but, nevertheless, one can quite easily caricaturely divide the world into a Dev-camp and an Ops-camp and, thus, have common guidelines for discussion (although we understand that the world is much more complicated and not black -white).
In this caricature Dev / Ops example, the main focus of the DevOps methodology at an early stage was on improving the deployment process. And, since the change process makes up the lion's share of work in IT organizations, it was also a logical and natural place to start.
Perhaps Patrick should have called the first conference “BizDevQASecurityOpsCloudUsers Days” or “SolvingABroaderProblemThanAgile Days” ... But I doubt that someone would come.
Source: https://habr.com/ru/post/335368/
All Articles