DevOps adoption approach: Plan and design

10 min readOct 28, 2019

DevOps is not something you buy; it’s something you do.

DevOps is a re-organization practice that focuses on automated environments, provisioning, and process improvement to reduce cycle time by removing bottlenecks and also an organizational culture shift that promotes breaking down silos and minimizing hand-offs. While this may seem easy on paper, it is not so simple to execute without strong support from the organization.

In its purest form, DevOps is an outcome-driven culture of practices that supports the agile movement. Its core tenet is “culture first”, a mindset of working towards shared goals, versioning, automation, measurement, and improvement. Yes, it’s about culture; don’t get bogged down by tools. I’m not saying that tools are not important — they are. But tools are not the solution. Far from that, culture is what matters; change is at the speed of culture.

My experience has shown that different companies understand DevOps differently and many have undergone multiple failed DevOps projects. I will attempt to shed some light and take a more holistic view of DevOps! The word “culture” refers to when an organization works together to achieve an outcome. When you have developers, IT operations, and quality assurance (QA) melding, all tasked to deliver something meaningful for the company, whether products or services. The most significant benefit is improving communication between cross-functional teams and the confidence in what they are building.

One of my favorite quotes from the late great Peter Drucker is: “Culture eats strategy for breakfast”. If you need to change, start with culture; everything else is secondary. Former IBM CEO Louis V. Gerstner, Jr. echoes this sentiment when he says, “The thing I have learned at IBM is that culture is everything”.

Culture is the catalyst required to achieve and ensure successful projects with the right teams of people applying the right set of processes and technologies.

In this post, I would like to share some of the experience and invite you to a journey of planning and designing a DevOps project. I will discuss what it takes to deliver a successful DevOps project through the different stages of the development lifecycle. The journey starts with the user (e.g. customer, client, software requirement, enhancement request, bug fix, line-of-business, features, idea) in mind. User feedback is an integral part of the process with ongoing development and deployment practices.

What is DevOps?

DevOps is agile applied and refers to a modern software engineering approach aligning with enterprise business objectives that involve:
- Continuous Planning
- Continuous Development
- Continuous Integration
- Continuous Testing
- Continuous Monitoring
- Continuous Feedback
- Continuous Delivery
- Continuous Deployment
- Continuous Operations
of the software throughout its development lifecycle. DevOps fosters a higher degree of collaboration and ongoing, real-time communication between traditionally disparate workflows of developers, IT operations, quality assurance, and infrastructure teams. DevOps is about drilling down on your own organization’s specific problems and challenges. It is also about achieving speed, efficiency, and quality. In essence, it is a culture, a movement, a philosophy of values, principles, methods, and practices to achieve the desired outcome for the organization.

DevOps key business values

Long gone the days where the business perceived IT as a cost center. In recent years, IT has taken center stage with a much more significant role. It can generate revenue, innovation, and competitive advantage with a tangible business outcome:

Time to market: Reduced cycle times and higher deploy rates.
Cost efficiency: Increasing automation eliminates effort, thereby significantly reducing labor costs.
Higher stability: All changes can be tested against the entire canonical software system resulting in higher stability.
Frequent releases: Deliver features more often. Automating the process removes the operational constraint.
Production ready code: Releasing software does not require additional effort. Version is always ready for release.
Predictability: Offers significantly lower failure rate of new releases.
Reproducibility: Version everything so that earlier version can be restored anytime.
Maintainability: Effortless process of recovery in the event of a new release crashing or disabling the current system.

DevOps values: CALMS

CALMS is an acronym for the five major points that describe DevOps culture. It is a culture of continuous improvement and a sense of urgency to meet the demands of a software-for-profit model on the values that guide DevOps where people over process over tools.

