When you jump off the hype curve, DevOps is neither "about" engineering nor "about" operations. At least not the way you think. And it doesn't fight with ITIL, either. What it's really about is...

1. DevOps and
the I.T. Consumer
An Archestra Notebook

2. The rush to DevOps Glory would not be nearly as interesting if 9 out of 10
companies were not already intent on doing it. There are even entire vendor
organizations that have repositioned in the market to be DevOps vendors.
This is further interesting, however, because not more than 3 out of 10
companies agree on what DevOps is.
To be fair, there is a lot of overlap of their ideas, which should be expected
because everyone is looking for a practical consensus on how to recognize it
when they see it. This effort is neither more nor less easy than similar previous
efforts to deal with such things as “innovation”, “agile”, and “configuration
items”. There will be lingering concerns about what is, at minimum, necessary to
“actually have it” or to “do it right”...
The agreement may resolve itself, mainly by avoiding brute-force insistence on
specific tools, procedures, or metrics – all of which are simply “means”.

3. While we’re waiting for the calm to set in, the surprising and useful realization
should be that DevOps is neither “about” generic Development nor generic
“Ops”.
Instead, it is about objectives to be addressed by both where neither can address
them successfully alone.
The single most important objective has to do with solving the problem of things
not working correctly under high stress of demand, diversity, or change.
In other words, the objective is Supportability, and the problem is how to
maximize it.

4. Problem Type Definition DESIGN PRODUCTION PROVISION USAGE
DEFECTS Includes damaged
or incorrect parts
Resources Building Configuring Packaging
OMISSIONS Excludes
necessary parts
Requirements Modeling Versioning Access
ERRORS Performs
incorrect function
for circumstance
Logic Method Process Operation
If defects, omissions and errors were not possible or not present, there would be no need for Support. Meanwhile,
the gap between “properly designed for the use” and “properly used as designed” is predictably why most support
issues originate. Support requires recognizing how and where the gap materializes, so that it can be eliminated at
least in the heat of the moment -- but more importantly in advance, by preventing it. Prevention techniques range
widely, including knowledge, detection, user interfaces, policies and more, as employed by responsible parties.
PROBLEM
CONSEQUENCES
Detrimental
effects and
outcomes
Insufficient fit to
the demand for
the purpose
Low-to-No
effectiveness
Inherent
probability of the
risk of failure
Costly need for
abandonment
Systemic
probability of the
risk of failure
Cost of recovery
or replacement
Unanticipated
inadequacy
Lost opportunity
and/or danger
©2015MalcolmRyder/ArchestraResearch

5. PREFERRED
EXPECTED
ACTUAL
Priorities
Competency
Rules
Responsibilities versus Choice: Across the full
lifecycle of a service, each and every stage can
experience tensions and variability between what
is preferred, expected, and actual.
The selection, generation, acquisition, provision
and utilization of a service are all now evolving;
technology allows consumerization, BYOD, and
alternative IT portfolios to concentrate a far
greater percentage of operational focus on the
user’s management of the service lifecycle.
Managing the users’ management becomes a key
issue to business stakeholders in organizational
performance. In the overall organization,
functional responsibilities and instruments for
implementing rules, competency and priorities
may be organizationally distributed but not
allowed to be logically misplaced. These measures
create the effective supportability of the service.
Selection Generation Acquisition Provision Utilization
Social Xaas Consumerized BYOD Self-service
©2015 Malcolm Ryder / Archestra Research

6. Responsibilities: End User
(service utilization)
Provider
(service level)
Supplier
(service class)
Rules Compliance Monitoring Warranty
Competency Skill Continuity Functionality
Priorities Security Availability Capacity
Supportability
method:
Consumerized
Self-enablement
Catalog
management
DevOps
“Service” is itself a type of product, which has managed support. Users,
providers and suppliers have different responsibilities, and have different
methods, for addressing and achieving supportability of the service.
Supportability of a service involves assuring the persistence of three things:
the intended effectiveness at the initial usage, the resilience of the service’s
utility within changing conditions, and the orderliness of its own status
transitions or evolution. The primary value created by this is not
“innovation” or “agility”; rather, it is “robustness” for ongoing consumption.
©2015MalcolmRyder/ArchestraResearch

7. SERVICE DESIGN MODEL
ACCESS TERMS
AVAILABILITY REQUIREMENTS
OPERATIONS PLAN
CONFIGURATION SPECS
ARCHITECTURE ENVIRONMENT CONSTRAINTS
PLATFORM & OPERABILITY CHANNEL & DELIVERABILITY
release
approve procure
ordercontrol
deploy
offerinstall
resourcebuild
USE CASE
SOURCING
DEVELOPMENT
The variables in the design of a service identify types of specifications that define an implementation, logically enabling
recognition and support of the service. The design model is vertically hierarchical (top-down) and laterally directional (left-right).
The platform and the channel are independent of each other but related. A knowledge base of the service design model (SDMK)
associates CMDBs and capabilities with asset repositories and Catalogs. The selection and acquisition of service by individuals or
organizations is flexible according to the specifications that can be supported. Standards may exist for a service type’s
specifications, within narrow or broad tolerances. The providers of support allow the flexibility to be feasible.
DevOps presumes the availability of a Service Design Model to guide collaborative and automated supportability.
©2015MalcolmRyder/ArchestraResearch

8. The most undesirable condition that DevOps is asked to address is the case
where rigidity displaces robustness and frustrates the ability to adapt proficiently
to changing business conditions.
Rigidity can occur in the mechanism that supplies service, in the functional
tolerances of the service, and in the scope of effectiveness of the service.
DevOps is expected to manage through and away from rigidity. The service
design model is both a guide and a diagnostic for determining the level and
location of alternatives that can offer timely adaptation with low risk.
That then amplifies the difference between two kinds of assurance to users: the
value of relying on services for productivity, versus the value that a reliable
service can offer to users. It becomes clear that the primary user perspective on
support is assurance.

9. Users have increasingly shown that they prioritize the ability to rely on services
more highly than they do the reliability of a given service.
This is reflected in their quick migration to other services based on capability
instead of on quality. Subsequently it is reflected in the pressure on a provider to
quickly extend quality into new capabilities.
As a result, the business development of a portfolio of services becomes the
true nature of “Dev” in DevOps while continual alignment of service availability
to current needs is the true nature of “Ops”, most visible in a catalog of services.

10. ©2015 Malcolm Ryder / Archestra Research
mryder@malcolmryder.com