A practical path to DevOps maturity
Any agile methodology is futile without real DevOps practices. The buzzword was misused in many organizations. If you say you have matured agile teams and you have a DevOps engineer or DevOps team, who are probably not going in the right direction. DevOps is a culture rather than a team name or designation. Taking a cue from CMM (Capability Maturity Model) this attempt is to help an organization to know where they stands in a DevOps journey and way forward. With some brainstorm between Development and Ops teams this can be expanded and customized to organization needs.
No number is bad as for as it helps an individual or organization to grow.
Unlike CMM, this is not a model that you need to prove to any certification organization. The only certificate you get is from your happy customers or business partners. It is a model to self reflect and and help business to grow. The very purpose of any IT team is to create value by doing sustainable, predictable delivery with quality.
This is a simple model that from Developer to CxO can understand and relate.
Before i discuss about the model. We need to understand need for this model. Many years ago, Melvin Conway in his paper “How do committees invent?” came up with thesis which became famous as Conway’s law.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
The law is based on the reasoning that in order for the software modules to function, multiple people must communicate frequently with each other. Therefore, the software interface structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult.
Lets look at how this works in software development with a real scenario. Radha is building a front end screen which shows detailed attributes of a product. Say this product is a mobile phone. Few common product details are color, price, dimensions, ratings etc. A new regulation came to display SAR value of the handset. The screen that she designed works with micro service call. She spoke to Sunil who works in data team. He said they can only send data in flat file. There is a clear disconnect between two modules. This is a scenario every IT team comes across if not all the 100% times but majority of times. This is just a design issue. The problem is wider. What if the other team’s priorities are very different from what your team is doing? Your requirements may be lowest priority for them while your stakeholders are running behind you.
The first step to successful DevOps implementation is to be open with organization changes.
Let me discuss 5 levels of maturity:
- Initial: In this phase, teams work in silos and there is only, need based collaboration. In a meeting with all the teams together, if you ask who owns the “Product” you will not have any hands raising. Time to market is typically longer, going to months and sometimes years. Priorities are set at team level but not at product level. This will lead to each team having their own priorities. As there is no defined process, every attempt is like reinventing the wheel. This will lead to quality issues and longer timelines. Team mostly does manual deployments and manual interventions. Well.. this is not a bad state. This is how most of the development would start.
2. Repeatable: Teams still work in silos. There is some level of automation within the team. When a crisis hits, team defines their own process and follows until the crisis ends. Only good news is some of these can become repeatable processes when the crisis hits again.
3. Defined: This is a good starting point to seed DevOps culture with a centralised team. This team understands various technologies Dev teams are using and tooling is based on the current need. Being a centralised team, it is not easy to monitor what each team is doing and so some decisions are left to teams to experiment. Central team typically consists of experts and dev teams will have some people with basic understanding and knowledge.
4. Managed: As the central DevOps team understands organization tooling landscape, multiple environments and tools are tested. Consistent and repeatable processes are followed by multiple teams. Tool chain is selected based on use cases rather than personal choices. Monitoring tools for all the processes are introduced and heavily used by teams to make decisions.
5. Optimised:
Success of a good leader is defined by not having followers but by the ability to create great leaders.
Final stage of DevOps maturity is to make the DevOps team disappear. This might look like counter intuitive. At this stage, DevOps is part of Product development team rather than a separate entity. Using infrastructure as code, containers, orchestration etc. zero touch deployment is achieved. Now if you call everyone who is working on a product and ask who owns the product, you will have some confident hands raising without any hesitation. Data from monitoring tools is used to select new set of tools (including infrastructure, programming languages, techniques). Decisions are based on data rather than personal preferences. Product team is ready to deploy code any day and any time. They love the “business value” and treat it as a pet. Everything else is treated as cattle.
