The value of DevOps is most often considered from the supply-side view of Dev. But Demand is what makes DevOps important, and Ops is central to the demand-side view.

1. DevOps: Fast, Cheap and Pretty
DevOps is a primary and strategic concern of engineers that increasingly announces itself through
automated frequent deployments to accelerate “delivery” to the business. But from a demand point of
view, both the explanation and the expectation is said differently. DevOps generates most of its value by
committing Producers to Providers in the business view of fulfillment.
We know the script. The business needs something new, fast.
The difference means change, the change means availability of something, the speed means no waiting,
and no waiting means risk.
Then, as a further expectation, we throw in the increasing likelihood that the business needs yet another
difference to be made somewhere, pretty soon.
So, we look for the way to have "better delivery" through high agility (speedy response to variety) at low
risk.
But let's reset.
The only real point of being speedy is to wind up being On Time.
Knowing the answer to "on time for what?" is the origin of the demand for deployment of anything
different, especially anything new.
And the excitement about DevOps transformation is not fundamentally about getting Business
Capability to be on time, nor about Operations being on time, because frankly, both operations and
business CAN be ready on time through buying.
Instead, putting DevOps in Demand perspective is about producing on time, at levels of quality and
economy needed by Providers -- regardless of what party is the responsible party in the role of Provider.
Despite the pressure of directly addressing user-demand, DevOps is not primarily a mode of "delivery";
primarily it is a Provider-centric mode of production.
Why is this difference important? Mainly, because Operations (Providers) and Users (Consumers) are
still defined, necessary, and evolving as independent roles and actors.
From the Demand perspective, Operations is neither being absorbed nor disintermediated, and many
Consumer requirements have no necessary dependency on DevOps at all.
Instead, Providers are the client of Producers, and that Provider-Producer relationship is where DevOps
is most necessary.

2. Page | 2
READINESS ON TIME
DevOps is often cited as a way to lower the risks of speed in change. But understanding the pressure of
Demand is about timing, not simply about less waiting.
In DevOps speak, continuous deployment is the mantra for coping with demand. But it is more about
managing the coping than it is about managing the demand.
Meanwhile, understanding the real significance of "continuous" is not simply about coping with the
frequency of change. Let's clarify assumptions about "Continuity" to avoid confusing the issue. The
consumer (end User) wants something different in order to "continue" to "make progress" of some kind.
But outside of being the consumer, having responsibility for that intention is only in a Support role.
To explain support, let's look at the distinction between Continuous and Continual, from the viewpoint
of Demand requirements. And to avoid getting bogged down in theory or jargon, let's stipulate the
following common-sense fact.
A consumer wants to engage an available product to take advantage of its suitability. We are safe in
assuming that:
 continuous suitability is about assuring uninterrupted supply, regardless of need;
 whereas, continual availability is about assuring uninterrupted provision, regardless of timing.
Why bother to make the distinction? The important difference is that the purpose of development is to
produce suitable supply. The suitability necessarily includes timing and supportability. But Providers are
not necessarily compelled to invoke development; they can instead buy. In fact, much of the heartburn
in a company's IT management today is, arguably, from the immature presence of "BuyOps", not from
the lack of DevOps.
DevOps promotes suitability in production, creating a usable supply. Based on suitability, DevOps can
significantly affect the business's decision to make a given producer its chosen supplier. Provision takes
place to establish the connection of the supply to the consumer.
READINESS ON DEMAND
When we shop for groceries we order an activity: retrieval from stock. Yes, if the store is not
immediately ready, there's back-stock, and there's back-ordering. But there's also just going to another
store.

3. Page | 3
When we are eating at a restaurant, we order cooking. But if we go to a “fast food” place, the difference
is not necessarily faster cooking; the difference is that our intended initial point of contact is with
ready-to-eat food.
It's easy to think of other examples that distinguish the User's intended point of contact. In the I.T.
arena, the distinction points out that for an IT User, "deployment" intends to mean "ready-to-use", but
readiness actually means "suitable for what I want to do right now"... Readiness always trumps
availability.
When IT Users want something different from what they already have, addressing the change typically
goes a certain way: for the change, IT Users do not by default rely on developers (producers). By default
they rely on Providers, to assure readiness.
OPERATIONS IS THE PROVIDER
What are the provider's responsibilities for change? For example, is the Provider the Responsible Party
for modification, recovery, refresh, and regulation -- which are all factors directly linked to "change" and
the prospects of successful change?
The IT User (consumer) "funnels" success criteria against change events through the presumption that
the Provider is the correct provider to use. A lot of today's talk justifying DevOps focuses on reducing the
concern that the Provider may be replaced; but the biggest risk to the Provider all along is to be saddled
uncooperatively with responsibilities that belong elsewhere, namely with the Producer (Dev) or with the
Consumer (Business).
Because role-blurring is prevalent, Providers even need to attend to the vocabulary used to set
expectations and agreements. The necessity is about avoiding confusion between what developers and
users must do versus what providers must do - especially under pressure of fast response.
Is the Provider responsible for:
 rapid "development"? No. Rapid delivery? Yes. But rapid maintenance?
 rapid "deployment"? No. Rapid implementation? Yes. But rapid adoption?
 rapid "productivity"? No. Rapid recovery? Yes. But rapid adaptation?
