In my previous blog, I discussed some of the strategies to adopt DevOps in an organization. I covered how important it is to have the senior leadership fully onboard with the DevOps principles and methodologies. Plus, we looked at setting high-level goals and an initial high-level assessment.
This blog will continue the focus on what it takes to complete a detailed assessment. This is a deeper assessment of all the products/applications in IT. It can be a self-assessment by employees in the company but in order for it to be effective and unbiased, it should be done by a firm that specializes in DevOps assessments.
Establish DevOps Champions and a Baseline
One aspect to consider is the importance of establishing DevOps Champions throughout the organization to evangelize DevOps practices, so to speak. These champions should ideally create a collaborative platform so everyone can share their ideas.
The goal of the detailed assessment is to streamline procedures in order to actually enable DevOps in an organization. In the process, we first want to establish a baseline and identify gaps. These gaps and bottlenecks might be in the form of delays caused by cumbersome processes or delays caused by a lack of automation and collaboration, for instance.
In order to establish this baseline, we recommend reviewing the complete flow i.e development lifecycle all the way from requirements gathering to production support. We want to see how developers, QA, and Operations folks interact with each other. What processes and tools are currently in place? We also would want to understand the current team structure.
Identify Key Resources
So what does this assessment look like?
Details Assessment usually consists of first identifying key resources in all the teams. You should have at least one representative from each of the following teams:
- Product Managers
- Project Management
- Architecture Team
- Development Team
- Quality Assurance (QA) Team
- Information Security Team
- Operations Team
- Release Management Team
Additionally, depending on the structure of the organization, we might also want to interview leaders in the organization such as platform leaders or directors that manage multiple teams or products.
Identify Assessment Areas
The assessment might consist of detailed interviews, questionnaires specific to each group, shadowing of their daily work if necessary, and reviewing any relevant documentation or artifacts. Essentially we should get as much information as possible in the following areas:
- Agile Practices
- Schedule and Team Structure
- Technical Debt
- Source Code Management process
- Source Code Integration and Build process
- Current Testing Processes in place
- Application Release and Deployment Process
- Server Configuration and Management
- Application/Server Monitoring and Logging Process
- Existing Tools in place
- Automation in place
This detailed assessment will be able to surface areas of concern for each team and will allow each team to provide an honest baseline.
Create a Target State
Once we have a good understanding of the current state, we can effectively create a target state in order to achieve our goals. Target state should provide details on one or more of the following DevOps categories depending on the priority:
- Continuous Integration
- Automated Testing
- Continuous Deployment and Release Management
- Configuration Management
- Issue Tracking
- Application Performance Monitoring
For more information on these DevOps categories, I recommend watching these videos on MSDN. [I plan to cover these categories in more detail in another blog.]
Create a Plan to Reach the Target State
Now we can finally focus on how we are going to reach our target state. We are now ready to tackle our problem areas and implement DevOps practices and tools to reach our target state. This is accomplished by creating a detailed remediation plan for each problem.
Let me further explain by an example. Suppose during the assessment it is discovered that the teams currently lack automated tests and that most of the testing is done manually. When an application is passed over to the QA team it has high defect rate resulting in very long testing cycles.
The target state will state something to the effect that the team needs to adopt DevOps practice of Automated Testing. It will further elaborate on what kind of automated tests will need to be implemented (unit tests, integration tests, smoke tests, regression tests etc.). Remediation Plan will then provide details on DevOps practices and tools that will alleviate the problem. It will provide strategy on how to implement the recommended tools and practices.
Before devising a remediation plan, it is important to identify quick wins and choosing carefully where to start. It is not advisable to start with a big bang. Get some early wins and broadcast those wins throughout the organization.
Identify Candidate Team
It is also important to find teams that are good candidates to implement remediation plan before it is implemented across all the teams. A dedicated DevOps team might be required depending on the size and type of organization. As Gene Kim pointed out in his book, “The DevOps Handbook”, one of the inherent challenges with DevOps initiatives is they are often in conflict with the existing delivery schedule/processes. It may not always be possible, but a dedicated DevOps team should also be created that can operate outside of the rest of the organization that is responsible for daily operations.