DevOps-Guidelines

We are pleased to present another successfully completed project: The creation of DevOps guidelines for Basler Verkehrs-Betriebe (BVB). As part of the consulting mandate, our task was to create an efficient and agile environment for software development and deployment (DevOps) that meets BVB's needs.

The analysis of BVB's IT landscape was divided into three sections in order to obtain a complete overview of the current state (ACTUAL state) on the one hand, and to define a clear target state (TARGET state) on the other, on the basis of which the guidelines could be developed.

In the first stage, several meetings and workshops as well as discussions were held to understand BVB's internal IT systems, their requirements and goals. In close collaboration with BVB, the desired TARGET state for the IT infrastructure was defined. Atticode gained a holistic view of the current IT organization to best assess the effort and criteria for the guidelines.

In the second phase, further workshops, analyses, interviews and site visits were conducted to gather more data and obtain as detailed a picture as possible of the current ACTUAL state. The eight phases of the DevOps lifecycle (planning, code, build, test, release, deploy, operate and monitoring) were examined in isolation within BVB and described in varying detail depending on the requirements. In this way, it was possible to capture the current state of the IT landscape as a whole relatively accurately.

In the third section, the planned result was developed. The resulting document contains a system analysis, risk assessment, and guidelines and recommendations, including a comprehensive catalog of measures to ensure a successful transformation to the target state. The document has a modular structure and is provided with graphic forms of expression in order to make the guidelines short, concise and self-explanatory.

Our goal was to provide BVB with an efficient tool for implementing a standardized but dynamic DevOps environment. The document describes guidelines, workflows, tools, technologies, processes, roles, etc. according to IT industry best practice as a holistic and agile process model for BVB's DevOps lifecycle.The guidelines are structured in such a way that they can easily and practically be applied in accordance with the DRY ("Don't repeat yourself") and KISS ("Keep it simple (and) stupid") principles from software development. Our experts have used their knowledge and experience to ensure that BVB can implement the best DevOps practices and thus optimize its software development process.

DevOps is a combination of "Development" and "Operations" that is an agile and collaborative approach to IT development and operations. DevOps aims to accelerate the development and delivery of software by improving collaboration and communication between developers and operations managers.

Traditionally, developers and operations managers work separately and have different goals and priorities. DevOps seeks to close this gap by optimizing the development and deployment process through automation and standardization, ensuring that software can be delivered faster and more reliably.

DevOps involves a combination of cultural, organizational and technical changes. These include continuous integration, continuous delivery, test automation, infrastructure automation and improved collaboration between the different teams within an organization. The DevOps philosophy is an important part of the IT industry and is used by many companies to improve the efficiency and quality of their DevOps pipeline.

The DevOps philosophy has gained a great deal of importance in the IT industry in recent years. However, when implementing this agile method, many decisions have to be made that can influence the success of a DevOps project. Atticode specializes in helping companies find and implement the optimal DevOps lifecycle.

Our reasoning for evaluating the internal IT landscape is based on the GAMAB principle for minimizing risk. GAMAB stands for "Globalement au moins aussi bon" (generally at least as good) and states that the risk of a new system should be at least as secure or low-risk as that of an existing comparable system. This principle sets the current safety standard as the minimum requirement. New systems must at least meet or exceed this standard. It assumes that the risk of a comparable production system is considered accepted and is thus an intuitive, but also common, risk acceptance criterion. Interestingly, GAMAB is essentially the same as best practice, which is what we ultimately want to build on.

Furthermore, it should be noted that risk management methods are increasingly being used in the implementation of IT systems in order to cope with the complexity and associated error-proneness of software products. Aspects of risk management should be taken into account across the entire DevOps pipeline, from planning and development to monitoring of the system

However, our aim is not to carry out complete risk management. Rather, we would like to apply the risk assessment approach in part and be guided by the processes of risk identification, analysis and assessment.

Our risk assessment aims to identify deviations from the best practice DevOps approach. The aim is to determine how great the differences are between a fully implemented DevOps pipeline and the processes, tools and technologies in the area of software development and operations. These deviations can be viewed as indicators of risk and used to define the need for action in the respective IT areas. This is because the greater the difference from best practice, the closer a system is to the area of "worst practice" and thus exposed to a higher risk of technical, personnel and financial difficulties.

In other words, we use best practice from the DevOps area as a standard and determine the difference to the specific DevOps implementation within the operation. In this way, the current risk can be assessed and at the same time it is known which steps to the standard are still missing in order to minimize the risk optimally.

Best practice is the general term for the best existing solution to a problem. In business administration, the term is associated with benchmarking and describes the pragmatic procedure of systematically benefiting from the existing experience of other, more successful organizations by using their solution approach (their "best practice") to improve one's own processes or products.

If proven methods are not readily applicable to a company's existing circumstances, the most important elements of best practice can also only be partially adopted and brought into line with existing processes. When using best practice, the wheel does not have to be reinvented; existing solution approaches can simply be adopted.

In the last decade, best practice for software development and operations has also been established in the IT sector. The evolution of agile methods has shown that companies with a holistic view of their complex software lifecycle are more successful than the competition. This has given rise to the DevOps approach, which is now not just best practice, but the de facto standard of successful software companies.

Since IT is considered a very fast-moving area, state-of-the-art technologies are adopted into best practice correspondingly quickly. However, the high pace of further development in the IT sector also gives rise to many trends and hypes that may later prove to be aberrations. Early adopters" in particular must therefore be careful not to adapt any supposed best practices. After a certain period of time, however, persistent IT trends can certainly be considered "good practice".

After our experts performed a detailed analysis of the current state of the IT system landscape, it was divided into three areas: We call these Internet of Things (IoT), cloud computing and machine learning as examples. Each area was further evaluated according to the 13 specific criteria. These include criteria such as failure rate, technology, user satisfaction, security, failure rate, maintainability, monitoring and scalability, etc. After the evaluation, we were able to define any need for action and make recommendations for the respective areas.

We then created a comprehensive package of measures to transform the IT landscape. In doing so, we were guided by best practice and DevOps methods and made specific technical recommendations for the 13 assessment points. Our recommendations are specific to BVB. We recommended tools, technologies, and methodologies and created a detailed DevOps checklist for internal software projects. In doing so, we have used open DevOps guidelines in order to be able to react flexibly to future changes.

In addition to the extensive catalog of measures, including proposed action requirements for the 13 areas, we generally recommended the transition to a microservice architecture, data flow optimizations and the treatment of impending legacy problems. We also helped raise awareness of critical systems by identifying and documenting their protection. The detailed results cannot be disclosed for confidentiality reasons.

Ultimately, Atticode's guidelines are a modular DevOps toolkit that should be understood as a recommendation, but not as a prescription. The flexibility of the Agile principles is in the foreground. Atticode thus offers companies an ideal solution for optimizing DevOps lifecycles and successfully implementing projects.

At Atticode, we are convinced that the creation of DevOps guidelines is a crucial step to improve the quality and efficiency of software development and to increase business agility. We are pleased to be part of this process and to have helped Basler Verkehrs-Betriebe to further unleash the potential of their ICT systems.

If you are also looking for experts who can help you transform your IT landscape into a future-oriented, standardized and risk-minimized environment, please feel free to contact us.