DevOps Architecture – Process blue print

Process blue print Introduction

This article describes an architecture model to achieve a balanced design of service management processes in a DevOps based service organization as a Process blue print.

Process blue print Definitions

Architecture model
A simplified representation of reality.

Process blue print Concepts

Process blue print:

A process blue print is an example of an architecture model. The blueprint shows in one picture which service management processes are used in a service organization and how vertical and horizontal governance is organized, without showing all communication lines in detail.

Level of steering	User organisation	Information Management	Application Management	Infrastructure management
Strategic Steering
Tactical Steering
Operational Steering
Innovative Steering

Figure 1, The 16-area model.

Figure 1 shows a 16-area service management model. It is very enlightening for each organization if this model is completed with the DevOps processes. If the processes are not explicitly recognized, it is also possible to complete the 16-area model with deliverables. For the sake of simplicity and clarity, only the deliverables are stated in this article. Furthermore, a DevOps team can of course enclose more than one cell.

The strength of this management model is that it helps you to think about what’s in the domain of DevOps and what’s not. As soon as something is excluded from the DevOps area it is the question where this deliverable is covered.

Process blue print Patterns

This article discusses some characteristic completions for the 16-area service management model. The formulation is indicative and not limitative, so there are many additional supplements possible. The purpose of these examples is to clarify how a choice can be made of how “control” is implemented within a DevOps team. Additionally, it is important to explicitly take distance of specific control aspects by recognizing and accepting the consequences.

Pattern classic service organization:

In a classic service organization, each cell of the management model is generally filled in. Usually, the deliverables of the BiSL and ITIL processes are used. An example entry is shown in Figure 2.

Level of steering	User organisation	Information Management	Application Management	Infrastructure management
Strategic Steering	Mission, vision and strategy Business goals Information planning	Information portfolio Architecture scenarios Information roadmaps	Application portfolio Architecture scenarios Application roadmaps	Infrastructure Portfolio Architecture scenarios Infrastructure roadmaps
Tactical Steering	SLA review	Annual and quarterly information management plans Business case Resource planning Financial planning	Application release planning SLAs Security plan Continuity plan Availability plan Capacity plan Resource plan Contracts	Infrastructure Release planning SLAs Security plan Continuity plan Availability plan Capacity plan Infrastructure planning & design Contracts
Operational Steering	Super user Escalation Calls	Information incidents	Application incidents Incident Resolution Root cause analysis Event management Performance & tuning	Infrastructure incidents Incident Resolution Root cause analysis House keeping Workload Scheduling Monitoring Performance & tuning Environment management
Innovative Steering	RFC	Risk assessment RFC calendar Requirements UAT, FAT	Risk assessment Application code Baseline UT, SIT, PAT	Risk assessment Scripts Baseline UT, SIT, PAT

Figure 2, The 16-area model of a classic service organisation.

Pattern Agile Development team:

Research by ten organizations in the Netherlands [Best 2015] indicates service management processes are still in place in service organizations that use an Agile method. Figure 3 shows which scope the ten organizations assign to the Agile development team. Grey means that there is no involvement but also not really expected. Red means as good as not involved. Yellow means partly involved and green means involved. The figures reflect the number of the ten organizations that implemented an aspect area. Especially the poor attention to information management is worrying. But also the absence at the majority of a strategic framework is striking.

Level of steering	User organisation	Information Management	Application Management	Infrastructure management
Strategic Steering	–	1	3	1
Tactical Steering	–	4	5	1
Operational Steering	–	2	7	–
Innovative Steering	–	5	10	1

Figure 3, The 16-area model of an Agile development team [Best 2015].

Figure 4 shows examples of deliverables that may be expected from these organizations. An important question for these organisations is what has to be realized for the other cells which manage the architecture directives (service strategy) and planning (service design).

Level of steering	User organisation	Information Management	Application Management	Infrastructure management
Strategic Steering	X	X	X	X
Tactical Steering	X	X	Product backlog	X
Operational Steering	X	X	Application incidents	X
Innovative Steering	X	Requirements UAT, FAT	Application code Baseline UT, SIT, PAT	X

Figure 4, Examples of a completed 16-area model of an Agile development team [Best 2015].

Pattern DevOps team:

Next to the patterns of a classic management organization and an Agile development team, it is of course interesting to see what is expected of a DevOps organization. In Figure 5, a possible implementation of an organization is stated that hast just adopted a DevOps method. In this case, it is a business DevOps team because information management is in scope. The completion is based on what is actually done by the DevOps team itself and what is covered by the line organization.

Level of steering	User organisation	Information Management	Application Management	Infrastructure management
Strategic Steering	Mission, vision and strategy Business goals Information planning	Vision statement Information portfolio Architecture scenarios Information roadmaps	Application portfolio Architecture scenarios Application roadmaps	Infrastructure Portfolio Architecture scenarios Infrastructure roadmaps
Tactical Steering	SLA review	Annual and quarterly information management plans Business case Resource plan	Application release planning SLAs Continuity plan Security plan Availability plan Capacity plan Resource plan Contracts Product backlog	Infrastructure Release planning SLAs Continuity plan Security plan Availability plan Capacity plan Infrastructure planning & design Contracts
Operational Steering	Super user Escalation Calls	Information incidents Kanban board	Application incidents Incident Resolution Root cause analysis Kanban board Event management Performance & tuning	Infrastructure incidents Incident Resolution Root cause analysis Kanban board House keeping Workload Scheduling Monitoring Performance & tuning Environment management
Innovative Steering	Product backlog Feature requests	Risk assessment Feature definition Requirement GAT, FAT Scrumboard	Risk assessment Application code Baseline UT, SIT, PAT Scrumboard	Risk assessment Scripts Baseline UT, SIT, PAT Scrumboard

Figure 5, Implementation of 16-area model of a DevOps development team.

In Figure 5, deliverables that are not used are shown in red. In this case, this concerns the deliverables of architecture, planning and control. The green terms relate to aspects that are designed within DevOps. This result is quite common for startup DevOps organizations, partly because a DevOps team often starts developing and managing a website. Therefore, there seems to be less need for direction (architecture) and control (planning). Later in time it often appears that there are interfaces needed with the back office. As soon as these are developed, ad hoc under pressure, situations arise that require more control and directive.

Process blue print FAQ

#	Subject	Question	Answer
1	Coverage	What is the ideally the scope of DevOps	DevOps should ideally include a service lifecycle, both in terms of information, application and infrastructure management. In any case, the operational and innovative layers are subject within the DevOps team are included. For tactical and strategic processes, often a central implementation within several DevOps teams is selected. It is important, however, that this directive (strategy) and planning (tactic) work closely with the DevOps team. One example is security architecture and the SLA standards.
2	Scope infrastructure	Does a DevOps team generally have full control over infrastructure management?	Many organizations divide infrastructure management into a generic layer and plot the DevOps teams above the layer. These DevOps teams can, within certain limits, program the infrastructure on their own (infrastructure as code).

Discuss with us about this article on LinkedIn.

More information

Related Books:

DevOps Best Practices, ISBN: 9789492618078
Agile Service Management with Scrum, ISBN: 9789071501807

Related training sessions:

• DevOps Foundation
• DevOps in practice
• DevOps Master
• Masterclass DevOps Operations
• Masterclass DevOps Application Development
• Masterclass DevOps Architecture

Related Article:

Service Management

Operational Level Agreement