The two previous posts addressed the importance of knowing who's involved in DevOps and what your challenges might be. Now let's look at what you can do to get to the mindset necessary to be successful.
The three key areas to address are culture, process and technology, and business goals/KPIs. Think of it as a three-legged stool. If any of those legs are unstable the whole structure is unstable.
A good culture thinks collaboratively, shares a common vision, and is always building for predictability and repeatability. This is not easy to achieve. Even on a small scale, a cultural transformation is challenging.
To get there the organization must strive to embrace change from the top down. Even the most open and collaborative organizational cultures are subject to inertia that hinders change. To help get things going, leadership must clearly articulate the vision. Then they can influence their organization by driving out fear, breaking down the organizational barriers that impede collaboration, and creating an environment of high energy that will help inspire teams to buy into the vision.
There is no one-size-fits-all approach to accomplishing this. Many different organizational change techniques can be applied. It is imperative that the organizational culture change be part of the recipe for implementing DevOps.
As you grapple with the cultural aspects you can also start to consider process and technology issues. They are both addressed by defining a DevOps framework of standards. Make it clear in your framework what DevOps means, how it is to be applied, who participates and when, and what technology is to be used. And then make sure everyone adheres to the standard.
This will help set clear expectations on how deliverables are to be built consistently and reliably. Document them and train your people on them. Don't let everyone guess what the answers are; describe them openly so that you leave little room for interpretation.
Many different areas must be covered when setting those standards. You will certainly have more than what is listed here. But here are some key considerations:
Backlog: Write your user stories in a consistent format. Using Agile canonical form? Great! Just make sure you do it consistently and everyone knows what it means. Ensure your acceptance criteria are well defined. Have more than just product managers and engineers contribute to the backlog. The other DevOps players like operations and security are key contributors. You will want their perspective and requirements to be implemented.
Coding Practices: Define, document and train your engineers on standards that cover the quality of your coding. These are affectionately called the "ity's": usability, reliability, securability, manageability, deployability, testability, etc. They cover the non-functional requirements essential to the DevOps approach. Think about the downstream impact your code will have on testing, deployment and managing your software. Scrap and rework is expensive and defeats the purpose of DevOps. Building this kind of code quality earlier in the process increases the likelihood you will reap the benefits of DevOps.
Architecture/Infrastructure: Development and test environments should be designed to be as close to identical to production environments as possible. More variation in the environments used to build and test from production environments results in more risk of defects and vulnerability findings downstream. Address this by getting your software and infrastructure architects together to define a cohesive architecture. Ensure that the software architecture is designed with the infrastructure in mind and vice versa. Consider every aspect of the application stack, operating system, network, storage, security, and so on. Then make sure everyone in every phase of the process is using the same architecture.
Security: Make sure you know how secure your service is. You will likely have security compliance standards to adhere to. You will want broad coverage for vulnerability and penetration testing. However, you also don't want to hamper your release readiness with disagreements over the severity and applicability of security findings. First, try to avoid these with good secure coding practices. Second, make sure that your engineering, QA and security teams agree to the toolsets used, acceptable configurations for the tools, and a standard methodology for interpretation of results. As mentioned before, the more that can be caught in the development process the cheaper and easier it is to fix. If and when findings occur, make sure there is a well-known SLA in place for remediation.
Release Train Process: Don't let the interlock be guesswork. Document the whole process and publish a schedule. Everybody needs to know how and when they will need to participate. Make it predictable and repeatable.
Cohesive system of record: Provide a foundation for strong governance to the overall process. There will be a lot of tools in use by your organization for various capabilities. They all contribute to a specific need, but likely none of them alone will give you the visibility you need to manage the whole process. Roll up information into a centralized system that can aggregate all the activity data and drive approval and workflow. This will provide you a place to manage the coordinated interlock of activity and layer on the governance the process needs.
Measurements/KPIs: You can't manage what you don't measure. Make sure you have identified what data will give you the proper insight to the overall health of your process and what allows you to measure the value to your organization. Then represent it in a discernable and actionable way.
While it is mentioned last, setting business goals should be in the forefront of everything you do when implementing DevOps. Don't just look at DevOps as a technical process for the propeller heads in your organization to work better together, but rather how it will impact the business. Are there tangible business outcomes you want to achieve? Can you show how DevOps can get you there?
Setting business goals will help get everyone on the same page since they will understand why you are implementing DevOps. It will also help sell the investment to the business to make the changes.
All of the work required to implement DevOps costs time, money, and effort. Don't assume that implementing DevOps will be something that people can just do as part of their day job. Once implemented, it will be their day job. Prior to that you will absolutely need time to take people away from their day-to-day activities to make this work. Make sure everyone knows why they need to participate and what they are trying to achieve for the business. And don't forget to make sure the budget is there to allow the participants to participate.
There are tools in DevOps. There are processes. But it's the mindset that will get you there. Take your time to get it right and it will reward you.
1 Comment
