We hear this often: What is DevOps? It’s a culture of trust and collaboration in which professionals use the right tools to achieve continuous delivery of business value.
Below we take a closer look at the problems that exist today in delivering business value and how DevOps provides a solution.
Agile Promise, Agile Failings
Agile development promised better collaboration and faster feedback. The focus was on the work and people doing the work over the tools. This has led to rapid software feature creation.
But where it has failed is in rapid feature delivery and operations. Agile was only designed to consider the business and developers working closely together to manage expectations and constantly respond to changing business priorities. In this endeavor, agile works wonderfully.
Delivering features requires a release to production. The problem gets worse when you have multiple agile teams working on a single code base. Many enterprise agile programs still struggle to release more than quarterly.
In essence, Agile is a very good development methodology, but it is not a release and maintenance methodology. So, IT challenges continue to exist…
Teams today experience a wide variety of challenges, each unique to their role. Combined, these challenges create traffic jams or slowdowns in the process of delivering features to support the business, as depicted below:
- I’m waiting on an environment or build 70% of the time.
- I need fungible environments.
- I don’t have any more capacity.
- Why didn’t they tell me they needed to scale?
- Our test systems do not match production nor are realistic.
- We don’t know what codebase we’re testing.
- I don’t know who to escalate to.
- I’m constantly fighting fires.
- Am I hot patching the right code?
- What is IT doing wrong?
- Where is my app?
The Impact of IT Challenges on Your Organization
How will IT challenges of today affect your enterprise?
#1 – Teams can’t deliver fast enough for the business
It’s been estimated that more than 80 percent of IT teams can’t deliver fast enough to meet rapidly changing business needs, which fuels friction between business and IT. Many business units have created shadow IT organizations to address this very issue.
#2 – Release and deployment issues are plagued by human error
Being that we’re all human, we are prone to errors, especially on highly repetitive tasks such as software releases. Often those errors are attributable to configuration issues, process flow missteps, and a general lack of attention to detail. Here’s an example: In 2012, Knight Capital Group released new software to seven of eight servers, according to a 2014 report by Doug Seven. The failure to fully deploy resulted in a market loss of $365 million in cash and equivalents causing them to go bankrupt.
#3 – Legacy systems and organizational structures aren’t adaptable to rapid change
Often legacy systems are monolithic in nature. They require an all-hands on-deck approach to fight deployment fires that may arise. This is because, as monoliths, the deployment needs to include the main systems as well as updates to most ancillary systems. Additionally, these systems tend to be difficult, if not impossible, to effectively roll back should something go wrong.
#4 – Digital and mobile systems require extremely short feedback cycles
Mobile phone sales are expected to eclipse 2.1 billion units in 2019, according to a 2015 Garner report. Coupled with wearable devices, Internet of Things, IT departments are facing an onslaught of requests for mobile and digital features. As the device landscapes continues to rapidly change, business are faced with rapidly releasing features or seeing faster competitors eat away at their market share.
#5 – Objectives by Developer and Operations teams are in conflict
Developers are incentivized and driven to release changes in form of new features, fixes, and other enhancements. Meanwhile, Operations groups are incentivized, and drive to ensure production stability and reliability – which typically means minimizing change. Hence, these two groups are often in conflict with one pushing changes more rapidly with agile, and the other wanting time to ensure stability and gating process to ensure control.
Birth of DevOps
In 2007, Patrick Debois was staffed in a Quality Assurance role on a project tasked with moving a data center. His role forced him to frequently move between the siloed worlds of development and operations. Some days he was working with teams testing newly developed features, other days he was working with operations to triage and troubleshoot incidents.
At an Agile conference in 2008, Patrick met Andrew Shafer. Together, they realized there must be a better way for these two worlds to operate. This would become the birth of DevOps, an amalgamation of Development and Operations.
What is DevOps?
DevOps is not a new technology or software. It is a cultural approach that breaks down development and operations silos by extending agile collaboration practices from product ideation through release and maintenance.
In a typical business environment:
- Operations teams focus on environments, server stats, capacity management, and scaling. Operations is focused on ensuring things keep running.
- Developers are all about constant feature development, consequently application changes. As a result, there are often opposing views on goals and priorities.
Development professionals need to learn to accept input from operations, and operational roles need to accept frequent releases from development.
DevOps works to break down these silos and harness the teams to work together.
But that requires a profound culture shift, wherein developers, IT operations, and QA staff communicate and collaborate to better understand each other. These groups must work together and embrace change in order for a DevOps initiative to be successful.
How Does DevOps Work?
DevOps embraces the principles of CALMS (Culture, Automation, Lean, Measurement, Sharing) that promote communication, collaboration, and cultural change. CALMS is a conceptual framework for DevOps and interfacing groups at an organization. These are DevOps guiding principles:
- Culture is the values and belief systems within an organization. DevOps embraces a culture that supports collaboration, cooperation, and team problem solving.
- Automation refers to removing people from the process of doing mundane, highly repeatable work. This takes place during the development to deployment process. Anything that can be automated to improve consistency and productivity, should be.
- Lean follows basic lean principles of reducing waste, minimizing hand-offs, and maximizing flow.
- Measurement refers to data collection efforts with a focus on improving processes and transparency.
- Sharing is a necessary component of collaboration and cooperation. This is true from a work perspective, but also from idea and innovation perspective.
Applying those principles across the entire delivery process allows DevOps to result in:
Improved deployment frequency
Better release quality
Faster realization of business value
More productive teams
DevOps at Maturity
Fundamentally, a team never completes a journey to DevOps. That is because DevOps is always about learning and sharing. However, there are some hallmarks of effective DevOps teams. Some key aspects of a mature DevOps team include:
- Team responsibility for development and operations
- Ability to roll back and roll forward
- Implementation of component-based architecture
- Self-healing and self-scaling architecture
- Use of continuous integration, continuous deployment, and continuous testing
- Management and use of IaaS and PaaS
To achieve these goals, many changes need to take place in people, processes, and tools.
Journey of a Thousand Steps
Gerald Weinberg states, “No matter how it looks at first, it’s always a people problem” and that holds true for DevOps.
What is DevOps? It’s not about implementing or buying a new tool, or calling a project a DevOps project, or about building a DevOps silo. It is about changing the way people work together toward a common goal of driving business value. It is possible that your organization will need new tools and processes, but the people-side must be addressed first.
Transforming teams to DevOps will require:
- Breaking down empires and silos
- Implementing new roles and responsibilities
- Reallocating decision making authority
- Adjusting resource models
- Capturing and sharing tribal knowledge
- Re-focusing on business service, not technology
- Building trust
As teams learn to work together to achieve common business goals, inevitably the shift will focus on modifying processes and implementing tools that enable teams to move to an automated solution that covers all of these: product ideation to delivery and monitoring.
Our latest insights
Trending Business and Technology Topics
The Phoenix Project Business Simulation Workshop
With your business and technology teams at odds, you’ll need a cultural shift for DevOps to work. Read a related blog
The Phoenix Project Business Simulation Workshop can help. It’s a learn-by-doing workshop in which teams work on challenging issues within a simulated environment. The goal: To learn how to apply DevOps principles and values.
Each participant will play a role with specific tasks, responsibilities and authority. The facilitator will provide support and instructions and help the team reflect on their experiences and what they have learned. More on the workshop