DevOps is the widely used buzzword for a far-reaching transformation of the IT organization in companies. The implementation of DevOps is based on methodological elements of different dimensions and addresses organizational, process-related and technical aspects. Optimal interaction of all methodological dimensions is a decisive success factor for sustainable implementation of DevOps.
In general, changes to tools and methods are not as difficult to make as changes to corporate culture. However, in practice, such changes to methods also make a significant contribution to achieving the underlying goals, such as faster deliverability of software solutions.
The project methods used for software development have evolved over time from classic waterfall models towards iterative and agile project methods. In the classic waterfall methods, a completed concept phase is generally followed by a single realization phase. In agile methods, the conception and realization phases are run through several times, or iteratively, with significantly smaller delivery objects. There is thus the possibility of still exerting significant influence on the end product during realization.
With DevOps, the agile methodology is not only used as part of the project phase for the development of a new software product, but is also applied throughout the entire product lifecycle and thus in particular also in the productive operating phase of a product.
Organizationally, the development toward a DevOps approach model is often driven strongly at the methodological level. In addition to the alignment of the operating processes, this also includes the basic architectural decisions and the cornerstones of the software development process. The methods used can be changed much more easily than the company culture. It is therefore also possible to omit individual aspects, such as the switch to a microservice architecture, (for the time being) and still achieve the massive benefits through the use of DevOps.
From an organizational perspective, the DevOps model differs from the classic operating model, which in many places is defined along operating processes in accordance with ITIL, in that the various areas are integrated. The division of areas of responsibility into the classic three phases of "Plan" (planning), "Build" (building/developing) and "Run" (operating) is split into integral DevOps teams, each of which covers all three areas.
It is particularly important to emphasize the fact that shifting responsibility for operations to the DevOps teams does not eliminate the need for company-wide operational processes in general. The operational processes are often not the first issues when shifting responsibilities to the individual teams, as the DevOps teams are ultimately responsible for operations themselves from then on.
Even without applying a complete operations process framework such as ITIL, the DevOps model usually requires defined and traceable change management and problem management processes. This is often a critical issue, as development teams tend to bypass corresponding processes, which have historically often been seen as holding them back, when moving to DevOps. However, frameworks such as Scaled Agile Framework® (SAFe) offer starting points to prevent this. For this to happen, however, there must be awareness of the need and appropriate governance.
In general, reduced central control is a challenge for governance in companies. This is not only the case when there are regulatory requirements, for example. Even the increased use of open source software without central governance can lead to "technical debt" or, worse, security risks if several teams use the same tools with slightly different approaches and possibly very heterogeneous know-how.
In classic development models, the conception of the security aspects of a software solution and, in particular, the testing of the security aspects is often the task of a dedicated team. The functional design of the solution is conceived first and, in agile project methods, is often already implemented to a certain extent before the security aspects are given appropriate attention. On the one hand, this often leads to delays in the project, since certain aspects only emerge at a later point in time and have to be clarified in detail. In addition, there is a high probability that this approach will ultimately not result in the implementation of the optimal solution.
In the collaborative DevSecOps approach, the security aspects are taken into account from the outset in the design of the future solution and the security expertise is an integral part of the development team at all times. The security aspects in modern software development and deployment models can be divided into two main categories:
Security of components and data (e.g., access and rights management, encryption of data transmission and storage).
Security within processes (e.g., scanners for testing when deploying containers, automated tests for compliance checking of infrastructure-as-code scripts).
In order to be able to guarantee integral security of software solutions, both categories must be taken into account at all times during design as well as (further) development. It is imperative that the corresponding capabilities can be sufficiently covered within a DevSecOps team. Again, culture is an integral part of the transformation towards DevSecOps. Due to the extent of the changes, we will devote a separate article to DevSecOps.
In order to be able to develop and release (sub-)applications independently of one another, the focus on APIs plays a central role. Clearly defined interfaces permit, as with object-oriented programming, a loose coupling of components. Beyond that APIs permit it however also to develop new and innovative functions fast, since the Orchestrierung of existing functions moves into the center. The trend toward low-code platforms and similar approaches, which in some cases even allow business users to automate processes directly (Citizen Developer), takes this idea of orchestrating existing functionalities to the extreme. See also "Digital platforms: Enablers of Agile Enterprise Architecture Part 1" and Part 2.
However, direct consequences of a shift to small components of applications coupled together via APIs as part of the trend toward "microservice" architectures can also be seen in "conventional" software development. The technological aspects of container technologies addressed by DevOps support this trend significantly and will be taken up in the next article.
Of course, with this type of architecture, the complexity shifts from the individual applications themselves to the network of relationships between the applications. However, it helps here that the challenges between different applications become much more similar and can often even be addressed technically. This is done, for example, through service mashes on container platforms. The shift of complexity towards the platforms on which the applications are developed is generally recognizable. This is particularly advantageous if the platforms do not have to be operated by the DevOps teams themselves, but can be purchased from a cloud provider, for example.
DevOps as a methodology is very closely intertwined with the agile project methodology. It additionally complements the agile approach with the operational aspects. The organizational aspect of the DevOps model requires an integration of the capabilities of software development, infrastructure service provision, testing and quality assurance, as well as operational aspects such as support, maintenance and further development of solutions. To ensure that IT solutions can also meet the ever-increasing IT security requirements in the process, close integration of cyber security capabilities is imperative. The methodical approach to dovetailing the DevOps model with the corresponding cyber security capabilities leads to a further development of the model in the direction of DevSecOps.
In addition to agile methods for developing, deploying and operating modern software solutions, a modern software architecture is another cornerstone for efficient and effective use of DevOps capabilities. The principles of microservice architectures and the focus on smaller software elements that communicate with each other via APIs can enable partial further development and the operation of individual elements according to agile DevOps methodologies.
From a technical process perspective, proven tools and frameworks provide the foundation for automated management, quality assurance and deployment of software solutions within the framework of the CI/CD methodology.
Various tools are available for the effective implementation of the DevOps methods explained, which we will discuss further in our next article.
If you enjoyed the article, we as Eraneos Group would be very happy to discuss your initiatives, experiences of success but also challenges in connection with the establishment and use of DevOps in your organization in more detail. We would be happy to support you with our experience and expertise in the field of DevOps and agile transformation.
DevOps: a question of culture?
Financial sector faces a variety of complex challenges
Support for successful business model transformations
Open Banking: Buzzword or Added Value?