How to implement DevOps without buying new tools?

Feb 1, 2016

Capgemini

DevOps is the new thing in IT. Many of our clients are either considering implementing DevOps or are well underway. For the moment, I’ll leave aside the question what DevOps actually is, because there appear to be as many interpretations of this as there are implementations.  The purpose of DevOps however is pretty clear: reducing the time and effort it takes to put software into production and allowing for more frequent production deployments. It is the companion of Agile but tackles the speed problem from the back-end of the SDLC (deployment, QA, environment control) rather than the front-end (requirements analysis, code development, integration testing).  Where Agile seeks to bring together business owners, developers, architects and testers, DevOps seeks to bring together final QA, environment operations, DBA, code management, and deployment operations.

It is obvious from the purpose of DevOps that to improve speed you will need to improve the level of automation in any of the steps involved in the deployment processes. And in order to improve levels of automation, tools are needed. So, what tools should you have? Certainly you’ll need test automation, plus you will need tools to automate the commissioning and de-commissioning of compute environments in your data center or the cloud, you will need automated source control, coupled with the ability to do “push-button” deployment to target environments, you will need a CMDB and a change control environment coupled with workflows, etc. etc. Ideally, all these tools need to be integrated with each other to “seamlessly” work together, and in turn, be integrated with the front-end development tools. You will now understand why DevOps is a technology consultant’s nirvana. Years can be spent evaluating and integrating all of this stuff, requiring expensive people with point expertise in all of these tools.

But wait. Perhaps none of this is a pre-requisite: As in any process, actual processing time is only a fraction of total lead time. So, rather than trying to get processing time down, an initial DevOps implementation should probably focus on all the non-processing time first. Reducing non-processing time is largely a matter of re-thinking how the entire process is organized, all the different organizational entities involved in the process and how to re-arrange these pieces for maximum speed and efficiency. For this, you will not need any tools beyond what you already have in house.

So, now that you know you can start to implement DevOps without having to buy new tools, what’s remaining is how to measure success of your DevOps initiative. I have a different perspective on this from what is normally presented. Stay tuned to my next blogpost to read all about it.

About the author

Kasper de Boer

Vice President | USA

Kasper de Boer is a Vice President in Sogeti US, where he is currently responsible for the Infrastructure Practice. Kasper has 25 years experience in IT Consulting and is particularly interested in IT organizations and how to make these more efficient and effective. He advises clients on how to reduce the on-going maintenance burden of IT systems and technology, achieve better alignment between IT capabilities and business needs, increase speed-to-market of IT solutions, and increase the overall responsiveness of IT. Competencies include IT Strategy, IT Optimization, Agile Transformation, Program Management, IT Cost Reduction, IT Service Management, Enterprise Architecture, IT Alignment, Cloud Transformation Kasper started his career in the Netherlands, where he obtained a degree in Mechanical Engineering, worked briefly in France, and has been in the US (Chicago) for the past 20 years.

Comments