FAQ

Metrics and KPIs are key to a successful DevOps implementation. They are a sanity check to your progress and adoption plan. The goal behind DevOps is to achieve the agility, speed, quality and visibility through operating in a continuous fashion and automation. Accordingly, ensuring that you are achieving the benefits of DevOps is key to your implementation.

DevOps KPIs and Metrics are a mix of business-related and technical measures. Technically you want to ensure that your release cycles are shorter, the number of defects are less per cycle and that the test and deployment efforts are reduced drastically. You also want to set and measure objectives in an aligned manner across the IT lifecycle and emphasis the handover points rather than function excellence. For example, how development hands over to test becomes a key focus on objectives setting to your development and test teams.

Business related KPIs and metrics are measured by attributing improved customer experience to product quality enhancements; or speed to market by measuring the time between project initiation and deployment into production.

The answer two that question is two fold depending on the stage you are in in your DevOps adoption and the definition of what a “DevOps Team” does or is responsible for.

Your target model should be to have “DevOps Champions” that take responsibility of ensuring your organisation is working with the latest and best tools. Also to introduce new trends and patterns into your organisation.

However, if you are starting off, there are Pros and Cons in having a DevOps team. The pros are around giving focus and ensuring the DevOps change is propagated into your organisation and implemented effectively and efficiently. Your DevOps team will be dedicated to make it happen. However, dedicating a team is a large investment that we found a few organisations really wishing to do.

Generally we prefer a “DevOps Champion(s)” approach, in which champions in different teams of the IT value stream are responsible for communicating the value and change that DevOps bring into their functions.

Continuous Delivery is the term used to describe the automation of the software delivery process from build through test to deployment. Generally, continuous delivery automation tools are more of a workflow automation, where each stage is an activity that falls in either the build, test or deployment phases of the software delivery lifecycle.

The practice of continuous integration is a couple of decades old and it was developed as part of the extreme programming principles. The goal is to get developers to check-in their code frequently, where this code is integrated with the rest of the other developers’ code and accordingly dependencies will be highlighted and caught early on. This practice is now an integral part of DevOps in an automated fashion.

There is no standard template for implementing DevOps and there is no standard set of tools that when installed, your organisation magically becomes DevOps’d. Installing automation tools on a waterfall process will produce an automated waterfall process. It will not train your developers to check-in code frequently, or your business analysts to expect a tight a closed feedback loop. It will also not speed up your release cycle if your process is based on quarterly releases.

The reason for the above is that DevOps is not only about automation, it is about the practices that enable the different teams work together in a multi-disciplinary fashion to achieve the DevOps benefits.

Unlike common misconception, the core DevOps concept is not about automation. DevOps is about bringing harmony and bringing down the silos between the different IT teams in the software delivery cycle. Categorised generally as Development and Operations, DevOps aims to bring down the silos across development, test, operations and infrastructure.

Automation came into the picture to execute on the DevOps vision of removing silos and providing a common process that is objectively automated across all teams.

DevOps is not the same as automation. Automation is the vehicle a DevOps implementation uses to execute on the vision of breaking down silos and aligning processes across teams and functions in the IT delivery value stream. However, there are aspects of DevOps that has nothing to do with automation like creating Multi-disciplinary teams, practicing continuous code check-in and quality analysis, creating common reports and objectives and sharing the artefact responsibility across teams. All of these are soft aspects of DevOps are practices and behaviours that automation cannot help with.

The short answer is No, but!. Eventually, by adopting DevOps, you are changing how your organisation is delivering software. How you introduce the change depends on your organisation’s dynamics and circumstances. Some organisations may be ready for a change as part of a larger transformation programme. Others are not ready to drastically transform the way they work and DevOps adoption should be phased slowly and driven by a business case for every phase or activity.

DevOps is a methodology for software delivery regardless of the size of the organisation it is running into. From that perspective, DevOps can work in an Enterprise. However, how you introduce and use DevOps in your Enterprise depends on the dynamics, governance (technical and financial) and processes of your organisation.

In a typical enterprise adoption scenario, introducing DevOps is a gradual and phased process that is based on demonstrating the benefits of each DevOps activity before implementing it. For example, how test automation can reduce the delivery cycle and reduce cost of delivery by eliminating redundancies. Then how continuous integration reduces the cost of quality and improves time to market and so on. The purpose of the phased approach is introduce change in tools and processes at a pace that can be positively adopted by the Enterprise.

Your outsourcing partners replace your internal development, test or operations teams. The goal of DevOps is to automate the end to end process and provide a holistic view across the board. From that perspective, there are certain activities that you would need to do and others that you can outsource to your System Integrators. For example, System Integrators should check-in code into your central source control. You would own the quality modal and thresholds, but they will execute on them in their SONAR (Code quality analysis tool) instance. You hold the Continuous Delivery pipeline, however, the stages of the pipeline are executed in your System Integrator’s domains. There is no specific formula or template to work with System Integrators, but as with DevOps, depending on your relationship and contractual agreement with your System Integrator, enabling DevOps through your System Integrator can be straight forward or require larger effort.