Culture
- Focus on people
- Embrace change and experimentation
- Operations integrated throughout the development process.
Automation
- Continuous delivery
- Infrastructure as code
- Driving entire lifecycle with the automation of processes, tasks, and decisions.
Lean
- Focus on producing value for end-user
- Small batch sizes
- Service broken into smaller pieces and released frequently.
Measurement
- Measure everything
- Show the improvement
- Integrated measurement and management designed into the entire development lifecycle.
Sharing
- Open information sharing
- Collaboration and communication
- Feedback built into the process at several steps but with emphasis on production, especially customer experience.

DevOps terminologies, phases and practices

Before we go further, let’s make sure we’re speaking the same language. It is of utmost importance to master the DevOps terms and to not confuse the definition. You are only required a few seconds to go over the terminologies and make sure the air is clear by having a common understanding of the industry’s tools and methodologies.

Continuous Integration: Continuous Integration (CI) is a software development process where a branch of source code is rebuilt every time code is committed to the source control system. The process is often extended to include deployment, installation, and testing of applications in production environments.
Continuous Delivery: Continuous Delivery (CD) is a software engineering approach in which continuous integration, automated testing, and automated deployment capabilities allow software to be developed and deployed rapidly, reliably, and repeatedly with minimal human intervention.
Continuous Deployment: Continuous Deployment (CD) is a software development practice in which every code change goes through the entire pipeline and is put into production automatically, resulting in many production deployments every day. It does everything that Continuous Delivery does, but the process is fully automated, and there’s no human intervention at all.
CI/CD: Acronym for Continuous Integration (CI) while (CD) stands for Continuous Delivery and Continuous Deployment.
Delivery pipeline: An automated sequence of steps to perform CI/CD
Version Control: Maintains different versions of the code with source code management

**Figure 3: Continuous Integration vs Continuous Delivery vs Continuous Deployment**

Code: Code development and review, more effective use of source control tools
Build: Introduce continuous integration tools to automate the build process
Test: Test and determine performance using automated QA
Package: Pre-deployment activities
Release: Change management, release deployment (Development and Operations team)
Configure: Infrastructure configuration and management, infrastructure as code
Monitor: Activity performed by the Operations Team

**Figure 4: DevOps Continuous Collaboration and Communication**

DevOps process flow integration and automation

Integrating DevOps practices with automation is something new for most companies. Too many technical and cultural changes to IT, causing infrastructures and applications teams to cope with their own set of challenges. They are required to swiftly and effectively adapt to these changes while responding to the business requirements by coming with new build, package, and verification processes. Relying on automation to:

Standardize development, test and production environments.
Effectively deploy and manage cloud resources.
Eliminate error-prone, time-consuming manual tasks.
Improve cooperation between development and operations.
Implement automated release pipelines.

**Figure 5: DevOps Process (one commit end-to-end)**

DevOps requirements

It’s a matter of understanding your requirements when it comes to process automation, over- and under-automation both are problems. Bear in mind; not all processes can — or should — be automated. Some process requires change management which helps with mitigating the risk of oversight. One can strike a balance between DevOps and Change Management, and both can co-exist; having a human to review, analyze, and approve changes to minimize risk as much as possible. Not all changes have the same impact; thus, there is the need to have DevOps and Change Management to co-exist. This approach is not only applicable to big organizations; even startups can benefit from it.

**Figure 6: Implementing Controls in Orchestration with DevOps**

DevOps team structures (tribes and squads)

A thriving DevOps culture is about transparency, communication, monitoring, and continuous feedback to improve the process. Where developers, IT operations, and quality assurance are encouraged to work as one mutual product or project-oriented team to pull together their aggregate skills to eliminate hand-offs. It is in their interest to provide end-to-end value to the customer by organizing themselves in highly specialized functions, with the help of the line-of-business (LOB) as an integral part of the team. For any company to be successful in its endeavor, seamless collaboration between development, testing, and IT operations is a must.

Each team member of the squad has a role, a mission, and a set of tools to perform their activities.

