Adopting Enterprise DevOps

DevOps is a philosophy to drive business efficiency within the organisation, often described as a transformation and a culture shift. DevOps isn't just a bunch of tools that Non-IT and IT team (like, Business, Dev, Test, Security and Ops etc...) can buy and rollout into the practice to realise the value. It requires thorough planning, continued focus & attention, the right approach and drive from leadership with the right team model… such as creating a DevOps CoE.

No matter what organisation you are and where you are on your transformation journey, transitioning to DevOps or maybe just a journey to deliver Business Efficiency. It's always helpful to hear from those who have been there, done that, and learned along the way.

Below are some of the key considerations from my side, some of them maybe you already using it and some of them are there for you just to disagree with me…

First Thing First - It's not for everyone: Create a separate DevOps team. It’s critical that any organisation transitioning to a DevOps has a separate DevOps team that coordinates with the software development team. Developers and/or testers can provide the mission-critical testing framework and perform automatic testing, while the DevOps team makes sure that the entire DevOps process – from updates to testing to user feedback is completed and shared to the entire product team.

Another thing to consider in DevOps is that it never really ends. Unlike most software development with a clear beginning and end, in a DevOps, there is a constant cycle of incremental updates, testing, and continuous feedback, which then flows back into new updates and cycle goes on and on.

And if it stops, it’s not DevOps! 

Finally, know that DevOps is not for everyone. While many enterprises are embracing DevOps, it’s not something all software solution or product should be jumping into blindly. For e.g... Legacy apps and desktop-based are not easy to move into a DevOps, so any project with those types of applications might want to first consider transitioning to web-based apps / Microservice-based architecture, etc.

Adoption - Ways of Working and Ways of Thinking: We are on a DevOps journey with many major successes already, especially since our on-premises focused days when we would have a release every one to three months, now we deploy builds continuously - multiple times a day with validation. Recently, I thought at the beginning that I may have to go to the partners to help with our DevOps transition in one of our Squad but were surprised and proud of the way our existing Engineering CoE stepped up to solve the puzzle and get us to where we are today. Strong support and trust from senior-level management made it possible and the dream comes true.

Most of the major and complex transitions take much longer than expected. Be patient and look for steady progress. It is not practical to stop everything else the team is doing and focus only on the future state. It is important to make incremental progress. Avoid bringing in tactical approaches. DevOps is a way of working and art of adoption, not just tooling stuff. Everyone in the organization needs to adopt a DevOps way of thinking. So, while top-level direction, vision, and evangelism are important, equally important is a grassroots adoption by the staff who believe in the change. Do not get attached to any particular tool. Using a particular tool or deployment method or process should not be the goal. The goal is to continuously deliver value and create an awesome customer experience.

Focus on ‘Value Delivered’: One thing to be carefully considered and looked that DevOps team and other Project IT teams work in collaboration and don't lose touch as their tool stack, development and other approaches may deviate. The potential for a new DevOps schism is similar to the old Dev and Ops schism is equally high. Hence, I recommend that best would be to approach DevOps adoption in a traditional IT way but with focus and close eye for the value delivered. Avoid rigid adoption of DevOps for all things, and try to find the right balance between DevOps and traditional practice/governance for the reality of the project and value will be delivered.

There’s no one size fit for all: DevOps is about people, culture, process and tools for the right fit - custom fit, not just some team with ‘as-many-tool-as-possible’. Many organisations/projects get this wrong and establish a DevOps team or CoE ends up becoming a one size fit for all solution and struggles to solve the challenges, DevOps is supposed to address or resolve. If you just have a DevOps team but no endorsement and appreciation of DevOps methodology, you won’t have a true DevOps you may be looking for. DevOps is like any other practices and processes which cannot be a cookie-cutter job. Whoever is taking on the task of DevOps needs to understand that the product they're building and the skill sets they have internally. They need to take the DevOps fundamentals and tailor it to that particular environment.

Integrating Security in DevOps: Security by design, security by code and validate it again in the test is essential throughout the DevOps. While DevOps is very good for shortening the dev, test and deployment cycle, adoption of best practices and standardizing the processes can still take systems-level requirements for granted, such as security. If security is not a consideration during all the phases of DevOps just not only development, it can stop or really slow down the feature to be delivered to production if security needs to be added in for any larger or critical application.

Minimum Viable Metrics: Some organisations just jump straight on implementing tools for development, tools for tests, tools for security and tools for operations before understanding the technical landscape and fundamental issues that need to be resolved regarding any development or engineering practices. If we try to analyse and separate what all can go into Enterprise DevOps, there are five layers: Culture of Collaboration, Agile Development Practice, Effective Engineering Practice, and Test Automation Framework, Continuous Deployment Capabilities, and Right Security Controls. For organizations aiming to improve time to market, they must first correctly identify where within these five categories their current issues lie. Within these layers, organizations must determine if they have issues that hamper team collaboration and process efficiency.

Once you have the above layer then only any organisation can implement metrics it would like to establish to track progress towards successful Enterprise DevOps adoption. The key is to have a few, simple metrics that truly reflect value to the end customer; Minimum Viable Metrics, which can include deployment frequency, average lead time for a production change, average production recover time; and change failure rate in production. To gain confidence and have some lessons learned, I recommend practising these metrics in the pre-production environment which most of the time used for Live-Proving and full-blown performance tests.

A true measure of successful Enterprise DevOps Adoption is an improvement in all these metrics over time.

Operations Agility: What is critical in the DevOps is the ability to monitor and manage applications and systems in a structured way, getting early detection of problems and failures so the development team can make changes before the system get impacted. While unexpected failures make interrupt-driven work unavoidable at times, DevOps journeys can become more proactive by examining their current approach and toolset against business needs to help create a path to continuous service delivery optimisation. Projects need to control and have visibility into their DevOps environment by collecting and instrumenting logs.

Emerging trends such as containerization, microservices, software-defined networking, elastic storage and hybrid clouds are pushing the boundaries of DevOps monitoring.

The right 'Ops' approach enabled by the right toolset and effective monitoring, logging & alerting approach which can identify and resolve the problems before they affect critical business processes or systems and enables to plan for upgrades before outdated systems begin to cause failures and outages for users.