8 Key Challenges in Adopting DevOps: Part 2 — Solutions
Tags: devops, devopsadoption, digitaltransformation, devopsengineer
Published: 2020-04-28 05:27:43

In part one ([here](https://dev.to/iamnajibradzuan/8-everyday-challenges-in-devops-adoption-and-how-to-solve-them-challenges-part-1-18ba "here")) of this two-part blog series, I looked at the 8 key challenges I see organizations facing when they are adopting DevOps. Now, let’s look at some solutions.

> **Change** is hardest at the beginning, messiest in the middle and the best at the end. — [Robin S. Sharma](https://www.robinsharma.com/about-robin "Robin S. Sharma")

**1.Making Culture Function According to DevOps Principles**
DevOps leaders and change agents will need to find ways to continuously educate teams and people within the organization about what DevOps culture looks like and why it accelerates the flow of value. Here are some things I have tried that have worked:

**Learning and Communities of Practice**
The DevOps personnel can arrange internal training or introduction presentations for DevOps adoption and give exposure to DevOps culture. This way they can promote and meet face-to-face with everyone in the organization. Face-to-face collaboration is preferred over using email or video conferencing as humans build trust faster this way so it’s recommended to undertake a roadshow if teams are dispersed, aiming to meet everyone at least one in order to build relationships.

**DevOps Knowledgebase & FAQ**
DevOps teams can create a knowledgebase or Frequently Asked Questions (FAQ) and share with all people within the organization, hence everyone knows where to get information to relate to DevOps where they need it. The visibility and easy access to the information that motivates them to search and read it by themselves and even contribute. This kind of information can be held in collaborative platforms such as Atlassian Confluence or Microsoft Teams.

**Applying Westrum Organization Culture Practices**
We can use [Westrum Organization culture](https://cloud.google.com/solutions/devops/devops-culture-westrum-organizational-culture "Westrum Organization culture") practice to make a generative culture that cultivates data stream and trust by looking at the six parts of Westrum’s model of hierarchical culture, concentrating on those practices found in the generative culture;
![westrum](https://github.com/iamnajibradzuan/DEVPost/blob/master/westrum%20culture.jpg?raw=true)

Here how you can build a Generative Culture;
![generative culture](https://github.com/iamnajibradzuan/DEVPost/blob/master/Generative%20Culture.png?raw=true)

**2.Addressing Resistance to Change**
Leaders have to expect that people will resist change. According to DevOpsologist, Philippa Hale , in her article about stakeholder mapping tools and she discussed how we can address certain group people’s moods and emotions toward changes then we can apply different engagement strategies to approach them toward DevOps initiatives. There are 6 “behaviour profile” and how we can engage with them as below;

![mindset](https://github.com/iamnajibradzuan/DEVPost/blob/master/change1.png?raw=true)

**Unengaged**
![unengaged](https://github.com/iamnajibradzuan/DEVPost/blob/master/Unmanged_Change1.png?raw=true)

**Spectators**
![Spectators](https://github.com/iamnajibradzuan/DEVPost/blob/master/Spectors_Change1.png?raw=true)

**Cynics**
![Cynics](https://github.com/iamnajibradzuan/DEVPost/blob/master/cynics_Change1.png?raw=true)

**Critics**
![Critics](https://github.com/iamnajibradzuan/DEVPost/blob/master/Critics_Change1.png?raw=true)

**Enthusiasts**
![Enthusiasts](https://github.com/iamnajibradzuan/DEVPost/blob/master/Enthusiasts_Change1.png?raw=true)


**Advocates(Champions/Experts)**
![Advocates)](https://github.com/iamnajibradzuan/DEVPost/blob/master/Avocates_Change1.png?raw=true)

To summarise based on the above, we can see all engagement approaches involved communication and stay informed about the DevOps adoption. We need to get closely work with all groups and be visible to them and give help whenever they need one.

**3.Bringing Clarity to the DevOps Vision**
Introducing the DevOps [CALMS](https://itrevolution.com/devops-culture-part-1/ "CALMS") framework can help define the DevOps roadmap and goals. CALMS is a conceptual framework for the integration of development and operations (DevOps) teams, functions and systems within an organization.

![calms)](https://github.com/iamnajibradzuan/DEVPost/blob/master/CALMS1.png?raw=true)
DevOps leaders need to develop a clear roadmap for DevOps evolution with clear improvement phases. They must share it and make it visible to everyone within the organization;
![continuouslearning)](https://github.com/iamnajibradzuan/DEVPost/blob/master/continuouslearning.png?raw=true)

**4.Creating Cross-Team Collaboration**
The development and IT operation teams need to learn to collaborate. This may mean creating cross-functional teams including both dev and ops, but this doesn’t work in many organizations. It’s often too dramatic an organizational change, or there is simply aren’t enough people to go around. Traditional technology department set-ups also tend to include deep subject matter expertise in IT operations around security and networking for example, so it’s difficult to see how to share these types of people across development or product teams.
What does help is having both the development and IT operations teams meeting regularly? If development teams are conducting daily scrums as part of their agile practices, inviting IT operations to participate can help with impediment removal. Inviting them to sprint planning can ensure those non-functional requirements are considered in the sprint, thus streamlining the value delivery process.
Cross-team communication tools such as Slack or Microsoft Teams really help here by making it possible for collaboration to be continuous. The “Alert/Notification” chat group or channel also needs to be properly managed, so that issues can be directed to the correct team and escalated fast using the correct action to take to solve the issue/bug.
Here are some collaboration tools that you may use and start collaborate within your organization;
![collab)](https://github.com/iamnajibradzuan/DEVPost/blob/master/collab%20tools.png?raw=true)

**5.Standardizing Environments**
An environment is a collection of resources or targeted places that you want to convert from code into a real product via the pipeline. The environment may include Virtual Machines (VM), Database Servers, 3rd-Party services etc. Below is an example of environment stages with its usage, user/persona, and person-in-charge of maintaining the environment;
![env)](https://github.com/iamnajibradzuan/DEVPost/blob/master/env.png?raw=true)

The advantages of having a well-defined environment include the following;
**Deployment record/history** — All pipeline run details are recorded in CI/CD tools for its resources.
**Traceability** — It allows one to track whether a code change (commit) or feature/bug-fix (work items) reached an environment.
**Permission/Control** — a secure environment by specifying which user is allowed and which target environment to deploy.

Automation environment provisioning is a major factor of success in a continuous delivery process. Can the Dev team request a new environment ad-hoc and are your environment being provisioned on-demand as application deploy? The application environment can divide into 3 main areas:
1. Infrastructure
2. Configuration
3. Dependencies

**Infrastructure** is the place where the application or service being deployed and the application will run specific configuration needs. It also includes how dependencies need to integrate with the application. As of today, infrastructure can be provisioned by script or they call it “**Infrastructure as Code**” or in short **IaC**. IaC is made more accessible today through a comprehensive range of tools available for automating the entire environment provisioning process.
**Configuration** is the next most consequential aspect of the application environment. Configuration dictates both how the application comports in a given infrastructure and how the infrastructure comports in cognation to the underlying application.
**Dependencies** are all the different modules or systems an application depends on, from libraries to services or other applications.
The benefit of using automate environment provision as follows;
- Reduced complexity by allowing DevOps teams to work at a higher level of abstraction.
- Increased stability by enabling applications to dynamically respond to their deployment.
- Increased flexibility by decoupling configuration management from an application’s specific hosting environment.

We have many tools available in the market whether it’s open-source or enterprise that we can use to do automate provision for all 3 areas mentioned above such below;
![env_stdrd)](https://github.com/iamnajibradzuan/DEVPost/blob/master/env_standard.png?raw=true)

**6.Standardizing the DevOps Toolchain & Providing it as Self-Service**
Once the DevOps adoption goals and processes are defined, we can determine the toolset required to meet the processes. Make sure the development and IT operation teams work together to decide on the tools suitable for the organization. With any new tool that is introduced, existing workers must be trained. It’s also essential to ensure that the tools meet security requirements and are well-integrated with existing resources and services.
![toolchain)](https://github.com/iamnajibradzuan/DEVPost/blob/master/DevOps%20Toolchain.png?raw=true)
> Just name a few toolchains available in the market for the above sections.

**7. Accelerating Release Management**
Once we have properly defined our environment, the DevOps leaders need to create a proper release pipeline which when we need an auto-trigger for deployment, when need pre-deployment approval gate and when the QA/testing stage need be placed. The below picture has shown a basic release pipeline with combine auto and manual deployment;
Once you have a proper release pipeline, the automation of building, integration, testing, & delivery, and other processes, it will reduce the human activities in every release as well as the amount of management and coordination required.
As development acceleration has become a competitive advantage, the DevOps team has sought to enable Continuous Integration and Continuous distribution (CI/CD). CI/CD helps developers and IT operations overcome a huge hassle on the software development and testing process. Over the years, software development has migrated from the enterprise level, where there are broad resources, to smaller development teams that race to keep pace with demand generated from billions of smartphones and other mobile consumer devices and platforms. Below is an example of CI/CD pipeline with the combination of toolchain available;
![release_plan)](https://github.com/iamnajibradzuan/DEVPost/blob/master/release_plan.png?raw=true)

In our case, we opt to utilize a combination of tools as it seems to provide the best solution for our complicated needs. Most teams developing enterprise products would benefit from such a ground-up approach. Our toolchain stack consists of,
**Atlassian JIRA** — a tool for team collaboration from the Product backlog, Sprint Planning and Report of release and how well the Agile team doing in each sprint.
**Github** — a Distributed Version Control System (DVCS) where the developer communicates with each other and collaborates to make product feature code better and visibility on changes and code versions. Any changes have to be reviewed by other developers or the Code Reviewer which made code more cleaner and less error/bug.
**Azure DevOps** — it’s a tool we use to orchestrate our CI/CD pipeline and it’s also the place where more collaboration between DevOps Engineer, Developer, Release Manager and QA team. It’s also the place where integrations happen in order to deliver a product with good quality which is why we have security analysis and QA testing before we deploy to the production environment.
**Datadog** — It’s a monitoring tool which with Datadog, you can monitor your servers, your clouds, your metrics, your apps, your team together. It’s like a one-stop for all kinds of monitors for your environment and products.

An efficient CI/CD pipeline can significantly improve the time to market and avail maintain stability and quality of the software are distributed.

**8. Automating Testing**
DevOps promotes automation and it’s goals to do as many automation as possible of all daily basis tasks that don’t require human interventions. Add QA experts into DevOps team composition will help the team decide the best approach or testing tools can be automated. Automation tools generally work when it comes to testing for application or system errors, but QA testing does a much better job of testing for usability and release readiness.
Integrating automated continuous testing to your CI/CD pipeline requires an application testing implement that’s easy to integrate with the build, test automation, and CI/CD implements you already use and that has extensive web API support. The benefit of using automated continuous testing as follows:
**Stability**. It helps you to apply quality and security requisites more consistently. If you record a manual security test and then automate it, it becomes a security requirement you can enforce on every build.
**Speed**. With automated continuous testing powered by scalable tools, developers can find and fine-tune issues in genuine time throughout the SDLC. Doing so expedites application development and avoids errors common to manual testing.
**Scale**. To scale manual testing, you require more manual testers. To scale automated testing, you only need more apps and builds to test.

**Conclusion**
DevOps Adoption is a journey that should start with an analysis of the organization’s architecture and goals. Solving these common challenges in DevOps Adoption will make transformation become much smoother. Over a period, every team or person in the organization will get used to the DevOps changes and adapt to the continuous learning processes. Once the Development, Operation, and Management teams learn how to cooperate, they will automatically be helping each other out and collaborating closely to archive DevOps Adoption goals.