In the previous sections, we have discussed the context and the organizational proposals DevOps made by training or feedback. From now on we have to find a pragmatic solution adapted to the customer in the process of transformation. This presupposes, first and foremost, an audit and analysis phase that will allow the outline of the transformation to be defined and the set goals for agility and DevOps. Because apart from the declaration of intention, it is necessary to provide a clear and measurable vision of what is expected. It is unlikely that in a large group this cultural leap will be achieved in one go and more likely that only one part of the organization will want or be eligible for agility and DevOps.
This being noted, it is necessary for the operations to respond to the 3 modes presented in the first part: The compartmentalized mode with V cycles, the ad hoc agile mode with SCRUM teams, the autonomous lab mode that can already use SAFe or Spotify like. With regard to the organization’s typologies that we saw in parts two and three, this implies for the Ops to start with project managers to move towards the establishment of dedicated Ops teams.
Let us take a contradictory hypothesis to change the entire structure in the same movement towards a completely DevOps’ organization, for example by supporting a SAFe model. At first, it involves training all the production project managers for…well for absolutely nothing because their role does not exist in SAFe! Second, it involves changing all RUN jobs to reallocate them as versatile Ops, knowing as much infrastructure provisioning coding as well as analyzing failures, defining chaos monkey strategies, etc. The operation would undoubtedly assume high expectations. SAFe mentions runway architecture as the system base on which the projects are backed up. A system architect, next to the product owner, determines the overall consistency at the system level, and then the Ops teams make the environments. There is nothing specific about the RUN applications. It therefore seems complicated to reintroduce existing systems, built and maintained by different services, within the trains’ scope of responsibility.
The questions that will quickly arise in this model:
Who now ensures 24/7 service availability, and how?
Who now assures level 3 in-house infrastructure and how to continue building and maintaining the infrastructure?
How are the Ops resources used/broken down without becoming a restraint in the train’s operation?
Who deals with the technical solutions’ adequacy with the skills and systems available, and how?
Who is responsible for ensuring that the applications developed have the required level of quality and reliability (and based on what criteria)?
To be more synthetic, how do we ensure a path between the existing technique and organization and the SAFe target? Migrating Big Bang to SAFe raises the issue of the reallocation of resources, technical training (not just organizational), the technical coherence of the entire IS and its ability to maintain existing and support all current projects.
If we take the DASA hypothesis, even if the focus is on an organizational model that responds in a simple and coherent way to the teams’ technical needs, we would get the same result because the teams’ empowerment necessarily passes through the versatility of resources and therefore the appropriation of previously dispersed skills. This requires a great effort of technical training and the adaptation of a large number of people. It also implies a synchronization and coherence effort at the global level of the information system, even if the general idea is to have a simple organization to build simple systems based on the weak coupling of the systems they develop.
On the SPOTIFY side we can also find some answers on the path we wish to achieve from the technical point of view. First of all, like DASA, Spotify takes the idea of a platform team that will naturally inherit existing infrastructure and middleware teams. Then, Spotify has set up a very interesting role with the system owner. Spotify defines it as follows: “The system owner is the “go to” person(s) for any technical or architectural issues related to that system. He is a coordinator and guides people who code in that system to ensure that they do not stumble over each other. He focuses on things like quality, documentation, technical debt, stability, scalability, and the release process.” Reading this definition we understand that this is a transition role allowing a junction between technical teams and squads.
I finally found the inspiration in this solution to propose a system owner who is not only the “go to person”, but who also has the scope of a product owner, a peer who is focused on the technical aspects and who guarantees the technical adequacy of the product according to need. The system owner is the one who must put the Ops at the product teams’ heart, or more precisely alongside the product owners. He becomes the driving role of the path to the DevOps and makes sure that the DevOps’ mantras that we saw in part 2 are implemented and respected.
Unlike Spotify, which makes it a relatively transverse role by being a referent of the system with all the squads intervening on his perimeter, the proposed owner system must be able to integrate and dedicate itself vertically in a train, a tribe or an autonomous DevOps team. His role is to accompany the product owner and put the Ops in the device as well as Dev. Thus there are multiple missions that it is defined by:
- He builds the mirrored technical backlog as the product owner builds his own
- He advises the team on the available technical bricks’ usage in the service catalog or through the skills provided by the platform team
- He sees to the construction of an emerging architecture
- He generally favors the emergence rather than the construction of big planning and the choice of an a priori solution (big plan up-front)
- He ensures the installation of the CI/CD pipe
- He maintains the link to the platform team and the piloting of the run.
- He feeds the teams’ platforms with innovation needs to meet the business needs
- He promotes the continuous interaction between Dev and Ops
Through these missions the system owner integrates himself into the different types of organization that we have had the opportunity to present: In SAFe he becomes the train’s technical reference that allows to maintain a constant alignment between the SCRUM’s team, the system team, and the architects system. In a standalone DevOps team on the DASA model, he will make the link with the platform team, accompany the system architect and Ops to take on a different responsibility by including the adoption of DevOps’ mantras. Finally, he allows existing operational project managers to be able to project their future role in a DevOps organization, and this is obviously a guarantee of involvement in the transformation.
Of course, we still need to train these new system owners who become the missing link in the evolution process from an ITIL organization to a DevOps organization.
With my personal thanks for the proofreading and the invaluable help of Nadia Djelassi, Pierre-Antoine Joly a. I also thank all those who took the time to add their comments and those who have shared this series of articles.