|exactly did he mean?|
System Thinking has its foundation in the field of system dynamics, founded in 1956 by MIT professor Jay Forrester. Professor Forrester recognized the need for a better way of testing new ideas about social systems, in the same way we can test ideas in engineering. System Thinking allows people to make their understanding of social systems explicit and improve them in the same way that people can use engineering principles to improve their understanding of mechanical systems.
Software is developed for people and by people. Human and social factors have a very strong impact on the success of software development endeavors and the resulting system. Surprisingly, much of software engineering research in the last decade is technical, quantitative and deemphasizes the people aspect.
With the DevOps movement, the emphasis returns to the people aspect, where DevOps (Development and Operations) is understood to mean a type of flexible relationship between Development and IT Operations. The goal of DevOps is to change and improve this relationship by advocating better communication and collaboration between these two business units.
We can therefore state that System Thinking for DevOps is required to understand Software Engineering as a social construct using engineering principles.
From a System Thinking approach, DevOps thinking is fundamentally different from the traditional form of analysis. Traditional analysis focus on separating the individual software engineering pieces, e.g., architecture, coding, testing, tooling etc. In contrast, the DevOps approach focuses on how all aspects of the software life cycle interact with other constituents of the system. Circling back to the definition of DevOps we can easily identify the ‘behavior traits’ observed in the DevOps movement, namely: adaptable/flexible (improve relationship), cooperative (better communication), diplomatic (collaboration), etc.
|First principle of DevOps System Thinking|
DevOps as an initiative does not strive to isolate smaller and smaller parts of the software life cycle system (e.g., isolate architecture, focus on tooling, etc.) but rather it works by expanding its view to take into account larger and larger numbers of interactions as a primary concern.
This statement still does not address the ‘Why’. The character of System Thinking makes it extremely effective on the most difficult types of problems to solve: those involving complex issues, those that depend a great deal on the past or on the actions of others, and those stemming from ineffective coordination among those involved, similar to what we have seen in software development and production support.
System Thinking has proven to be invaluable in a number of areas that directly relate to the problems encountered in software development as a result of the above. This brings us to where System Thinking benefits DevOps in solving issues related to: (not an exhaustive list):
Problems that require shareholders to “see the forest for the trees”.
Recurring problems that have been made worse by past attempts to fix them.
Challenges where actions effect the environment surrounding the issue.
Problems where solutions are not obvious.
|Second principle of DevOps System Thinking|
DevOps as an initiative recognizes that complex problem solving require a broader environmental impact consideration (functional and non-functional), while keeping in mind the agreed problem at hand (as describe by all stakeholders), following agreed patterns and recognizing and removing anti-patterns along the way.
DevOps understands that the software development life cycle is plagued with complex issues, involving multiple actors, and these issues are at least partly the result of past actions that were taken to alleviate them.
The DevOps movement recognized that the key benefit of System Thinking is its ability to deal effectively with these types of problems and raise the thinking to the level where results are realized for individuals and organization. In addition, it improves the understanding of the complexity associated with the software development life cycle as a whole.