Paraphrase
The idea behind this framework is to enable Organizations to create, design and evaluate the comprehensive approach to CI/CD processes on Organization level. When used, it allows to have a helicopter view on the area and brings proper perspective - it allows to see all elements of the bloodstream in the body. The body is the Organization, and bloodstream (in this case, CI/CD process) is responsible to deliver oxygen (deliverable) to the body and allow this body to operate. Any issue in the bloodstream might bring serious threat to the health or even existence of the body.
As we use this paraphrase with body as an Organization, here is a little story. For some time I treated CI/CD as backbone of the body / Organization. But something didn’t sound well. Backbone is static. It has very important role, however it is not that flexible and adaptable as CI/CD should be in the Organization. Bloodstream and blood play different role. Blood delivers (Continuous Delivery/Deployment). Blood guards (quality gates). Blood can be measured (DORA). And I can find more relations, but I think it is enough :) So, that is why I use this paraphrase now; CI/CD as bloodstream, works better for my imagination.
Structure
Focus on the level of Organization requires different approach. Here the strategy is build. The vision is crafted and some boundaries are set. These boundaries can be treated as potential constraints for our process. As an example, here are a few potential boundaries / limitations / constraints
- budget
- business type
- security
- regulations
These are few examples only.
In this perspective the focus is on two aspects. One is Organization and the second is Process - these are the primary aspects. The third aspect can be identified as the central part, which belongs to both primary aspects. On this level the tools are not considered from technical perspective, rather as part of the process and Organization’s capability.
Picture above presents the two primary aspects and central aspect. Each aspect contains areas of interest which are placed based on their weight in specific aspect. Most of areas has connections to both aspects, however all of them cannot exist in central area.
Central aspect contains those areas which are inseparably connected with both aspects and have very strong influence from both of them.
Mind map
Why mind map? This approach allows to be very flexible during the design process. The flow, the order and the areas can be selected in the way that suits the process and participants. There is no “best order” when considering the areas. Also, the form of mind map allows to add areas dynamically, depends on the design process expectations.
Main view of the framework
Picture below presents the framework in full view.
(pdf file can be downloaded in Download section)
Why the framework
In case of one, ten, or fifteen pipelines, the small organizations don’t see the need of consolidation and proper process for CI/CD on Organization level. However, scenario here might be very similar to scenarios which industry observe in case of Agile, Scrum, etc. In some point of growth the Organization needs to modify simple model (like simple Scrum approach) to something more organized on higher level. That is why industry uses so-called scaled frameworks, like LeSS, SAFe, Nexxus and so on. Same happens with the core of DevOps Organization - the need of scaling CI/CD and organizing it on higher level. This framework’s construction allows Organizations to enable this higher level management.
The framework itself doesn’t limit the tooling and strategies selected by team or teams. However, the outcome of using the framework can set this boundaries and limitations. The framework operates on Organization and Process levels only, not tooling or team’s composition.
When to use the framework
There is no proper answer to this question. From one side, there is no “entry point” when the Organization should start using it. Thanks to the flexibility of the framework, it can be used from any moment, even from day one.
From another side though, there is a moment in DevOps lifecycle when the process become very complicated, not well managed, the team, managers and simply speaking all interested parties start to see the gaps and misalignments in the process. This is the good time to take a look on the situation and implement improvements.
Who can use the framework
Everyone. The framework is focused on high level design and structure what allow to establish common language. Think about it like a Rosetta Stone of CI/CD which allows to communicate and discuss design through all competencies and business levels.
Why to use the framework
Some of benefits are discussed in Benefits section.
One of the most important reasons of using this framework is adaptability and integration with architecture frameworks. Today industry uses roles called Cloud Architect or DevOps Architect (at this point it doesn’t matter if we agree with these roles’ responsibilitites or not). This framework can be easily integrated with Solution Architecture and Enterprise Architecture, especially in full scope.
In fact, all aspects can be translated to Quality Attributes (or Non Functional Requirements) in Architecture area.
How to use the framework
The power of this framework is flexibility. It doesn’t have a starting or final area, so it is up to leading person to select where to start and how to lead the design process through the areas and aspects. Moreover, there is no obligation to go through all areas. The scope can be selected by the leading person or the involved group. Some areas can be taken into consideration more deeply too.
Extensions to the framework
The framework is not closed thing. It is the base, the foundation for design process, but if the Organizations sees need to extend aspect’s details or even add more aspects - it is not only possible, but very welcome.