We’re continuing Michael Hüttermann’s guest blog series on DevOps and its ability to streamline software development and delivery. Part Three dives into the “DevOps Matrix”.
The DevOps Matrix
DevOps brings together concepts from Agile, Lean, Theory of Constraints, Kanban, good practices e.g. from ITIL, and just common sense. DevOps is not about *what* to do, it’s about the *how*. Sooner or later you’d probably like to catalogue and rollout DevOps. The DevOps matrix comes in handy with that distinguishing among four different areas. Figure 2shows the DevOps area matrix approach, which is based on and extends Patrick Debois’ approach.
Area 1 is about extending development to operations. A common use case for this is use Kanban to organize and track tasks, to put Chef cookbooks into the version control system (“Infrastructure as Code”) and use the same provisioning tool for both development and operations. Area 2 is about extending operations to development. Examples include providing visibility for traffic and runtime behavior so also development can access those valuable information, continuously. Area 3 embeds development into operations. Examples include setting up constraints and shared goals for nonfunctional requirements, which may also be part of service-level agreements. Examples of shared goals are that 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); or automated tests must exist for all components including infrastructure code (a shared maintainability goal). Area 4 embeds operations into development. This can be done to enhance collaboration by providing access to information to development without the involvement of administrators, thus preventing system experts managing the operational environment from being gatekeepers.
To foster knowledge exchange and fast feedback, each area emphasizes interactions in both directions (i.e., from development to operations and vice versa). In practice, areas overlap. Distinguishing areas can help to introduce DevOps into organizations and projects and shape a shared understanding. All four areas cover the three basic views, metrics and measurement view, the process view, and the technical view.
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). Both the projects and activities of the operations team should be aligned with each other. Business objectives serve as good shared goals such as customer satisfaction and market image. DevOps often comes along with misunderstandings. Some of them we’ll explore in the next post.