The biggest problem with DevOps is the name
Oleg Skrynnik, Managing partner at Cleverics; EXIN DevOps Master, ITIL Expert
Wikipedia starts with the statement that DevOps is a clipped compound of “development” and “operations”. Meaning it is a methodology that combines software development (Dev) with IT operations (Ops). Of course this is correct, if we are considering wording and spelling. Nobody will argue that the three first letters (or so) of each of the two words were used to coin the term:
Unfortunately, that is not enough to explain what DevOps really is and how to get the most out of it. DevOps is quite often perceived wrongly because of this very term. Let me explain the three views on DevOps that I’ve come across.
The first is a very simplified view
Let us think about Agile for the moment. It is a well-known fact that agile software development methodologies are aimed at solving the significant and difficult issues that come with communication, interaction and contractual agreements between two parties (the customer of software development and the software developers). Life would be much easier if it would be possible to have a fixed scope, requirements and funding to develop an IT system, internally or externally. In this case, the customer and developer could then sit together, discuss what is needed, put a formal contract in place with fixed price and specification(s). This could be in the form of an agreement between commercial entities or just a project charter for an internal IT provider. Then the developer can carry out the work, usually for several months, while the customer waits for the results. Of course they will have some interactions in the meantime. Though mostly to check up, and not to make any changes.
Finally, the developer will present a solution to the customer, get some minor feedback, fix some small things and get the payment they deserve. This is basically software development project management. So, this road is well-known to us. It’s something already learnt and that has been pretty much mastered in terms of knowing how to manage projects.
Though not anymore. In a modern world, the customer often knows very little about the final product he or she wants to get. So, we expect the requirements to change in the middle of a project, and they will most certainly change several times and quite dramatically. Moreover, these changes are very dependent on the feedback from the software product development process and usage. Feedback is an essential part to understanding the product, its limitations, possibilities, value to the end customer and so on. So, the more we develop – the more feedback we’ll get, and the more changes that will be required to the product being developed. It is not possible anymore to work using a fixed contract, otherwise the developer will never get paid for his or her efforts. A wall has been erected between the customer and the developer. One side needs to be able to influence the product in development on a weekly basis, while the other side needs to be left alone and do the work.
The solution, of course, is agile software development. With this approach, the developer works in small increments, delivering parts of the solution to the customer to get valuable feedback, and then change the course of development according to new requirements and ideas. Most of the teams will refer to these increments as “sprints”, appoint somebody from a customer side as “product owner”, gather every second week for a “retrospective”. This means we now have Scrum – not a bad idea at all, but not the only agile method either.
But what about operations in this scenario? Well, not to worry! Developers will have some people around to put the new version of software into the production environment. Several years ago, those guys from Operations were working slowly, with lots of manual work. Nowadays they have CI, CD, pipelines, clouds, containers and other modern buzzwords to speed up the delivery of working software to the end users. At most of conferences and events about Agile you will run into this simplistic and convenient view on the subject: DevOps is just the usage of special software tools to build CI/CD pipeline starting at the moment that the new version of software is ready for deployment.
It is no wonder that this view brings very little value, as many Agile teams are struggling with on-time software delivery and huge downtimes while doing changes in a production environment. Therefore, diminishing all the benefits of fast and agile software development.
The second is a better but still “we can do more than this” view
The problem lies between development and operations. Our Devs and our Ops have opposite goals, which means it is almost impossible for them to work together as one entity and one team.
Modern developers want to deliver software rapidly, releasing it to production with every sprint (in case of Scrum) or even constantly, every day or several times per day (in case of Kanban). The more frequent the releases are, the better the work of analysts, programmers, testers should be. Basically, the whole developer’s team… They usually have some KPIs to reflect that: more changes is better, keep up the fast pace, provide new versions frequently, and allow for fast feedback.
Operations people, on the other hand, are all about stability. Our IT infrastructure is fragile; we tend not to touch it so often. The fewer releases we do, the better uptime we get. Every release is a huge pain – we know from experience that anything can go wrong and most certainly it will. So, Ops will spend lots of time and effort to make this release work in production. The usual KPIs for Operations, including things like uptime, MTBF, MTTR and such, help complete the picture. Therefore – the less changes we have the better we, Operations, will perform. Developers – please wait for the agreed release time next quarter, as we have a release policy guarding our IT infrastructure.
Now let’s look at another wall, this time between Development and Operations.
One can find the solution to this problem in DevOps. So, if we could somehow manage for Developers and Operations to sit together, work as a team, use the same tools and methodologies, then we could find some possibilities to not just develop software fast and frequently but also to deploy it fast and frequently. This view on DevOps can be summarized as: DevOps is a means for Development and Operations to work together in the same direction towards fast, frequent and reliable software delivery. This view is more useful than the previous one, especially given that it has been expressed by several respected international experts.
However, can we do even better? It turns out, we can.
The final view is a holistic view
There are two main problems with the previous view. The first one is that it all somehow stops on the right-hand side with Operations, while in reality the software is consumed by end users and most of our feedback comes from them. It is strange not to include users in this picture, as this means the picture will definitely be incomplete.
The second problem is even bigger. From our experience, we know that it is very hard to build a single smooth process out of two quite different methodologies and toolsets, Agile and DevOps. In the past, we saw some failed attempts with a lot of time, money and effort spent and with little value and benefits in return. Looking at the picture above, we somehow need to remove not only the walls, but also the arrows themselves. We need a unified and single process for software development and delivery.
This is the view where DevOps is a continuous rapid flow of work in a single value stream towards end users, built on Agile and Lean ideas and methodologies, allowing for fast feedback. Please note that neither Development, nor Operations was mentioned in the sentence above. In my opinion, it is more important to realize that this flow starts with business and ends with business. Rather than to include Devs and Ops – they are, of course, included in the flow, just like analysts, UI/UX designers, DBAs, Security guys and everyone else required to build modern software solutions.
Conclusion
In a nutshell, it is very hard to see the latter view just by looking at the term “DevOps”. One needs to read the full article to understand what DevOps means and which problems can be solved with this methodology. Being very pragmatic myself, I treat ITIL/ITSM, COBIT, PRINCE2, TOGAF, Agile, Lean, and, of course, DevOps, as tools in my toolset – depending on the problem that needs solving. I can choose the best solution for my client.
Interesting enough, it took a couple of decades to appreciate ITSM (IT Service Management) and to understand finally that it is not just “IT delivering services while following processes”. Companies embracing ITSM beyond Service Desk, Service Catalogs and SLAs are managing to get more benefits from methodology, achieving more value for business.
I truly hope the road towards understanding and adoption of DevOps will take significantly less time, as this new tool (not a toy!) is very promising and already delivering significant outcomes.
More information on this topic can be found in my book DevOps – A Business Perspective published by Van Haren Publishing.
You can reach the author at o.skrynnik@cleverics.ru
The post The biggest problem with DevOps is the name appeared first on EN | Van Haren Publishing.