Line of business lead
- How do I drive my department forward with better performance and reliability of my services to meet my clients’ demands?
- KPI, SLA, SLI (service level indicators), OPI (operational performance indicators)
Cloud development lead
- How do I build an application in a maintainable and efficient way?
- BFF, microservices, NOSQL database, containers
Enterprise security lead
- How do I secure this application against unauthorized users?
- WAF, CDN, SSO, enterprise user directory
System reliability lead
- How do I ensure that the application is performing reliably at an enterprise-scale?
- Monitoring, log, event correlation, runbook automation)
Quality assurance lead
- How do I ensure that the quality meets the demand and provide corrective actions when required?
- (Automated documentation, testing framework, test automation tool, software test automation)

DevOps strategies

The Cloud paradigm has led to quicker and more agile frameworks for managing software. This new discipline has brought significant benefits by automating redundant tasks, removing repetitive cumbersome manual tasks, and reducing human error. This new paradigm has helped to bring it all together:

Understand your own requirements
Define your DevOps process
Find individuals that have both Dev and Ops skills and make liaisons
All production environments mirrored by identical development environments
Dev and Ops staff all have scheduled “office hours”
Focus on automated testing of all infrastructure and software components.
No app launches without automated testing in place at both the infrastructure and app level.
Automated monitoring or platform monitors infrastructure and software layers 24/7, and pages Dev and Ops 24/7.
Both Dev and Ops have 24/7 accountability for the performance and availability of the environment.
Regular code reviews are required, and Ops is involved with code reviews.
Do not automate what you don’t understand.

Adopting the DevOps approach

DevOps is a game-changer; it helps resolve complex business issues while providing organizations higher velocity and ability to change rapidly. Its impact on business continuity helps deliver better and faster business outcomes.

DevOps is the combination of people, processes, and tools that enable continuous delivery of value to end-users. Part of the cultural transformation is to embrace the different needs of the teams by recognizing that each team has different priorities and objectives. We should consider the perspectives and needs of other groups. The emphasis should be on people and processes less about tools.

How Design Thinking helps DevOps problem-solving

Design Thinking applied to DevOps problem-solving can help gain that understanding the same way application developers do. By creating user personas, mapping journeys to identify pain points and delighters, and running rapid test-and-learn cycles. In the same way, traditional Design Thinking runs by capturing:
- Empathy maps
- As-is scenario maps
- Design ideation and prioritizing
- Define
- Ideate
- Prototype
- Test
- MVP build
all to help define and implement an automated DevOps pipeline. Empowering teams to move faster and deliver differentiated outcomes over and over again, as a result of Design Thinking and DevOps coming together to understand and deliver continuously.

Conclusion

A successful DevOps journey starts with culture; no amount of tools, methodologies, and processes will get you there. DevOps requires strategic support, and the organization must be fully on board with the endeavour. Anything else is noise. In my experience, the major challenge facing enterprises is its culture. Culture transcends everything!

A DevOps process must consider customer experience (CX) in mind. Failure to do this, the adoption will not have a lasting effect on the culture.

In the next post, I will deal with the problems developers face while writing, testing, and delivering software to end-users and how they solve it using CI/CD pipeline. The success of DevOps comes from the fact that business and IT are aligned as one working hand in hand with continuous conversation to achieve a common goal, a raison d’être.

Attribution

Special thank you to Amy Xin from Marketing and Communications IBM Garage for reviewing the early draft before publishing.

Thank you to the IBM Cloud and Cognitive Software team in Korea: Yong Sung Lim, Sales & Services Executive; Sul Hwa Lee, IT Architect; Kisoong Jang, Software Engineer; Hae Kyung Lee, IT Architect and Hyuk Seoung Choi, IT Architect.

References

For more details on DevOps and CI/CD, please refer to the links below where you can find many read up for developers, IT operations, and quality assurance team-centric approach:

Bring your plan to the IBM Garage.
Are you ready to learn more about working with the IBM Garage? We’re here to help. Contact us today to schedule time to speak with a Garage expert about your next big idea. Learn about our IBM Garage Method, the design, development and startup communities we work in, and the deep expertise and capabilities we bring to the table.

Schedule a no-charge visit with the IBM Garage.