In fact, there are likely two things the Provider cannot be responsible for except by the discretion of
explicit agreement with the Consumer: Optimization and ROI.
Since the consumer nearly always initially wants both optimization and ROI, the relationship of the
consumer to the provider is clearly one that, as a default, requires management. In that managed
relationship, the means and opportunity for satisfaction are intentionally exposed and considered.

4. Page | 4
Operations is responsible for the relationship with the consumer; Operations is the provider.
SUITABILITY
"Delivery" simply means moving something from point-of-residence A to point-of-residence B.
"Deployment" refers to something being introduced into the routine of active use.
Let's assume that the thing is a product. As managers we presume that there is a value system in place
that explains why the thing being introduced is allowable.
In that system, a chain of responsibilities shows that multiple roles have been involved in learning,
accepting and conducting prerequisites to ultimately create the critical point of contact between the
availability of the product and the active use of the product.
Nearly the entire chain of responsibilities manages not risk TO quality but instead risk OF misuse.
For example: a new medicine normally comes with an aggressive awareness campaign exhibiting
prohibitions and side-effects. The message about the product is that:
 if it is relevant,
 then if it is prescribed,
 then if it is consumed as directed,
 there will be "results" in a predicted timeframe,
 and the results are likely to be among the expected effects yet still may not necessarily be
exclusively the intended effects .
There is, in other words, a zone of tolerance that completely surrounds the logic of engaging the
product. The product is engaged to obtain a desired benefit of change, but the product is not expected
to work "correctly" if it is not both systematically and systemically supported.
Working incorrectly is a big risk to the consumer. To minimize the risk, it is necessary to understand if:
 the product is compatible,
 the utilization is permitted,
 and the affected states are resilient.

5. Page | 5
The proper effect of a change is expected to be obtainable as an outcome of factors including
tolerances in the form of compatibility, permission and resiliency. These factors are going to be
requirements transmitted from the Provider to the Producer.
But who is held "responsible for" the Proper Effect of a change? Proper effect is normally based on the
co-operation of the change User with the change Provider.
MODIFYING THE SYSTEM
What Users want is a path of progress, on demand. Changes are important in terms of how the change
affects the path.
For example, let's take "Traffic" (not coincidentally an on-demand path of progress) as an analogy.
In this example, busy intersections in a growing town have gone through various changes over time.
 A new traffic law allowed making right turns on red, onto a two way street.
 An even newer one allowed left turns on red, from a one way street onto another one way
street.
 A further newer one allowed pedestrians the right of way in all directions at an intersection.
Clearly, "Traffic" is changing as a result of these "new" rules being implemented. Each of those changes
allows and encourages newly different behaviors of the users of Traffic.
For the drivers, new rules are the "new products" that are the "deployed changes". The supportability of
the new rules is an intrinsic part of the concept and design of the rules. We recognize that the rules (the
changes) are defined (formed) specifically to enable (not cause) behaviors that are intended to be
beneficial. We don't request, get or use rules that encourage unmanageable behaviors.
Through behaviors, the new rules PERMIT the inherent dynamics of the traffic system to generate new
effects that are intended to be productive.
But if the newer rules are not usable by drivers, they are meaningless to the pursuit of benefits.
Between the rule-makers (producers) and the rule-users (consumers), the role of a "Provider" addresses
how the rules become known, invoked, and supported for usability.
In the example of traffic, that "provision" includes the many things that mark, direct, and enforce the
organization of the environment (including other users) to promote the application of the rules (i.e., the
accessibility of the product). That might even be called infrastructure. It also includes attention to
unintended side effects, which are to some extent expected to occur. Traffic operations are conducted
by one or more parties with those responsibilities, intending to make traffic systematic.

