Why Stop Inventing New DevOps Combinations?
The term DevOps is well known by now. It was initially introduced by Patrick Dubois a Belgian IT consultant who organized an agile oriented event in October 2009 and named it DevOpsDays, targeting not only developers but also systems administrators, managers, and toolsmiths from all over the world. After the conference, the conversations continued on Twitter with the hashtag #DevOps.
If you want to know more about the origin of the DevOps, you can check the video given below which gives you a lot of background about the reason why Patrick Dubois initially started this DevOpsDays conference:
DevOps and the rise of the combinations and derivatives
With the increasing popularity of DevOps, more people start to give their definition of DevOps. The different definitions of DevOps that go around can differ, depending on what aspect(s) of DevOps you want to focus.
In a previous article, I wrote about how to explain DevOps in 5 letters – CALMS or CALMR i.e CALMS framework for DevOps
Some other definitions tend to focus primarily on the automation aspect, omitting the Agile foundation. As a consequence, you get the first combination of DevOps, named BizDevOps or BusDevOps. There are different interpretations about what BizDevOps actually means.
“BizDevOps, also known as DevOps 2.0, is an approach to software development that encourages developers, operations staff and business teams to work together so the organization can develop software more quickly, be more responsive to user demand and ultimately maximize revenue.”
At the same time, it is the most disputable definition. This definition assumes that DevOps is mainly a technology-driven initiative that hardly involves business people. But as mentioned in my previous article, the foundation of DevOps is culture, which goes back to the agile principles. And we all know that agile without business is only symptomatic. So DevOps without business is as symptomatic as agile without business.
According to the Dzone article, DevOps is focusing on a single application or system whereas BizDevOps is focusing on the entire enterprise with all its complex processes and the mixture of applications and systems that support these complex processes.
According to this article, BizDevOps provides an answer to dealing with:
OK, fair point, but these aspects could as well be tackled by defining proper value streams and Agile Release Trains to deal with all the links and dependencies between these systems and applications. I don’t see the need to come up with a different term.
I guess you understand by now that I am not a big fan of the BizDevOps term and the confusion it creates. But it can get worse. It was some likely clever tool vendors that came up with the term DevSecOps. And if it is not the tool vendors that invented it, at least they were so clever to jump on the wagon to support the need for more security awareness in DevOps.
Nowadays, large tool vendors using of the term DevSecOps instead of DevOps.
Here’s my opinion on this: security should be an integral part of DevOps. It should be a part of the culture:
Don’t only think about what something functionally should do, but also what can go wrong (think Abuse or Misuse cases). It is also a part of the automation. All security related tests should be automated as much as possible. Think about scanning vulnerabilities in your own source code, vulnerabilities in external libraries that you use, scanning your container images for vulnerabilities, or even – up to some extent – automated penetration testing. It is also a part of Lean principles: when a security test in your build pipeline fails (e.g. scanning your source code discovers a critical vulnerability), you stop the line.
So again, the is no reason why the term DevSecOps should exist at all.
Now that we have business and security covered, we can go on and see who else could feel denied or at least ignored? Maybe DBA’s? Or any other person involved in data management? Maybe, that is the reason why we also have DevDataOps nowadays.
I could go on for a while like this. But you get the point by now: it is useless
I recently got to read an interesting article on disciplined agile delivery, the information portal from Mark Lines and Scott Ambler of their Disciplined Agile Delivery, or short DAD. DAD is not – as they call it – an agile methodology, but a process selection framework. DAD is the kernel of a layered model, like an onion, that they call Disciplined Agile and that consists of the following layers:
Let’s explore each aspect in Disciplined Agile Framework mentioned in the diagram.
1. Disciplined Agile Delivery (DAD)
Disciplined Agile Delivery (DAD) aspect consists of initial modeling and planning, forming the team, securing funding, continuous architecture, continuous testing, continuous development, and governance all the way through the lifecycle. The Disciplined Agile Delivery (DAD) framework supports multiple delivery life cycles, basic/Agile lifecycle based on Scrum, a lean lifecycle based on Kanban, and a modern Agile lifecycle for continuous delivery. This aspect is responsible for addressing all the aspects of solution delivery.
2. Disciplined DevOps
Disciplined DevOps streamlines the IT solution development and IT operations activities, and supports organization-IT activities, to benefit more effective outcomes to the organizations.
3. Disciplined Agile IT (DAIT)
DAIT aspect helps to understand how to apply Agile and Lean strategies to IT organizations. This aspect comprises of all IT-level activities such as enterprise architecture, data management, portfolio management, IT governance, and other capabilities.
4.Disciplined Agile Enterprise (DAE)
DAE can predict and respond quickly to the changes in the marketplace by facilitating a change through an organizational culture and structure. This aspect can be applied to organizations having the learning mindset in the mainstream business and underlying lean and agile processes to drive innovation.
The second one, Disciplined DevOps principles deal exactly with what I mentioned before: the different derivatives and combinations of DevOps. They start by giving an answer to the question of why it is so difficult to come to a common definition of DevOps:
Specialized IT practitioners
Many IT professionals still tend to specialize, choose a focus, like DBA, enterprise architect, operations engineer, or whatever. Each discipline will focus on its own aspect of DevOps.
Agilists are focused on continuous delivery
Because of their focus on releasing daily or even several times a day, a lot of discussions deal with bringing new features faster and more frequently to production and not paying attention to all aspects of DevOps
Operations professionals are often frustrated
Systems administrators are crunched between the push of the development teams to deliver faster and more frequently and the typical stringent service management processes they have to deal with, that are not yet adapted to the need for more frequent changes
Tool vendors have limited offerings
A fool with a tool is still a fool… DevOps tool vendors only focus on these DevOps-aspects that their tools cover
Service vendors have limited offerings
Similarly to tool vendors, service vendors will only focus on these DevOps aspects that their services can currently cover
Tool vendors treat DevOps as a marketing buzzword
Surfing the waves of the hypes, vendors might be persuaded to rebrand their existing toolset to something DevOps-ish, because it sounds better in a sales pitch. Sounds like window dressing…
The DevOps = Cloud vision
Apparently, some people think that implementing DevOps in your organization can only succeed if you move to a cloud-based platform. Although cloud-native development practices are a facilitator for implementing DevOps, it not a requirement. And moving to a cloud platform definitely isn’t a requirement.
All these reasons make that person come up with DevOps combinations that give an answer to only part of the problem.
Disciplined DevOps mentions the following visions:
1. BizDevOps
BizDevOps is a basic DevOps vision that explicitly brings the customers into the picture. BizDevOps is also called BusDevOps. DevOps is not just for teams, but it can be potentially applicable to any team supporting an incremental delivery lifecycle. The BizDevOps workflow consists of Business Operations, activities of delivering of products and services to the organizations. BusDevOps seeks to streamline the entire value stream, not just the IT portion of it. Its workflow is depicted in the diagram below.
2. DevSecOps
Another common improvement over the basic DevOps vision is something called DevSecOps. The aim behind this vision is to ensure data security by getting the various security issues, adopting the latest security practices, and finding out and addressing the highest priority security gaps [DevSecOps]. This vision includes collaborative security engineers, exploit testing, real-time security monitoring, and building “rugged software” that has built-in security controls. The workflow of DevSecOps is shown in the figure.
3. DevDataOps
The aim behind DevDataOps is to maintain a balance between the current needs of data management consists of providing timely and accurate information to the organization and DevOps to respond to the marketplace. Supporting data management activities include the definition, support, and evolution of data and information standards and guidelines; the creation, support, evolution, and operation of data sources of record within your organization; and the creation, support, evolution, and operation of data warehouse (DW)/business intelligence (BI) solutions. The following figure depicting the workflow of DevDataOps.
Even though the message of Scott Ambler and Mark Lines is perfectly reasonable, not everybody might the term Disciplined DevOps. It fits their framework like a glove: everything boils down to Disciplined.
If you don’t want to be framed into the Disciplined Agile/DevOps framework (pun intended), you may as well stick to the term DevOps and make sure that you cover all the aspects, which include business, security, data, release management and support.
Research & References of Why Stop Inventing New DevOps Combinations?|A&C Accounting And Tax Services
Source
0 Comments
Trackbacks/Pingbacks