DevOps for Executives: A Primer

Share

Share on linkedin
Share on twitter

Many organizations are adopting DevOps.  If you’ve never worked in a DevOps environment, here are the basics.

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

Melvin E. Conway

How you structure your organization influences how your organization performs and what it produces.  New technologies and business practices allow for novel systems and outcomes, but these are difficult to achieve if your organization isn’t designed with them in mind.

DevOps is a way of organizing and getting work done that creates a high performing organization. It can be applied no matter the technology stack – including in legacy or hybrid IT departments.

This post outlines the six foundational concepts of DevOps to help executives understand where DevOps concepts could help their IT organizations become more productive and reliable.

The Core Concepts of DevOps

DevOps is sometimes described as a set of behaviours or in terms of supporting tools. In truth, both are critical. However, at its core DevOps is a set of practices or concepts than can be drawn from by any IT or product-based company to improve the quality of their outputs.

Core Concept #1: Developers Support What They Develop

DevOps is literally the combination of Development and Operations. Instead of IT having two separate arms – one developing new features and enhancements and the other providing stability and reliability to existing products – DevOps puts responsibility for operating and developing on the same people.

By combining Development and Operations, DevOps aligns the objectives of Development and Operations to incentivize mutually reinforcing activities. The team’s focus is on completing new features and delivering stable services – not one or the other.

Technical debt is less likely to accrue because the DevOps team, which is directly impacted by defects, is incentivized to identify and correct shortcomings immediately as it develops rather than pass them downstream.

With less technical debt, the development team can move more quickly, delivering more business value.

What’s different from Traditional IT?

With Traditional IT, incentives for separate development and operations teams are in conflict. The development team is trying to deliver great functionality or features for the business, and the operations team is trying to keep things running.

Inevitably, developers are pressured to take shortcuts that make it harder to operate the software.  Operations are forced to use workarounds that don’t solve core problems, making it harder to develop efficiently. If not managed carefully, this can lead to increasing technical debt.

Core Concept #2: Development Occurs in Small Cycles

The second core concept of DevOps draws on lessons from lean manufacturing. 

In lean manufacturing, parts arrive at the factory just when they are required instead of in bulk. If there’s a problem with a component, it can be addressed quickly. If a product feature needs adjusting, it can be changed quickly while minimizing waste.

The same concepts apply to software development – especially so because software is a complex system where problems will occur regardless of how well work is planned.

By reducing the size of work batches and providing feedback faster, developers can deliver value sooner. 

What’s different from Traditional IT?

A traditional IT project occurs in large batches. Developers may spend months working on a set of features prior to integration and release.

When developers emerge after months of work, there is a scramble to fix defects and problems so something can be delivered to the client.

To make matters worse, the “something” that is delivered may or may not be what the client expected. After all, requirements rarely capture all the client’s thinking!

Core Concept #3: Testing is Automated Whenever Possible; Manual Testing is Minimized

A factor when reducing batch sizes is to incorporate testing into daily or weekly activities. To limit the overhead associated with increased testing, this should be automated whenever possible.

If testing is done manually by a testing team, the cycle time of frequent testing is high, but this is dramatically reduced by automated testing. In DevOps, tests are run by the DevOps team – not by a separate QA team.

By automating testing, testing can occur more frequently, shortening the feedback loop between testing and identifying and fixing problems.  Automation increases quality by allowing the developer to fix problems early without building on yet to be identified defects.

If defects can be identified at the point of work, code can be improved before moving forward. This prevents a mass effort at release time to find and mitigate defects.

What’s different from Traditional IT?

In traditional IT, defects are found after development. Problems may have been built on top of problems and fixing simple bugs can be like untangling a knot in fishing line.

Core Concept #4: Continuous Deployment Replaces Occasional Releases

In a DevOps environment, code is kept in a deployable state. This means that at any given time, the business could choose to make the code public and it would work.

This concept belies a fundamental shift in how software is created. By keeping code in a deployable state, and by using automated build tools to reduce deployment time, deployment to production is separated from public release.  Release becomes a business decision – not a technical decision

What’s different from Traditional IT?

In traditional IT, all features test and release at the same time.  As a result, the business can’t release a subset of the features in response to a business event (for example, if a competitor has released a similar – but inferior – product). Because the testing and releasing of all features happens at the same time, if one can’t go none can go.

Core Concept #5: Business is Integrated into Key IT Processes

With short work cycles, an iterative approach to design, and with releases separated from deployment, the business must be closely involved with the development process. Business works alongside development to prioritize backlogs, provide ongoing feedback, and make decisions about releases.

By integrating the business into the DevOps teams, IT is much more likely to produce something of business value. There should be a minimal gap between business needs and what is produced because feedback is provided early and often.  The course correction from feedback is what ensures that what is delivered achieves the business outcome.

The requirement to integrate business closely into the development process means that transitioning to DevOps requires commitment from the business as well as IT.

What’s different from Traditional IT?

In traditional IT, the business is consulted early on then towards the end of development. They typically aren’t involved in daily clarification discussions, even if these have implications for the user experience.

When the business isn’t involved on an ongoing basis throughout the development process, it is far less likely that what is produced will satisfy the business. It also increases the risk that technical choices are made that limit the future business capabilities of the software.

Core Concept #6: Tools Automate and Facilitate Many Functions

The last DevOps concept is implied throughout but is worth emphasizing separately. DevOps relies heavily on tools to streamline workflows, automate lengthy manual processes, and improve communication.

Without these tools, adopting DevOps is not possible. At the same time, full implementation of these tools can force many of the cultural changes that are integral to DevOps. For this reason, many practitioners incorrectly focus exclusively on the tools when discussing DevOps.

However, tools alone are not enough. Without leadership buy-in and organizational, process, and culture changes, DevOps will not be adopted.

The full journey to DevOps takes years. But, that’s no reason not to start. If you lead an organization with traditional IT, you can get started with DevOps today.

Many of the core concepts discussed here can be adapted to any IT environment and the adoption of new practices will produce tangible results. Done right, each step in the journey towards DevOps increases IT’s productivity and quality and allows IT to produce greater value for the organization.

Alex Bota

Alex Bota

There are always ways to deliver more measurable value as an organization. Alex loves helping organizations move from "how we've always done it" to "how we should do it."

Read More of Our Posts

Where’s the Fun in Quarantine?

Embracing the new norm and moving your company to virtually held social events can be a great way to maintain staff moral and positive employee relationships during a world pandemic.

Read More »

Floating on Cloud Analytics

Moving your organization’s data analytics solutions to the cloud introduces a wide range of benefits that will ultimately improve your ability to make strategic data-driven decisions. 

Read More »