6. Page | 6
However, the new behaviors that are allowed and enabled by the rules will not be beneficial, on
balance, if the change users go "rogue" – that is, if the Users do not commit the new behaviors with the
dual purpose of being productive while maintaining the same benefit of usage for others. Users share
responsibility with traffic operations. That is, the "Customer" co-operates with the Provider.
Meanwhile, in the traffic example, drivers (the Users) expect the rules to become "realized" due to a
party (the Provider) that puts them "into effect", not the party that invents and defines them (the
Producer).
PROVIDING READINESS ON DEMAND
The benefit of change comes from actual engagement with the deployment of something that is
different.
In the traffic example, "Realizing" the rules happens when the Provider's management efforts support
their engagement by Users.
Overall, the effectiveness of a Provider includes the ability to both anticipate changes (What If) and then
manage them (How To). Together, the responsibilities for What If and How To describe a distinguishing
scope for the Provider role, versus other roles.
The anticipation and management together focus on the readiness for use that a deployed product
should acquire.
As a working definition of responsibility for "readiness", the scope covered by anticipation, planning and
implementation gives the Provider the critical position for connecting (a.) the independent capabilities
of a producer with (b.) the customer's own expressed requirements for something that is different from
the status quo.
Under pressure of frequent demand for change, the key challenge of readiness comes from timing. The
provider must deal with whatever mechanisms will establish a punctual engagement of the User and the
Product with the proper effects.
The Provider typically first goes to a reliable existing deployment to minimize challenges to readiness. If
a reliable deployment does not already exist, then the Provider must call for more production (changes)
to address the User's demand.
ENABLING READINESS
Benefits are easier to prevent than to generate. A presumption of benefits of proposed changes must
come logically from a framework of references that includes priorities, standards and constraints. (For

7. Page | 7
example, in the changes to rules of the road above, safe productivity of traffic is the relevant framework
of ideas.) Those factors, which can represent the beginning status quo, need to enable benefits, not
inhibit them.
Without the framework, changes are hard to justify, hard to tolerate, and hard to enforce. With the
framework, ease is more likely than difficulty -- which heads towards assurance.
In effect, that framework is the architecture of the production system for change. Within the
architecture, additional newer product can at all times be anticipated, planned and implemented. Some
speed is obtained from not needing to consider things that fall outside of the framework; additional
speed can come from being able to reuse decisions that proved to be successful before; and more speed
can come from having expectations already shared between producers and providers. With the support
of architectural compliance, the Provider can also attend to setting expectations confidently with Users.
In order to be entitled to expectations of fulfillment by Providers or by Producers, Users are responsible
for expressing the scope and scale of their needs. The needs will provoke requests for offers that will
change users' status quo when providers fulfill user requests based on deployments from producers.
FULFILLMENT
Change is a fulfillment option. The Demand perspective on a successful change is fairly simple. Its idea
of a success is based on two dimensions of fulfilling requirements.
 This was a good design.
 This was a good delivery.
Those two fulfillment characteristics apply to any "successful" change regardless of its scope and scale,
because they are fundamental to readiness.
Consequently it is necessary to be able to specify how something is a good design and how something is
a good delivery.
The way that good design and good delivery are predictably obtained is through planning based on
expected readiness.
Readiness includes supported purpose.
The User relies on the Provider's having assurance about the supportability of the change. Without
supportability, the introduction of a change is inconsistent with the presumption that the change is
going to be beneficial. Setting expectations relies on communication and prioritization. Accordingly, the
Provider has the responsibility for transmitting supportability requirements, which will invoke an
appropriate production source and platform as necessary.

8. Page | 8
Prioritizing readiness also sets the logical target for the use of time in production. The use of time to
reach deployment predisposes the contact point for the product's consequent engagement.
For the Provider, engagement readiness is predicated on the product's immediacy of availability and
appropriate use once deployed. That consequence is the condition that defines fulfillment.
In the demand perspective, targeted deployments that are late, unavailable, or inappropriate are
fulfillment deficits. To proactively defend against fulfillment deficits, prioritizing readiness is also a key
shared touchpoint of the Provider and Producer processes.
Demand tracking creates a projection of readiness requirements. The Provider does demand tracking.
PRODUCTION FOR FULFILLMENT
The chosen producer cannot continuously supply against requested changes unless the economics and
compliance of meeting requirements is sustainable.
For the Producer:
 Readiness of the Change is accompanied by resource management under the intention of having
scope be economical.
 Economy of Scope pre-determines types and scales of progressive changes.
 Scope includes the permitted intended effects enabled by types.
 Producing the types consumes resources.
 The resource consumption level must be balanced with the level of compliance to the
permitted scope of usage.
In a producer's camp, the combination of architecture and automation likely predetermines the level of
capability for continuous supply.
Architecture underpins the timing and supportability of the deployment's availability and usability by
setting prerequisites in place as enablers.
Automation optimizes the relationship between resource consumption and compliance to scope.
Automation acts on labor, monitoring, and decisioning to find, sustain and renew their balance as
necessary. In setting how that gets done, automation also relies on architecture.
Producers are responsible for a managed relationship between Architecture, Development and Change.
That relationship allows Producers to favorably collaborate with Providers. From the Provider's point of
view, that management can be a deal-maker or deal-breaker in the selection of a Producer.

9. Page | 9
DEMAND-BASED PRODUCTION
Many critical enablement scenarios for business do not require the business to make production
decisions but instead to make provision decisions.
But in the business scenario where differentiation through production is a necessity, DevOps responds
to the Provider's need to involve a selected Producer in the determination, prioritization and assurance
of fulfillment per the requirements for change-on-demand.
From the Demand point of view, DevOps is an approach to production in which, knowing that the
Provider can go elsewhere, the Producer treats the Provider as a customer.
©2015 Malcolm Ryder / Archestra Research