DevOps Debates on DevOps.com
We had a very nice, involved, hectic, hands-down involvement into our next version of the platform. Really excited how it is shaping up. This kept me away from blogs and posts. Apologies. You will very soon hear about our CloudMunch 2.0. But I am now back into the blogging spree.
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 kicked off my “DevOps Debates” series in DevOps.com
The first one came live yesterday, and it is as below. I thought I should share the same with you all as well. Lets debate and get the right thing out.
Please send in your thoughts.
Investor | Advisor | Founder | Technology Leadership
9 年Ashish - thanks for your comments. You make a lot of sense.
DevOps, AI-ML Outcome-driven Intrapreneur | Thought Leader | International Speaker | Innovator | Futuristic | Builds High Performance Teams | Global Leader - Digital Transformation
9 年My 2 cents - In the evolving world of DevOps, it would be good to have the teams practicing the DevOps experiment with their way of using the tools for DevOps and then the Central team should pitch in after some rigour to have the best taken from all the teams and standardized across the organizations.....This helps the team on ground to get the ownership, capabilities to experiment and hence be agile and then the best tools fit for the organization are adopted and standardized via a Central team taking DevOps towards maturity........
Senior IT Professional
9 年Nice crisp article, Prasanna! My two cents... 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 superior skill level edge 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 sit well with star programmers/experts. It is very important as to how the standardization is positioned, communicated and how 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. For smaller orgs, since there are many multi-taskers and folks tend to don multiple roles and communication isn't that big a challenge, the benefits of non-standardizing are higher.