Right from the outset, the digital age has brought with it a great many new buzz words and
concepts that have an impact on IT. Agile, Scrum, Lean IT and DevOps, to name just four. We are
seeing that followers of the various schools of thought are often in conflict. When we more closely
examine the background of each concept and the objectives they are aimed at realizing, three
common goals can be identified: optimizing the agility of the organization by anticipating change,
reducing the time to market of new features, products and business models, and delivering
the highest possible customer value while focusing on quality at the source.
After reading this white paper, you will be able to place current developments – and the often
heated discussions about the next steps – within the context of your organization, and recognize
their relationship to one another. DevOps is the development that links the Agile world’s need for
flexibility with the need to guarantee continuity in the provision of services. This paper also links
DevOps to a development that has emerged from infrastructure management in order to respond
to developments in that domain as well. Ultimately, these developments reinforce one another and,
after reading this paper, you will know why.
DevOps is a cohesive approach
Let’s first examine the objectives of the various
concepts.
Lean, which came into its own in the automotive
industry (the Toyota Way), aims to optimize the
value stream by removing as many unnecessary
actions and steps as possible. To this end, Lean
offers an extensive toolkit in which the focus is
on leadership, knowledge of the work floor and
continuous improvement.
Agile and Scrum emerged from the world of
software development. Here, the Lean mindset
is translated into responding to changed insights
regarding feasibility and customer value which
are identified by the customer and developers
during the development process and use of
new software. Process improvement and waste
reduction are the next step.
DevOps adds user value during the lifecycle to
the above. By allowing operations to be performed
by the same team that develops the
functionality, a direct feedback loop is created
which enables the team and the customer to
identify priorities from the long-term perspective
and to develop software in such a way as to
minimize the operations burden throughout the
lifecycle of a service.
These differences in origin do not have to be a
restriction; the concepts are complementary and
can be used together effectively. It is, however,
useful to understand the background of each
concept, and how more customer value can
be delivered when they are combined based on
each one’s own specific strength. Application
operations versus application development,
application domain and infrastructure domain:
from the customer perspective there is a growing
need for flexible and reliable IT. It is up to you
to meet the challenge of fulfilling this need. In
this regard, DevOps is a cohesive approach to
four areas: Operations, Development, Applications and Infrastructure. At first glance, DevOps
is simply the combination of Development &
Operations. However, behind this façade there
lies a whole new world of thinking which entails
making optimal use of new technological
opportunities, focusing on team responsibility
and integrating processes within the team. This
paper aims to reveal the secret behind the term
DevOps and thus create more clarity. After all,
DevOps is an organizational earthquake which
can contribute significantly to the added value
delivered to customers and experienced by staff.
This paper illustrates what DevOps delivers from
four different perspectives in 4 DevOps journeys.
What is DevOps?
DevOps is the merging of the responsibilities
for development and operations in order for
them to together guarantee the health of the IT
service for the user organization. Initially aimed
at new software to be developed based on new
programming languages, in practice applying
DevOps to existing systems (including legacy
and ERP systems) has proven equally successful.
However, in this regard, it is essential that
development is guided by testable acceptance
criteria; transparency and improving quality at
the source are vital aspects.
Another factor is that the success of DevOps
is to a large extent determined by the mindset
and actual behavior of staff and management.
It is not a ready-for-use recipe that can simply
be implemented without any problems.
Challenges and problems have to be tackled
creatively and with tenacity to move steadily
closer to realizing the goal of responding more
quickly to the changing needs of customers by
providing high-quality managed solutions. Lean
leadership, which is also used in Agile teams,
also plays a major role in DevOps. Learning from
mistakes with the focus on delivering customer
value is a key success factor.
This brings us to the organization of work across
multidisciplinary teams that have full responsibility
for the ‘health’ of the service involved.
Composing the teams in such a way that the
required competencies are present is an important
factor in maintaining this health. However,
team dynamics is also a major element. An
interesting point in this regard is that a balanced
male-female ratio demonstrably contributes to
the quality of the service and the growth that a
DevOps team undergoes. Get the systems in
one room – diversity within teams is essential
to the continuous delivery of improved results.
DevOps focuses strongly on operations processes
and change processes and the automation
thereof. This involves more than a combination
of operations and development because
there is also a focus placed on quality at the
source and first-time-right as the active ingredient
for operating services without rework, and
for moving services quickly through the DTAP
street (Development - Testing - Acceptance -
Production). This means that quality assurance
therefore constitutes the third element in DevOps.
Continuous integration, automated testing and
automated promotion through the DTAP street
based on predefined acceptance criteria, and
version control of the entire IT stack including the underlying platforms and infrastructure, capitalize
on the earlier mentioned success factors and
reduce the lead times of change, recovery and
incident handling.
The 4 DevOps journeys
In practice, what people think of DevOps is
shown to be highly dependent on the experience
they have with it within their own organization.
In this paper, we use four DevOps journeys to
bring together these different experiences as
pieces of a larger puzzle. Each journey describes
the development of DevOps from a particular
perspective. Each of the four journeys can be
regarded as the archetype of a journey an organization
can make. These journeys serve as
a frame of reference for discussions about the
meaning of organizational changes.
In practice, you have probably noticed that within
the various parts of your organization people are
trying to find a solution to the increasing need
for agile and reliable IT. Each part does so from
its own perspective. However, this is like trying
to convey what an elephant looks like by only
describing its trunk or its tail or foot. Each part of the organization is right, to a certain extent.
The trick is to make combinations of descriptions
which provide a clear picture of an elephant.
By understanding the different perspectives,
you can combine them powerfully because the
underlying goal is a common one.
Journey 1: From waterfall to DevOps
Traditionally, new systems are developed in
projects, in a waterfall process. The project
ultimately delivers the system (after months, or
sometimes years) to the operations organization,
which formally accepts the system. In practice, however, these new systems are ‘thrown over
the wall’ and remaining points and quality issues
have to be resolved in the operations phase.
However, a trend in recent years is to develop
(or further develop) systems in short cycles using
Agile methods like Scrum. Scrum can be very
successful but in reality it turns out that actual
deployment to production is a very high hurdle:
the ‘wall’ referred to earlier is higher and more
solid than had been thought. Operations’ ground
rules are difficult to capture in the Definition of
Done and hard to pass on in advance to the
Scrum teams in the form of requirements or
non-functional requirements.
This DevOps journey starts when the Scrum
team takes responsibility for resolving incidents
and, as result, acquires insight into the functionality
and becomes jointly responsible for making
the functionality available in the production environment.
Taking responsibility for matters ‘on
the other side of the wall’ leads to a different
awareness of quality. The technical debt and
the number of incidents, questions from users
and operational issues will hurt; they impede –
and will continue to impede – the Scrum team
in delivering value quickly. Low quality leads
to a congested backlog. This can also be the
starting point for assigning multiple operations
tasks within the Scrum team; for example, the
team will monitor and optimize (automate) the
performance of systems. In addition, it becomes
important to the team that the technical debt is
contained and reduced. The development team
This DevOps journey starts when the Scrum
team takes responsibility for resolving incidents
and, as result, acquires insight into the functionality
and becomes jointly responsible for making
the functionality available in the production environment.
Taking responsibility for matters ‘on
the other side of the wall’ leads to a different
awareness of quality. The technical debt and
the number of incidents, questions from users
and operational issues will hurt; they impede –
and will continue to impede – the Scrum team
in delivering value quickly. Low quality leads
to a congested backlog. This can also be the
starting point for assigning multiple operations
tasks within the Scrum team; for example, the
team will monitor and optimize (automate) the
performance of systems. In addition, it becomes
important to the team that the technical debt is
contained and reduced. The development team not only becomes responsible for the delivery
of working software but also for the delivery of
the entire service so that a user group can also
use this functionality optimally in its own business
process. This change is the most common
DevOps journey: the journey from development
to operations.
Journey 2: From application
management to DevOps
This journey starts from application management.
In this domain, staff members are mainly
organized in silos according to their expertise.
This means that service delivery managers,
functional application managers, technical application
managers and database managers make
up separate departments or teams. Processes
are focused on channeling the work through the
different teams. To facilitate this, ITIL process managers and ITIL coordinators are added to
the organization as a function.
To begin with, based on shared features (including
customer features) applications are clustered
in product lines, information domains,
value streams, etc. Key in this is to produce
cohesive work packages for identifiable customer
groups. Subsequently, the required operations
competencies are combined in multidisciplinary
operations teams. This second stage starts when
the operations teams not only focus on operating
and provisioning the contracted service, but also
feel increasingly responsible for realizing new
functionality in existing services in operation
and subsequently also actively take on the role
of owner in respect of service innovation. In
turn, within these permanent, mature operations
teams, this leads to increased awareness and
the acquisition of the competencies needed for
the teams themselves to realize innovations.
Development tasks such as designing, building and testing can be performed within one’s own
team. As a consequence, the management reflex
to realize every innovation in projects with ad-hoc
project teams can be overridden. The focus thus
shifts from resource allocation, which is traditionally
one of the time-consuming processes within
an organization, to task prioritization.
Journey 3: From infrastructure
management to DevOps
The third DevOps journey described in this
paper is relatively unknown within the domain
of DevOps, but it is essential to facilitating the
journeys set out above. The starting point of
this journey is the infrastructure management
domain (from running infra via changing infra
to providing self-service infra). Infrastructure as
code and platform as code are terms you will
hear in this regard. Making virtual infrastructure
provisioning available to the DevOps teams
allows them to respond flexibly to their changing
needs for suitable infrastructure. The flipside
is that this flexibility can only be realized if the
underlying platforms and infrastructure have
been standardized and the lifecycle management
of hardware, OS, databases and middleware
has been implemented explicitly. This flexibility
and maintaining the platforms and infrastructure
provided, lie at the heart of infrastructure-based
service provision. Enforced processes (change
and release management, automated promotion
of software through the DTAP street based on test and acceptance criteria) mean that the
DevOps teams demonstrably keep to the rules
within the organization. We often see that on
paper ITIL processes look great but in reality they
are applied insufficiently. In a DevOps world, it is
also desirable that the DevOps teams make sure
they – and other teams – keep to the processes.
Moreover, this is much easier because all the
people in the process are in one room and thus the processes are very short and efficient instead
of being long and burdensome. What is more,
processes are increasingly described in the form
of behavior rules and agreements rather than
in process documents. This also applies to the
processes in the other journeys.
In this way, a giant step is made towards realizing
infrastructure management that is in line with the
need for IT services to be agile and available.
This step towards facilitating change has become
possible in recent years thanks to a wide array of
tools and methods (that are often open source)
which are aimed at automating parts of the development
process and the deployment process.
As a result of the virtualization of infrastructure
– infrastructure as code – the standards from
the development domain (version control, full
scripting of the promotion of software as well
as modifications to infrastructure and platforms)
are applied to compatible standards.
Does this mean that Dev has triumphed over
Ops? No! That is certainly not the case. Although
the commitment to innovation within the
infrastructure domain has been strengthened,
success is equally due to life-cycle thinking in
the operations domain in terms of availability,
continuity and stability. It is this cross-pollination
that has brought Dev and Ops closer together.
Quality at the source enables the divide between
Dev and Ops to be bridged.
Journey 4: The step to Lean IT
That brings us to the fourth DevOps journey. A
next step is taken in this journey. The DevOps
teams seek to respond to the application domain’s
need to reduce time to market. Infrastructure
facilitates these teams optimally with
appropriately modified platform and infrastructure
services. As the quality is demonstrably under
control, the added value of the division between
run and change becomes steadily lower and new
possibilities are created for further expanding the
change domain. After all, the continuity of service
delivery is safeguarded. Through value-stream
optimization (Lean IT) new possibilities are created
for shortening processes. We have called
this journey Lean IT (‘handing over the keys to
the kingdom’) because it optimizes the Lean IT
value stream. What we see is that from a Lean
perspective, the focus is on creating added
value, and non-value activities and necessary
non-value activities are reduced. By automating large parts of the operations processes and
activities, greater transparency is created regarding
the status of operations and updates.
In fact, the effect of the operations standards
increases because these standards are routinely
applied and outage is measured and minimized
(continuous improvement).
A step is thus made away from operational management
in the form of reactive monitoring of
components towards proactive management of
the entire service in the chain. Of course, this had
always been the intention and, in principle, had
always been possible. However, when we look
at how things turn out in practice, it is often not
the case. Through far-reaching standardization
and shortening of operations processes, collecting
monitoring data (big data) and providing
the DevOps teams that are responsible for the
health of the service with access to this data,
proactive management becomes the key to
continuously increasing the tempo of updates
and not drowning in incidents and fire-fighting.
Mature operations teams manage and update
the services on a daily basis. In this situation,
operations (or infrastructure operations) can hand
the DevOps team the key without jeopardizing the
availability of the service. What is more, if this key
is not handed over, the delivery of customer value
will be jeopardized. Today, customers require
services which are in line with their current needs
and not necessarily the contracted services of
several years ago. Change becomes the norm
but these services have to remain available.
This fourth journey thus shows how the application
domain and the infrastructure domain work
together to increase the agility of IT as a whole,
while never compromising the basic need to
safeguard continuity.
The DevOps journeys above provide a frame of
reference for various stakeholders to consult one
another about the goals an organization seeks
to achieve, and how the different parts of the
organization can contribute to achieving them. A
common view and language are vital to this end.
In addition, it is useful if people recognize and
learn from one another’s contributions. Developers
should learn that continuity requirements
and operations tasks have value and can – and
must – be optimized in order to safeguard agility
in the long term as well. At the same time, people
in infrastructure learn to use the development
standards when developing and maintaining
cloud-compliant infrastructures. The common
goal of delivering more value, faster, requires
new steps and working methods from every
perspective. It is essential here to break down
‘walls’ and facilitate flow within the various IT
domains and between the business and IT.
The business can also take
the initiative
There is still one more journey: one that starts
from the business process (BusDevOps). In this
journey, in the development towards DevOps,
IT is regarded as a business support function.
This fifth journey falls outside the scope of this
paper and will be dealt with separately elsewhere.
Conclusion
DevOps is a different way of working and organizing
but, above all, it is a different way of
thinking. It is made for change. DevOps makes
the organization ready for change. It is a concept
that is perfectly aligned with our increasingly
more digitalized world because the different
functions, silos and islands are merged into a
single end-to-end responsibility. DevOps is an
inescapable step towards maximizing the quality
of the customer experience.
Source : Quint Wellington Redwood