A reference model for DevOps as a Service – Reshaping IT services in DevOps World Series 02
Author
Raminder Rathore : Chapter Lead, Canada DevOps Community of Practice (Toronto) & Global Head – DevOps Practice HCL Canada Inc.
Recap
In our last blog – Reshaping IT Services in DevOps World , we looked at how IT services are evolving to adapt “DevOps as a Service”. Different organizations are redefining their ways of working and are investing time and money for upskilling their people, adopting new tools, creating new cost models and propositions. They all understand that this shift is necessary to mobilize talent. New team structures are formed in the ecosystem that is supported by shared services groups – some call them COEs – Center of Excellence; while others call them COPs – the Center of Practices. This service group continuously measures and tracks DevOps maturity across all the teams and they are in charge to guide them towards success. This shift is a journey that needs proper planning and execution and cannot be done overnight. The senior leadership organizes and plans for rolling out the new model. They identify ambassadors across the business/technology units who act as the first citizens to understand the change and broadcast the information to their teams. But, is there a standard to be followed for rolling out the new structure?? The answer is “YES”, there are multiple models available to refer to and adopt, BUT as the saying goes – “one size does not fit all”. Hence, organizations can refer to standard models but they should tweak the recommended structure that fits in their ecosystem and is well accepted by their teams. Well, the initial steps towards this change will have speed breakers. The leadership needs to stay focused and work with the teams to facilitate cross-skilling and support the inception of new roles and responsibilities.
A reference model for “DevOps as a Service”
As organizations commit toward a new change in their ways of working, it does include-
- broadcasting the purpose,
- revisiting and upskilling teams,
- changes to their team structure,
- investments in new tools, and
- continuously monitoring the journey towards the change.
The new teams are renamed as “pods” / “squads” or simply as “product teams” (there may be more). These teams are self-organized and they collaborate with other teams to roll out products/services. These structures as vertical groups that are supported by horizontal services that include COPs/COEs, PMO, Finance, Cybersecurity, Platform, and Operations teams. Again, the verticals and the horizontals can have different names but they all need to stay focused on the organization’s goal – which is to drive agility and DevOps practices. Introducing new roles ignites this transformation and is very helpful. Take a look at a sample model below-
Every product or service may have one or more pods or say, squads. Each squad is a self-organized team they go by the principle of “we build it, we run it”. Each pod follows the waterfall or agile pattern depending upon the nature of the product/services. The idea is to have small teams that can run independently to develop, test and deploy applications/services. These products/services need supplements, they need expertise from other areas like security, automation, operations, etc. These horizontals existed before too, but in the structure, these teams are rebuilt to work in a collaborative fashion with limited hand-offs and proactive participation. The PMO horizontal works closely with COP to broadcast the new changes, define the purpose for the new change, and ensure the new pods/squads understand and practice DevOps. There are organizations that have a horizontal that offers DevOps services to the verticals. This could be a function of the COP or an automation team that gets refreshed as a team that offers DevOps tools as a service. They are in charge of the DevOps tools and ensure that these are in a working state for the product teams to consume. Such COPs also track product teams’ performance by deriving project and program level metrics that serve as a scale for measurement. They also build standard pipelines that are leveraged by the product teams who now do not waste time installing DevOps tools and building pipelines from scratch.
Thus, each horizontal is committed to building a quality product along with the product teams. So, before such new structures are created, everyone in the organization should be enabled with the purpose of the new structure, trained on new technologies, and agree to work together as a team. The above snapshot is just a sample model, this can further be refreshed based on the organization’s needs. The core idea is simple – develop modular teams that work as one team thereby reducing risk and increasing productivity.
Conclusion
The term “DevOps” has evolved over the past decade and has taken various forms. Organizations need to understand and interpret “DevOps” for their teams. They need to be sure that this concept brings in trust and transparency to their teams. And this is made possible by upgrading or changing their IT operating model. Developers should not be held responsible for DevOps tooling, they should concentrate on building quality products. Horizontal services in the organization need to take responsibility to complement the product teams. The movement towards a DevOps organization is a journey that evolves with learnings and experiences. Proper coaching and leadership support enable organizations towards a successful path.
Looking for some more references with examples? Check out the “Hands-On guide to Agile Operations” a guide to implementing Agile, DevOps, and SRE for Cloud Operations.
Want to be part of the Canada DevOps Community of Practice to contribute? Get in touch with our team or connect with Chapter lead in your specific location.
