Planning for Devops - Considerations Before Taking the Leap
The primary goal of DevOps is to optimize the realization of business value. The faster you can add value, the more competitive your organization will be. It seems easy on the surface, so why do so many organizations struggle with implementing DevOps successfully?
Moving from a traditional Waterfall SDLC to DevOps practices represents a major shift, not only in IT operations, but in organizational culture and mindset. It requires thoughtful planning and organizational buy-in to implement successfully. Before embarking on the DevOps journey, and it is a journey, here are some things to consider to achieve a greater chance of success.
In many organizations, IT departments are organized by role or skillset that support a distinct part of the development lifecycle. Development, testing, business analysis, and release management are examples of these. In DevOps, these roles are combined into small teams which support a product, application, or technology for the entire lifecycle. If your organization is large, you may be able to support DevOps teams that have one or more people filling each distinct role. In smaller organizations, a single person may need to fill multiple roles on the team. You’ll need to look at your organization and see what works for you, but consider not only new development, but support for production issues, the ability to absorb vacations and sick time, etc.
And what about the business? They are a critical part of any DevOps team. There is a high level of collaboration between the business and IT that must occur to be successful. They must work closely with IT so that requirements are understood and tested. Feedback is also critical so that future efforts can incorporate suggestions and better approaches can be taken. It should be noted that communication is two-way. IT should be free to offer feedback to the business as well.
Managing cultural change maybe the most important component of any transformational change. To be successful, everyone must be on board and embrace the change that will be coming. There will of course be benefits, but the increase in velocity that will result from DevOps will require changes to everyone’s way of working. I think of it in terms of frequency and amplitude. DevOps will help you work smarter but the frequency of activity will increase while the amplitude will decrease. This will actually smooth the ebbs and flows that sometime occur in Waterfall lifecycles.
The combination of Development and Operations introduces the idea of shared responsibility where everyone on the team shares in the successor failure of the product. This necessitates a focus on collaboration where everyone works together toward a common goal. It is important that the individuals on DevOps teams function well with each other, so building the teams with the right people is crucial.
Consider how your organization must operate to comply with government and industry regulations. While DevOps can still operate within these governance structures, many compliance organizations may require time and coaching to help understand how governance controls will still be met. Controls such as“ separation of duties” can still be maintained, often times through automation of certain processes.
Automation, it is one of the most important DevOps tenants and what makes it so powerful. This is where scale and speed are achieved while still maintaining quality. Generally speaking, teams should try to automate as much as possible. This can be accomplished through continuous improvement in the team’s processes. There are many options, both open source and commercial. You’ll need to decide which is right for your organization.
DevOps practices are generally more suited towards products that are modular with a code base suited to quick development sprints and incremental added value. Building large portions of the code to deploy even the smallest of features will result in increased regression testing requirements and increased risk. Refactoring the code is an option, but unless the system is a source of differentiation, the cost may not justify the means.
For many, DevOps represents unfamiliar territory. Unless there are people in your organization with DevOps experience, making a wholesale shift to DevOps is ill-advised. Starting small and getting the process and tooling refined on a small scale first may the best approach. This reduces risk and helps to identify the technology, process, and culture changes that are right for your organization.
Even injecting DevOps concepts into your Waterfall lifecycle can take you closer to your goal. Shift left by engaging testing and development teams earlier in the lifecycle rather than waiting to engage them at their gated project stage. Give regular demos of the system as development progresses and show them wireframes of how the final solution might look to garner early feedback so you can course correct earlier if needed.
Take the Leap
With proper planning and incremental implementation, you can increase your likelihood of DevOps success. There is no one right answer. Establish the practices that work for your organization and improve the overall outcomes of your development efforts. Remember, the goal of DevOps is to increase business value. Every step you take towards DevOps is one steps closer to the goal.