Editor’s note: This is the first in a series of blogs discussing five current myths about DevOps. The blogs have been compiled by our DASA Ambassadors, Frank Faber in the Netherlands, and Lawrie Kirk in Australia. Both Frank and Lawrie have written this blog from the perspective of their experiences as consultants and program and project managers. We look forward to the discussion that is generated from this series.
Our interest in writing this blog was sparked when we were both separately advised that, within a DevOps environment, a focus on structure was unnecessary, given that DevOps uses an iterative and organic approach to delivering client solutions. The context of structure in these discussions refers to an organizational structure that provides governance over a project or program. Despite being in separate corners of the globe, we both questioned whether this was correct!
Helping clients solve and manage problems is core to what drives a good consultant to achieve their goals. To ensure that any improved process that has been delivered is sustained, it is vital that it can be replicated and supported by the organization. This can only be achieved by recognizing the significance of structure. Structure should not be seen as a limiting factor; rather it is there to harness the resources that can be used to solve a problem, create an improved solution, and, more crucially, provide a way for successful approaches to be repeated in the future. However, we both recognize that structure has been, and in some areas continues to be, used to stifle the ability to adapt, acquiring a more reactive response to clients and suppressing and discouraging innovation. Like so many things in life, the answer is not in the extremes; it is in the middle ground.
So, what does this middle ground look like in a DevOps environment? To address this question, we were reminded of the DASA white paper created by Rick Farenhorst in November 2020 entitled DevOps, A Maturing Discipline that details a reflection on the use of DevOps from 2009 to 2020 as well as on the three schools of thought that have emerged as the DevOps approach has evolved.
The paper is highly recommended as a reference on this topic as it provides answers to some of the common myths surrounding the use of DevOps today, including the need for structure. In this paper, Rick proposes that three schools of thought have evolved in different time periods, namely Integrating IT Operations with IT Development in 2010, Creating High-Performance IT Organizations in 2015, and Organizational Transformation & Digital Leadership in 2020.
It was the description of this most recent school of thought, with its focus on Organizational Transformation, that helped us justify why structure is needed in a DevOps environment. The three schools of thought are not mutually exclusive, and the use of any—or all three—is dependent on the maturity of the organization and where it finds itself with regards to the use of DevOps. Whereas the second DevOps school of thought focuses on improving the IT discipline inside-out, thereby crossing boundaries with various traditional business disciplines, such as DASA’s competence model, the third school of thought applies a more outside-in approach. Disruption to business comes from many areas outside of the organization and is not always IT-related. Almost always, human capital, organizational structures, governance, and leadership are the culprits.
The required organizational transformation goes far beyond simply improving the performance of some Agile teams in the IT department. To achieve the necessary comprehensive coverage, there must be a clear structure to the DevOps approach being used to ensure that the other parts of the organization are provided with a well-defined and repeatable outline of what is involved. Other areas rely on structure to ensure compliance with regulatory or defined and repeatable delivery processes. If areas other than IT are to receive the benefits that a DevOps approach provides, structure is essential to ensure that this DevOps-style approach is repeatable and aligned with other cultural, organizational norms.
Therefore, accepting and embracing a structured approach for DevOps helps drive organizational and cultural transformation and digital leadership for the organization, not just for IT teams.
DASA has also recognized this need for structure through training their DASA DevOps Certification Scheme. It starts with the DASA DevOps Fundamentals certification, which provides the core education needed to build a common and consistent DevOps vocabulary and shared understanding of its principles and practices. Two other layers are then provided, a Professional layer (with a focus on Know and Apply), and a Leadership layer addressing Lead and Enable. Each of these layers has three certifications completing the structured and repeatable approach to the generation of corporate knowledge and capability improvement.
So, when people observe that DevOps does not need structure, it is critical to ascertain if the comment refers to the delivery of DevOps, the extension of the DevOps concept for organizational transformation, or DevOps training. After reviewing each of these areas, we continue to reach the same conclusion that a structured approach is necessary when using DevOps. Structure is a value-laden term; take time to clarify what it means in the context at hand. Also, reflect on the DevOps journey, review the three schools of thought, and determine where your organization lies.
Structure should not be used to stifle creativity or innovation. Structure should be used to encourage and present a common understanding of how DevOps can help deliver organizational transformation.
Do you agree, or do you think differently? Please let us know what you think by sharing your thoughts below; we will make sure to review each comment.
The views, thoughts, and opinions expressed in the text above belong solely to the author(s) and do not necessarily represent the views of DASA.
DASA DevOps Certification Programs
DASA developed a certification program designed for each profile to test the practical skills and experience of professionals who feel most related to these profiles.
