Version 2.
“System is characterised not by own mistakes, but by its reaction to own mistakes.”
– Julia Latynina
Make code right first, then make it fast.
EVERYONE WHO WANTS TO CONTRIBUTE INTO “CODE OF DEVOPS PRACTICE” IS WELCOME TO SEND SUGGESTIONS VIA THE FORM BELOW THE TEXT
Subject
The Code of DevOps Practice states how the company expects DevOps teams to behave. It gets down to specific action expectations.
Cause
Industry adopts automation of regular and commoditised processes in the realm of software development. The adoption is expressed via combining previously separated processes of software product implementation or code development and technology operational activities in the set of automated activities known as DevOps. The DevOps teams have initially inherited the team organisation and development principles from Agile Manifesto and Scrum Guide with a few features of Lean and XP development.
Automation enables improvement of the outcome quality and significant increase of the development speed. DevOps is not a combination of people and automated tools/processes, it is a new cultural element for corporate IT Departments and even Business consumers. Automation is not a simple task and many routinely mandatory activities and controls are still not automated or just semi-automated. Under influence of global digitalizing, many DevOps teams started to deviate from their initial role and stipulate a new rooted in code-writing practice model for their position in the company and product delivery to the internal and external consumers.
The major focus of such teams has shifted from the fast and frequent delivery of the quality software products to just as fast delivery as possible. These teams have found resources for the delivery acceleration in simplification or omitting complex or long-running tests, oversimplification or skipping security controls and validation of industry regulations. Also, such traditional norms as “make code correct first and fast second” and “not addressing technical debt slows down development and results in a worse, more buggy product” or “consumers drop unsecured or incompliant products altogether” are scarified for the sake of speedy development.
Objectives
This Code of DevOps Practice aims to producing quality products with all due testing, security (technical and business) and business regulations within dynamic corporate and external context.
Since each company usually has its own Code of Practice for its software development function, this Code of DevOps Practice is assumed as guidance or template for the corporate’s code. Provided Values, Pillars and Principles are in balance though none of them is mandatory. Each company is free to change them according to its unique business and technology context and market, but a change may lead to a need of rebalancing, which is on the company’s account.
The Code of DevOps Practice is viewed as an instrument for managerial and architectural governance over the development process, especially if the company operates more than one DevOps team. The members of the DevOps teams may find the Code of DevOps Practice restrictive, but it addresses only minimum viable requirements to the digital products from the company and market perspectives.
VALUES, PILLARS AND PRINCIPLES OF THE “CODE OF DEVOPS PRACTICE” ARE LINKED TO THE COMPLIMENTARY EXPLANATIONS
Values
Pillars
| № | PILLARS | COMMENTS |
| 1 | Business Value of the outcome | The business value of the DevOps work should be defined outside of the Team or proposed by the Team and approved outside of the Team. A Team cannot be the requestor and the provider of its work when being paid for the work by its Employer. |
| 2 | Quality of Product | Quality of products created by the DevOps Team is one of the most valuable factors of competitive advantage of companies in many industries and markets. Every product released by the DevOps team, even a released part of the future product, should meet quality criteria defined outside of the team |
| 3 | Business Flexibility of the outcome | Business Flexibility is the long-time expected value that DevOps practice can deliver. Business Flexibility is not a qualitative opinion-based category; it has a clear quantitative expression where the software development is expressed via business characteristics such a cost and time-to-market. This Principle defines the objective criterion for “minimum valuable solution” |
| 4 | Professionalism of Team-Members | In the context of DevOps, a professional person is not only the one who can perform work associated with a particular profession. It is a person who possesses special education and training that prepare members of the profession with the particular knowledge and skills necessary to perform their specific role within that profession. |
| 5 | Continuous innovations | Innovations, in contrast to inventions, are contextual and implementation-specific methods, effects or products. So, they are not necessarily only new things, but the things new in the given context. Adoption of DevOps practice can be an innovation by itself. Innovations developed/proposed by a DevOps team should aim to increasing business values for the company and can be expressed in methods, products, operations, organisation and technologies |
Principles (see post)
| № | PRINCIPLE | COMMENTS |
| 1 | Code development, security and compliance have equal realisation priority. | When coding, never leave security and compliance for tomorrow. Use security and compliance by design and by default in implementation. Value of the code with no security and/or compliance is next to zero. |
| 2 | The velocity of product delivery may not reduce the quality of the development outcome in any way. | Consumers in the internal and external markets are entitled to quality products from the first attempt. Market does not give a second chance. No development team may define the ‘minimum viable quality’ for a particular product; this is the prerogative of the Marketing and Sales Teams of the company. |
| 3 | A DevOps person may not be the creator, judge, executor and validator of his/her work. | Design of the product, the judgement of the design suitability for the business task, code development or implementation, product/code execution and result validations are different concerns and have systemic reasons for segregation. Otherwise, any accumulation of them in the hands of one person constitutes a high risk of conflict of interests. |
| 4 | Definition of ‘done’ should include full testing, documentation, security and compliance validation. | In order for a company to successfully market its products to consumers, the company should be confident in that the code is of high quality, fully tested secured and compliant with the market regulations. |
| 5 | Working software is the one that meets the definition of work is “done”. | Working code is only a ‘phase’ in the product development. It is not a criterion of complete product. Just working code has its final value only as a POC, not as a product. |
| 6 | The value of the team-work outcome is validated by the consumer, not by the Team. | In many types of company organisations, other divisions and the company management can be the consumer of the DevOps work outcome. |
| 7 | Decisions about all aspects of product development may be made only in the business and technology context of the product use | Business and technology contexts vary depending on where the consumer of the DevOps outcomes resides. Priorities and preferences dictated by contexts can be different in different contexts. Effective technical decisions can appear limited or prohibited in a particular business context. |
| 8 | Specialist’s opinion may not be suppressed by common opinion in the Team. | A specialist is the core resource of the DevOps Team. Cooperative work of specialists where each one is responsible for the assigned work is more efficient and effective than just a team-work of inexperts. |
| 9 | Design and planning of the DevOps work depend on the task’s subject and complexity, available resources and business or consumer demand, not only on the opinion of the Team. | Design and planning of implementation for different business tasks depend on many factors that may be (usually are) situating outside of the Team’s realm and competence. |
| 10 | All outcomes produced by the DevOps Team and dedicated to the consumers – internal and external – should be documented to the level where the outcomes can be supported, modified and maintained in absence of the product developers | A group of code has several fundamental differences from the product in the market. Documentation is one of these differences. A company as an owner of the product (until different is stated in the individual Employment Contract) cannot not rely on presence and availability of a DevOps Team or an individual developer and has to be able to maintain the product by itself. How the documentation is created is a special different topic. |
| 11 | Cultural environment and Team’s internal culture should link with each other via honesty and transparency at the individual and Team levels. | A high-performance culture is generative and psychologically safe. This integrates continuous improvement with continuous learning. That culture needs to include both technical and non-technical competencies and practices. |
| 12 | The quality of products for an internal user may not be lower than the quality for an external user. | An ideal quality of software products has to be as such that any internal product could compete with the analogous external one. Otherwise, the DevOps teams will be steadily replaced by outsourced development. |
| 13 | User Stories, as well as Non-Functional Requirements (NFR) to be taken by the DevOps Team for implementation, are subjects for specialist reviews outside of the Team. | The User-Stories and NFR are the development assets owned by the company and planned for the corporate Target Operating Model. in So, the company is in full right to selecting its business and technology directions/strategies and distributing its funding accordingly. |
| 14 | Everyone in the DevOps Team is responsible to the Team for the individual contribution; the Team, not only the Product Owner, is accountable to consumers and corporate management for its outcomes. | Individual contribution is based on the Employment Contract and validated via individual performance of the employee. Participation in the DevOps practice does not change the Employment Contract automatically. |
Recommendations
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly”. Agile Manifesto.
Wisdom of Software Development
- Modern market does not give the second chance to fix your mistakes
- Uncertainty in requirements does not excuse uncertainty in results
- Not everything what Team can do is needed
- Changes of the DevOps Team’s organisation and management are the deeper the company grows–up from a start-up
- Standardise automation tools
- Not everything that works well on a small stand-alone task works equally well on a bigger task
- Before accepting any technical or organisational decision justify the decision maker
- Do not mix Product Log with Team Debt Log. The latter should be empty by the time of product release or minimal and specially approved by the business stakeholders
- Not everything that is in the list of requirements is in line with corporate, LOB, Division strategy and technology Roadmap; deviations from strategies should to be treated as such
- Before trying something new, check out if it is just renamed something old.
Helpful References (to complete)
- 10 bad DevOps habits to break
- Purpose Case Management , section “Defining Flexibility”
- Distorted Microservices
- Sib Pattern for Microservice Fault-tolerance
- Microservice Polling Tandem Pattern for Reliability
- Inevitable Distributed Transactions for Microservices
- Microservice-database Anti-pattern
- Microservices – The Robust Architecture for Applications
- Grounds for Building A Robust Microservice Architecture
- Problems in Microservice QA and Solutions
- Microservice Protection based on the principle of Zero Trust
- API – a Problem-of-choice
Major Contributors
John Tieso , Lonnie Franks, Guy Maslen , David R.R. Webber , František Simetinger, Igor Topalov, Quintin Betancor Cabrera, Michael Poulin
HOW to ARCHITECT for DEVELOPERS 