As my role demands, I work with various large enterprises looking at implementing DevOps to improve their software delivery cycle times. I have seen many strategies being adopted by them—some working, and some not working yet. I have pulled together some of the more common ones so we could debate them to see if these indeed are worth looking at. With that, I kick off my “DevOps Debates” series.
The first one on the list is a popular one: If you want to create anything in large volumes, you need to standardize the manufacturing process. That makes it easier to understand what is going on, control the quality and later change processes if necessary. This is happening in a similar fashion for software delivery processes and in DevOps.
Standardization techniques adopted in many large enterprises often include standardizing the toolset used by software developers. To do this, companies create a centralized tools group or software center of excellence (COE), which tries to find the best tool for the company and then implements and manages it for the teams. The intent is to streamline DevOps implementation across the board by having a common DevOps platform that hooks into these standardized tools, delivering common practices and reporting.
I have seen and heard a lot of emotional discussion on this. Here is my go, for and against the topic. Your thoughts are most welcome!
For Standardization:
- Centralized teams can take a global view of how things are being used across the organization. As such, they are better placed to push best practices where necessary and learn best practices when they need to. This helps in picking the right set of tools.
- Centralized teams can create a generic DevOps platform that can serve the needs of the organization across all groups. They then can help bring a DevOps focus and manage budget centrally.
- Standardization helps organizations streamline license cost to optimize software use.
- Small teams focusing on DevOps may not have the muscle power or the budget to create a momentum needed for adoption. Running a central body for such implementations helps.
Against Standardization:
- DevOps is still evolving—standardizing may be detrimental to the innovation process that needs to happen within the tools and needs ecosystem.
- Developers from various teams driving a DevOps implementation will be more successful; they can solve the issues “on the ground” rather than a central team trying to understand and then implementing a solution.
- Some tools are good for a specific use and may not be used companywide. Standardization may reduce productivity.
- Developers are the users of the tools—they need the freedom to choose what they want to use. Standardizing won’t allow them that freedom, which may upset them and, in turn, lead to decreased productivity.
Would that then mean,
- While it is a good idea in the long run to standardize, is now too early to do it?
- Would it be better to create a DevOps platform that can provide multiple tools support while standardizing the organization’s needs?
Thoughts?
Great article!
In my limited experience, the presence of a core tooling team doesn’t (or rather shouldn’t) limit the creativity of individual product teams who would want to try out a new tool or a methodology. This team could use its wisdom/experience in the organisation to guard/alert the team against likely pitfalls. The way I look at it, this team would actually *encourage* teams to try out new things and share it with the broader community and once institutionalized, owns the roadmap/upgrade-plans/scale-ability of the tool etc.The last thing this team would want to be is a roadblock or a bureaucratic overhead to creativity!
Thanks Mrinal. I agree with your views. I have found some enterprises having trouble to get that act together.
I’m working in a large global organisation (approximately 65,000 employees according to Wikipedia – not all IT). It’s currently quite chaotic here, so, it’s only recently that such a ‘core tooling team’ is being gathered and I think this is needed. Such a large company, you end up finding without such standards, there’s a massive spend on various tools across the globe that are very similar and could be greatly reduced if standards were in place. So, at such a size, I feel standards are needed, at least from a pool of available options.
Ross, Accepted. What I have found in some occasions (depends on the team) is that the considerations for picking a standard tool may not always align with the reality on the ground. Given that you start seeing a lot of resistance in adoption. I have seen standardization of process and monitoring working when it does not impact any tools individual contributors use.
So may be a platform which can blend itself into the disparity of tools being used and not imparting any change on individual contributors may work in such a large implementations? Worth a try, Ross?
My two cents, Prasanna…
Pros
1) A central group becomes inevitable when you consider licensing costs for the tools you want to procure. The central group over a period of time becomes better at negotiating and drawing contracts which protects the organization. Of course, the “Con” is that they can tend to not understand the urgency/utility and delay things 🙁
2) The central group if staffed with good technical folks can also become a repository of “Best Practices” and a “Knowledge Sharing” portal where they can pass the learnings across projects.
Cons :
1) Central group tends to lose their “technical” skills over a period of time. Also, the career prospects/growth without continuous hands on in projects are less and can lead to less satisfaction. A possible solution can be a constant rotation of folks from projects into the central teams and again back to projects.
2) Standardization implies a bureaucracy which usually doesn’t go well with star programmers/experts. It is very important as to how the standardization is communicated and how much receptive the group is to ideas from the ground.
Net/Net, it is more or less inevitable for large organizations to have a central standardizing group, but it can only be successful if they can be open, aware and receptive.
Ross, Accepted. What I have found in some occasions (depending on the team) is that the considerations for picking a standard tool may not always align with the reality on the ground. Given that you start seeing a lot of resistance in adoption. I have seen standardization of process and monitoring working when it does not impact any tools individual contributors use.
So may be a platform which can blend itself into the disparity of tools being used and not imparting any change on individual contributors may work in such a large implementations? Worth a try, Ross?
We’re in a agreement on such a tools team and standardisation from within a pool of choices (depending on where the standards are to fit into place). Some things decisions can be driven as a standard across the whole company, but others need to have some freedom of choice to make sure the environment doesn’t turn away good talent by being too restrictive.
Currently we’re trying to reduce the technical debt from too much freedom and investments in a range of tools that do the same or very similar things from having a very non standard approach previously.
Sure Madhu. Thanks for your comments.
We are going through this process as well. This article summarizes the challenges of a tools organization – Maybe the strategy is to go generic before standardizing to ensure adoption. The other challenge is the decision to provide wrapper layer over tools to ensure standardization, easy switching costs, availability etc.