DevOps brings together concepts from Agile and Lean software development methodologies, the Theory of Constraints, Kanban, ITIL, and just plain common sense. DevOps is not about what to do, it's about the how.

The DevOps matrix can be an effective tool when it comes time to catalog and roll out DevOps in your organization. Based on an approach by IT consultant Patrick Debois, the matrix helps clarify and distinguish the four main areas of DevOps practices. All four areas cover the three basic views: metrics and measurement, process, and technical.

Area 1: Extend development to operations

Common use cases for extending development to operations include using Kanban to organize and track tasks, putting Chef cookbooks into the version control system ("infrastructure as code"), and using the same provisioning tool for both development and operations.

Area 2: Extend operations to development

An example of this is providing visibility for traffic and run-time behavior so development can also access the valuable information continuously.

Area 3: Embed development into operations

Embedding development into operations includes setting up constraints and shared goals for nonfunctional requirements, which may also be part of service-level agreements. Examples of shared goals include:

• Services will return results to the screen in less than two seconds (a shared performance goal).
• The system shall not make use of any technology that would make it difficult to port to another Linux distribution (a shared portability goal).
• The database will be capable of storing 20 million members on the specified hardware while still meeting performance objectives (a shared capacity goal).
• Automated tests must exist for all components including infrastructure code (a shared maintainability goal).

Area 4: Embed operations into development

Embedding operations into development can enhance collaboration by providing access to information without the involvement of administrators. This prevents system experts managing the operational environment from acting as gatekeepers.

Each area of the matrix emphasizes interactions in both directions (i.e., from development to operations and vice versa) to foster knowledge exchange and fast feedback. While areas will overlap in practice, distinguishing the different areas can provide a structured way to introduce DevOps into organizations and projects and shape a shared understanding of what DevOps means.

The approach of the DevOps area matrix accounts for the fact that both development and operations often use their own internal processes and micro-optimized solutions. Development is often organized as part of a “project” whose goal is to deliver defined content (the scope) at a defined quality with the available manpower in a given period of time (according to defined milestones).

As development and operations teams adjust to new ways of working together, the DevOps process may raise misunderstandings in the beginning. Both the projects and activities of the operations team should be aligned with each other so business objectives such as customer satisfaction and market image can serve as shared goals to unify DevOps efforts.