The VOICE model applied to DevOps

While the VOICE model concerns supplying information, DevOps is about creating systems. The VOICE model therefore supports gathering information about IT systems during the time these systems are created and maintained. Continuous quality assurance and testing are essential to supply vital feedback to all people involved and to promote achieving valuable systems.

The VOICE model applied to DevOps consists of:

VALUE
In today’s world, the main reason for building and maintaining information systems is to create business value to stakeholders. While building and maintaining the information system, the stakeholders need to have information to decide whether they are confident that the business value can actually be attained. The first step is to identify the pursued business value. The value will relate to creating a specific service or supplying a certain product for the stakeholders within or outside the organization. The business value elaboration itself is not described by the VOICE model or in this book, since it is part of IT development activities beyond the scope of this book. The defined business value however is the starting point for quality assurance and testing. The value mainly relates to the DevOps activities “monitor” and “plan”.

VALUE

In today’s world, the main reason for building and maintaining information systems is to create business value to stakeholders. While building and maintaining the information system, the stakeholders need to have information to decide whether they are confident that the business value can actually be attained. The first step is to identify the pursued business value. The value will relate to creating a specific service or supplying a certain product for the stakeholders within or outside the organization.
The business value elaboration itself is not described by the VOICE model or in this book, since it is part of IT development activities beyond the scope of this book. The defined business value however is the starting point for quality assurance and testing.
The value mainly relates to the DevOps activities “monitor” and “plan”.

OBJECTIVES
When the pursued value is clear, the next step is to detail the business value into quantifiable objectives. The objectives define several different but coherent aspects that together will make the confidence in the business value measurable. In DevOps, people will use the objectives as guidance about what the IT system must achieve and how it must support the business processes, and which quality measures must be applied. These objectives will amongst others refer to service levels to be met, quality characteristics to be implemented and the software delivery model (Bespoke / COTS / SAAS) used. The objectives mainly relate to the DevOps activities “monitor” and “plan”.

OBJECTIVES

When the pursued value is clear, the next step is to detail the business value into quantifiable objectives. The objectives define several different but coherent aspects that together will make the confidence in the business value measurable. In DevOps, people will use the objectives as guidance about what the IT system must achieve and how it must support the business processes, and which quality measures must be applied. These objectives will amongst others refer to service levels to be met, quality characteristics to be implemented and the software delivery model (Bespoke / COTS / SAAS) used.
The objectives mainly relate to the DevOps activities “monitor” and “plan”.

INDICATORS
To measure whether the objectives are achieved, one or more indicators per objective are defined. These indicators are measured by means of data collection and data analysis, which in the short DevOps cycles can only be done effectively using tools that automate most of the collection, analysis and visualization. Measuring these indicators is what we generally call testing, but other quality measuring activities are also used. Indicators may be caught in very exact measurements, but some indicators will also be based on opinions of people, which just as well contribute to establishing the confidence level. The indicators are defined in the DevOps activity “plan” and measured in all other DevOps activities.

INDICATORS

To measure whether the objectives are achieved, one or more indicators per objective are defined. These indicators are measured by means of data collection and data analysis, which in the short DevOps cycles can only be done effectively using tools that automate most of the collection, analysis and visualization.
Measuring these indicators is what we generally call testing, but other quality measuring activities are also used. Indicators may be caught in very exact measurements, but some indicators will also be based on opinions of people, which just as well contribute to establishing the confidence level.
The indicators are defined in the DevOps activity “plan” and measured in all other DevOps activities.

CONFIDENCE in pursued value
With the results of testing and other quality measuring activities, the team interprets the indicators and reports using a confidence monitor (see Building Block, “Reporting & Alerting“). The stakeholders digest the information, which results in the confidence whether or not the pursued business value is attainable. This conclusion generally supports the decision whether or not (a changed version of) an IT system can go live. Confidence is built by the people involved, such as the product owner, during all DevOps activities, but mainly during “deploy”, “operate” and “monitor”.

CONFIDENCE in pursued value

With the results of testing and other quality measuring activities, the team interprets the indicators and reports using a confidence monitor (see Building Block, “Reporting & Alerting“). The stakeholders digest the information, which results in the confidence whether or not the pursued business value is attainable. This conclusion generally supports the decision whether or not (a changed version of) an IT system can go live.
Confidence is built by the people involved, such as the product owner, during all DevOps activities, but mainly during “deploy”, “operate” and “monitor”.

EXPERIENCE the real value
When an IT system is used to support a business process, the users experience the real value. They will experience this real value based on the outputs and results of the system, but also by monitoring (mostly using tools) the indicators in a live operation of the system. They will compare all the gathered information with their initial expectations as described in the pursued business value. Based on this experience and the comparison, new ideas will arise that are input for changes or new developments. A new cycle of the VOICE model is then triggered. “Experience the real value” mainly relates to the DevOps activity “operate” and “monitor”.

EXPERIENCE the real value

When an IT system is used to support a business process, the users experience the real value. They will experience this real value based on the outputs and results of the system, but also by monitoring (mostly using tools) the indicators in a live operation of the system. They will compare all the gathered information with their initial expectations as described in the pursued business value. Based on this experience and the comparison, new ideas will arise that are input for changes or new developments. A new cycle of the VOICE model is then triggered.
“Experience the real value” mainly relates to the DevOps activity “operate” and “monitor”.