Defining Disciplined DevOps

 

This posting, the first in a series, overviews a disciplined approach to DevOps.  It begins by defining DevOps, no small task given the continued debate within the DevOps community, and then described a disciplined approach to DevOps.

Defining DevOps

For our purposes we propose the following definition:

DevOps is the streamlining of the activities surrounding IT solution development (dev) and IT operations (ops). 

Figure 1 below summarizes this idea, showing how the development and operations groups within your IT department begin to breakdown the barriers between them that inhibit effective collaboration.  In organizations that have not yet adopted a DevOps mindset we say that there is a “DevOps gap.”  This gap results in lengthy solution deployments and hence higher costs to deploy; a long mean time between deployments (MTBD) which is often measured in terms of months; reduced market competitiveness; and reduced ability to govern your IT efforts due to lack of real-time intelligence.  When organizations close the DevOps gap, by adopting strategies described later in this article, they effectively address these challenges and more.  They do this by adopting a mindset that promotes collaborative, learning-centric ways of working that are supported by agile practices and automation.

Figure 1. Closing the gap between IT software development and IT operations.

Defining Disciplined DevOps

What does it mean to take a disciplined approach to DevOps? It requires discipline to do the things that are good for you that you may not normally choose to do.  Given this, we propose the following definition:

Disciplined DevOps is the streamlining of IT solution development and IT operations activities, and supporting enterprise-IT activities, to provide more effective outcomes to an organization.

To understand the difference, let’s work through the scope implications of what DevOps could mean to your organization.  Figure 2 depicts an initial strategy for scoping your DevOps efforts, basically rethinking the interactions between your Development teams and your IT Operations team.  Notice how in Figure 2 we’ve started to use the term “IT Operations” and not just Operations.  This is because many organizations choose to distinguish between their IT operations activities and their business operations activities (such as selling, distribution, marketing, and so on).  Of course IT operations exists to support business operations.

Figure 2. An initial view of DevOps.

Some organizations will start with the strategy of Figure 3, particularly when there is a separate group responsible for managing the release/deployment of systems into production.  These Release Management teams are often, but not always, a subgroup of your IT Operations team.   Product companies that are creating solutions for the marketplace will typically have a separate Release Management team because the release effort includes both IT release activities, in particular releasing updated solutions into production, as well as customer-facing release activities (such as marketing, sales, and so on).  A disciplined DevOps strategy streamlines both the IT and the business aspects of your Release Management activities.

Figure 3. DevOps with an explicit Release Management activity.

Although Figure 3 is clearly a step in the right direction, it isn’t complete.  A Disciplined DevOps strategy will streamline the supporting activities performed by your Enterprise Architecture and Data Management teams.  Enterprise architecture activities that support DevOps includes the definition, support, and evolution of technical and business roadmaps which guide the efforts of the rest of the organization.  This in turn supports the creation of a common and consistent technical infrastructure within your production environments, enabling common DevOps practices such as continuous deployment, automated end-to-end regression testing, and operational monitoring.  Supporting data management activities include the definition, support, and evolution of data and information standards and guidelines; the creation, support, evolution, and operation of data sources of record within your organization; and the creation, support, evolution, and operation of  data warehouse (DW)/business intelligence (BI) solutions.  All of these activities will be described in greater detail later in future blog postings.

Figure 4. Disciplined DevOps – An enterprise view.

All three views are valid, your organization needs to decide which one is most appropriate for them given their current situation.  Figures 2 through 4 have been presented from the point of view of a potential DevOps maturity model – you could start with the initial strategy presented in Figure 2, then improve it to address release management (Figure 3) and finally evolve your strategy to address other IT activities such as enterprise architecture and data management (Figure 4).

In following blog postings we will show how DevOps strategies are explicitly addressed by the Disciplined Agile (DA) toolkit, thereby taking some of the mystery about how DevOps works in practice.