D E VO PS

T H E S EC R ET OF AGI LE START-UP S—NOW WIT HIN T HE

REAC H O F LAR GE O R GAN I Z ATI O N S
www.wavestone.com

Wavestone is a consulting firm, created from the merger of Solucom and Kurt Salmon’s European
Business (excluding retails and consumer goods outside of France). The firm is counted amongst the
lead players in European independent consulting.
Wavestone’s mission is to enlighten and guide their clients in their most critical decisions, drawing on
functional, sectoral and technological expertise.

2
 EDITORIAL

DEVOPS: TOWARD END-TO-END AGILE Apple, Facebook, and Amazon) companies.

These web giants have been lucky enough
In an age of digital disruption, companies
to be able to build their ISs in green-field
are seeking all possible ways to increase
mode, thinking modularity and Agile from
Agility and improve the time-to-market of
the start.
their products.
What they teach us is that DevOps is, on the
And when it comes to getting there, there’s
one hand, a subtle blend of modularity and
a key word: Agile!
major autonomy, and, on the other, strict
But you can’t legislate for Agile. It involves rules and operating frameworks in order to
a transformation on every level, from ways ensure that the entire system fits together.
of working, through organizational design
This publication presents the principles
and decision-making processes, to the very
of DevOps implementation, and our
architecture of information systems.
recommendations for how best to embark
While companies are starting to employ on this profound transformation, something
Agile methods in the design and that all ISDs must pursue.
development of products, they still come
I hope you enjoy reading it!
up against an unsurmountable wall that
separates “Dev” and “Ops.”

This wall was created gradually through the

construction of information systems that
became increasingly heavy, monolithic, and
strongly interwoven with each other. To this
have been added organizational silos that
keep development and production teams
apart.

To change, and move toward DevOps at

large scale, we must take our inspiration
from the practices of the GAFA (Google,

LAURENT BELLEFIN
Associate Director

3
AUTHORS

Maximilien Moulin Hasmik Manouchian

Maximilien is a manager in Wavestone’s IT & Hasmik is a manager in Wavestone’s IT &
Data Architecture Practice, who specializes in Data Architecture Practice. She specializes
Cloud and Agility projects. A graduate of INSA in technical architecture, agility, and
Lyon engineering school, he began his career governance. She joined Wavestone 6
working on internal IS architecture at Orange. years ago, after graduating from IAE
After a period as an entrepreneur, he joined Lyon 3 engineering school. She assists the
Wavestone where he has spent four years advi- company’s clients on their transformation
sing the company’s key accounts on their Cloud projects.
and Agility strategies.
hasmik.manouchian@wavestone.com
maximilien.moulin@wavestone.com

Pascal Bour
Pascal Bour is a manager who specializes in
technical architecture and the industrialization
of production. A graduate of ENSEIRB, he has
been supporting Wavestone’s clients for some
eight years in the design phases of strategic
projects, as well as helping them secure and
optimize their operations.

pascal.bour@wavestone.com

This p ub l i cat i o n wa s w r i tte n i n co llabo rat io n wit h Matt hieu B arret , Franck Lenor ma nd
et Riya d Ya k i n e.

4
 SUMMARY

06 DEVOPS : Agile from end-to-end

08 Improving time-to-value by bringing the Ops and Devs

closer together

17 PILLAR I: Modular, loosely-coupled applications

25 PILLAR II: Continious delivery for automagic deliveries

31 PILLAR III: The Infrastructure as Code, an infrastructure

driven by the application code

36 PILLAR IV: Breaking down silos, and developing Agile and

collaborative work processes

40 MOBILIZE YOUR CHAMPIONS TO BEGIN THE TRANSITION

TO DEVOPS

47 TOWARD A NEW OPERATIONAL MODEL FOR THE ISD

51 CONCLUSION

5
 DEVOPS
AGILE FROM END-TO-END

The rapid and reliable provision of relevant IT services has become an essential element
of business competitiveness, whatever the sector of activity.

To increase responsiveness, without sacrificing reliability and quality, large organizations

must transform their practices, in depth, throughout the IT production cycle: from
design to deployment.

This transformation is already well under way through the democratization of Agile
methodologies, such as Scrum, which have accelerated and increased the number
of application deliveries. However, encumbered by the long delivery times for IT
infrastructure, these methods are still not able to fulfill their potential. To truly improve
time-to-value, that is, the time between the business expressing a need and the launch
of an appropriate service, the entire IT value chain, from the business functions to
operations, must be transformed.

The DevOps approach extends Agile practices from development into production, to
take full advantage of this acceleration in application deliveries.

6
7
 IMPROVING TIME-TO-VALUE
BY BRINGING THE OPS AND DEVS CLOSER TOGETHER

DevOps is an approach that aligns stakeholders in the IT value chain (business

f u n c t i o n s , d eve l o p m e n t , a n d o p e ra t i o n s , b u t a l s o s e c u r i t y, a rc h i t e c t u re ,
c o m p l i a n c e , a n d o t h e r c ro s s - f u n c t i o n a l d e p a r t m e n t s ) t ow a r d a c o m m o n
b u s i n e s s o b j e c t i ve, w i t h t h e a i m o f i n c re a s i n g t h e re s p o n s i ve n e s s o f t h e
company within its market.

8
This approach is embodied in a set of
good practices, methodologies, and tools,
which serves two purposes: D E VO PSWA S H
// Aligning objectives between Dev and
Ops
Th ere i s , a s yet , n o s i n g l e,
// Automating the entire production convent i o n a l vi ew o n wh at t h e
cycle te r m D evOp s m ea n s . S o m e, s u ch a s
For re ster, d ef i n e i t a s t h e creat i o n
of a n a u to m ated s o f twa re d el i very
A L I G N I N G O B J EC T I V E S B E TW E E N D E V A N D p ip e l i n e; ot h ers , s u ch a s Ga rt n er,
OPS st res s t h e a d o p t i o n o f Lea n a n d
The term DevOps was born out of a
a g i le p ra ct i ces to ra p i d l y d el i ver
contraction of the terms «Development»
I T s ervi ces . T h i s l a ck o f p reci s e
and «Operations» (the teams involved
d e f i n i t i o n , a n d t h e b ra n d i n g o f
in infrastructure engineering and the
ma ny to o l s u n d er t h e D evOp s
b a nn er, cl ea rl y s u g g est t h at we
operation of IS production). Historically,
are exp eri en ci n g a p eri o d o f
the teams involved in the construction
«DevOp swa s h ,» fo l l owi n g o n f ro m
and operation of the IS were one, but the
p rev io u s waves o f « g reenwa s h » a n d
complexity of the architectures and the
«clo u d wa s h” s een i n recent yea rs .
significant growth of ISs have led to a clear
T here’s a n eed , t h en , to rem a i n
separation between those who develop
ca ut i o u s a n d n ot b e ca u g ht o u t by
the IS (Devs) and those who ensure its
t h e l a b el i n g g a m e.
operation and proper functioning (Ops).

9
The wall of confusion

APPLICATION
DEPLOYMENT

DEVELOPMENT TEAM OPERATION TEAM

PRODUCT CULTURE SERVICE CULTURE
Objectives: Objectives:
INNOVATION & FUNCTIONALITY STABILITY & RATIONALIZATION

Adapt the IS to market demands by Maintain availability by controlling

developing new features changes to reduce the risk of breakdown
= =
MAXIMIZE CHANGES MINIMIZE CHANGES

10
To d a y , c o l l a b o r a t i o n b e t w e e n DevOps practices and tools enable the
Development and Operations teams inclusion of all players in the IT value chain
is often painful. Their respective aims, into a single, integrated, and continuous
which cannot be a priori reconciled - process based on Agile principles
innovation, development and reactivity (iterations, strong business collaboration,
for Dev, and the stability and reliability of test and learn, etc.) and the development
the IS for Ops - and their strong mutual of a genuine culture of collaboration
dependencies, explain the complexity of between Dev and Ops.
their relationship. This state of affairs can
lead to a lack of performance, and also
A U T O M AT I N G T H E E N T I R E P R O D U C T I O N
mutual «annoyance.» CYCLE

Because there is too little involvement of DevOps also relies on the implementation
Operations teams, Agile methodologies, as of automation tools throughout the
they are applied in most large companies, entire IT production cycle: automation of
have not been able to address this infrastructure provisioning, application
problem. On the contrary, the acceleration b u i l d i n g , te s t i n g , a n d a p p l i c a t i o n
of the application delivery frequency deployment.
and use of a test and learn philosophy The primary aim of such automation is
have sometimes widened the gap even to absorb the increase in the volume and
more. Operations teams must deploy frequency of tests resulting from iterative
an increasing number of new features operation. It is, therefore, critical to
in production, often with an increase in guaranteeing the quality of the application
error rates. At the same time, reliability code at each iteration without creating a
requirements remain just as demanding. bottleneck downstream of application
This not only results in the creation of construction.
bottlenecks in the transition to production,
but also to ever-greater «friction» between
the Development and Operations teams.

11
 EXAMPLE OF KPIs

SOME EXAMPLES OF INDICATORS: AND THE EXPECTED GAINS*:

Number of application deliveries 200x more deliveries

Time to putting into production 2 555x faster

Number of incidents 3x fewer incidents

Resolution Time (MTTR) 24x more rapid resolution

Number of rollbacks 0 rollback

* Puppet and DORA, 2016 State of DevOps Report

Because it reduces human errors and DevOps emphasizes the automation of

facilitates measurability at each stage, the entire manufacturing and deployment
automation in the DevOps process is cycle. As a result, with the appropriate
also a lever to continuously improve, and tooling, everything becomes measurable
render reliable, the entire manufacturing over the entire cycle. Measurement is the
and deployment cycle. key to enabling stakeholder buy-in to the
process, and to continuous improvement.
Here, high-performance automation of
That is how «DevOpswashing” can be
the entire cycle is the main lever to avoid
defeated, but also a way of having the
the bottleneck between development
right indicators to demonstrate the gains
and going into production. This is the key
over the whole cycle.
to getting Operations teams out of their
firefighting role (continuous management
of problems) which they tend to be
pushed into, following the widespread
adoption of Agile practices.

12
 LE DEVOP S IS NOT :

• A FINIS H E D PRO DUCT or a g e ne r ic a p p roa ch. T h ere i s n o g en era l t h eo ry

th at can b e a p p l ie d to a l l b usi ne sse s; w hat ’s req u i red i s to t a i l o r D evOp s
g o o d p ra ct ice s to t he sp e ci f i c b usine ss context .

• A FU S ION of t he re m i t s of Dev a nd O p s. M ore over, D evOp s d o es n ot

n eces s ar il y t r i g g e r a cha ng e i n org a ni zat iona l d es i g n , n o r d o es i t
requ i re t he two te a m s to b e g roup e d w it hi n th e s a m e st ru ct u re.

• A “Q U IC K AN D DI RTY” a p p roa ch ig nor i ng t he pro ces s es o r i n d u ci n g a l o s s

o f co ntrol . I n g e ne ra l, p rod uct ion re m a i ns i n t h e d o m a i n o f Op s .

13
 FOUR PILLARS TO BUILD DEVOPS

To understand what DevOps is, we need to understand what it is based on:

// A spot of automation

// And a lot of collaboration!

14
 W H I L E CO L LA B O RAT I O N H A S TO B E A L L- E N CO M PA SS I N G , AU TO M AT I O N C A N B E D I V I D E D
INTO THREE COMPONENTS:

COLLABORATION, which is the link between all these pillars,

focusing on the alignment between Dev and Ops.

CULTURE OF COLLABORATION

APPLICATION CONTINUOUS DELIVERY

THE APPLICATION itself should be
modular and integrate information
FILE 1 MANIFEST
about the infrastructure to be BUILD
Env a : Desc Infra a
deployed, as well as the operational
FILE 2 Env b : Desc Infra b
elements and automated tests to be
performed.
DEPLOY ENVY

API TEST

INFRASTRUCTURE AS CODE

INFRASTRUCTURE AS CODE, which must deliver automated CONTINUOUS DELIVERY, which has
and standardized-interface runtime environments for the to offer a pipeline that allows the
application, as a function of the needs expressed within its testing of the application in an
source code. automated way, and its deploy-
ment on the right environment at
the right time.

15
So, to deliver a DevOps transformation // Infrastructure as Code: lean toward
successfully, it is essential to pursue a consumable service infrastructure,
four parallel threads—the four pillars of and also, one that can be integrated
DevOps: with application delivery

// A p p l i c a t i o n s : P re p a re fo r t h e // Collaboration: change the culture

transformation of applications by and practices to move toward an
making them modular and possible organization without silos, and driven
to automate by Agile methodologies

// Continuous Delivery: automate the

delivery chain from the development
to going into production

The application once built

CULTURE OF 1 (compiled) must be deployed in
an environment (such as test,
COLLABORATION integration, production, etc.).

The Continuous Delivery pipeline

APPLICATION CONTINUOUS 2 uses the Infrastructure API to
DELIVERY request construction of the
environment.
FILE 1 MANIFEST
Env a : Desc Infra a BUILD
The infrastructure uses the
Env b : Desc Infra b
FILE 2 1 application’s configuration file
3 (Manifest) to create an environment
tailored to the application.
DEPLOY ENVY
3 2

5
6 The infrastructure then orchestrates
API 4 the effective creation of the
4 TEST
environment.

INFRASTRUCTURE Once the required environment is

AS CODE 5 created, the application is deployed
on it.

The application can then be tested

6 according to the tests present in the
application code

16
 PILLAR I
MODULAR, LOOSELY-COUPLED
APPLICATIONS

17
A N A R C H I T E C T U R E T H AT I S N E C E S S A R I LY An application built in this way is an
MORE MODULAR assembly of modules (up to several
dozen), which are all independent code
Being more Agile involves delivering new elements, each under the responsibility
application versions, usually by sharing of a «feature team”: a small, autonomous
the work over several teams (often small, team that carries out the think, build, and
and multidisciplinary, “feature teams”). run activities for the module.
This requires the decoupling of their
work to achieve greater efficiency, and, The exchanges between modules are
therefore, the use of more modular standardized, and rely on interfaces
application architectures. (APIs), which allow them to be
decoupled. These APIs will be able to use
While service-oriented architectures have management solutions (API management)
been held back by centralized and rigid to allow developers to work autonomously
governance structures, the focus here is on their creation, publication, and
on decentralized approaches that give consumption. This will, however, require
developers autonomy in their publication service-mapping solutions to avoid a loss
and consumption activities. of control over the IS.

MONOLITHIC ARCHITECTURE MODULAR ARCHITECTURE

HS HS

 X X   

Team A Team B Team C Team A Team B Team C

With monolithic architecture, each delivery requires the With modular architecture, several teams can work on
entire monolith to be put into production. different modules at the same time.

18
B eyo n d t h e s e b ro a d t h re a d s , t h i s In a modular approach, the components
approach is also an important facilitator in of the application must, therefore, be very
developing an Agile approach because it loosely linked—at all levels:
helps improve the quality of code, facilitate
// In terms of frameworks and libraries,
teamwork, speed up the execution of tests,
which can be used as tools, but
and so on.
must not define the structure of the
application layer.

// Between application modules

TH E C ASE OF MICR O-S ER V ICES and all things external, in order to
simplify the carrying out of tests.
The application and its modules must
M i c ro - s er vi ce a rchi te ct ure, a be unitary testable without requiring
paradi g m th at ha s b e e n d eve lop e d a user interface, database, or other
fro m t h e pract ice s of B 2 C p l aye rs applications. This places a great
w i t h ver y b ro a d use r b a se s, of fe rs, importance on the unit tests within
i n par ti c u l ar, a re sp onse to t he the code of each module of the
n eed fo r s pecif ic f unct i ons in a application, as well as on the creation
system to b e h ig hl y sca l a b l e. Whe n of plugs to allow unitary testing of
fo l l ow i n g a rati ona l e of d i sm a nt li ng a service.
fu n ct i o n al bo u nd a r i e s a nd re p l a cing
t h em w i th autonom ous f i ne l y- // In terms of the user interface. This
m es h ed s er vi ces , w hi ch neve r t he le ss must be replaceable without any
co nt i n u e to i nte ra ct w it h e a ch ot he r, impact on the application layer and
arc h i tectu re, inf ra st r uct ure, a nd its functions.
o p erati o n al p ra ct ice s m ust evolve
co n s i d erabl y i n ord e r to m a na g e a // In terms of data persistence. To be
pan o p l y o f m i c ro-se r v i ce s w hi ch m ay scalable, this type of architecture
b e i n stant i ated in a n a d -hoc fa shi on. requires stateless services. The
persistence of data and sessions must
be managed in a way that ensures an
increase or reduction in load, while
ensuring the consistency of the data.

// In terms of any other function that

is external to the application and
comes from other applications or
services.

19
RAPID AND WELL-MANAGED RELEASE order to put certain functionalities into
production in a partial or targeted way.
D e s i g n i n g a p p l i c at i o n s i n D ev O p s
mode requires more robust tests to In the same way, this requires the
be performed (in particular through application to be conceived so that it is
automating them) and taking more risks directly operable, without waiting until it is
in the production stages. This needs put into production to address its placing
development methods to evolve, and under supervision or backup, the design
the introduction of new approaches such of new automation scripts, performance
as Test Driven Development, Feature problems, scalability or other operational
Flipping, or Blue-Green Deployment, in issues.

20
 UNIT TESTING: THE TEST-DRIVEN-DEVELOPMENT APPROACH

WHEN A DEVELOPER CODES A FUNCTION, THEY GENERALLY DO THE FOLLOWING THREE

THINGS:

1 Write the function’s source code;

2 Write the unit-test source code for the function;

3 Run the unit test for the function in order to verify that it passes.

WITH A TEST-DRIVEN DEVELOPMENT APPROACH, DEVELOPERS DO THE OPPOSITE. HERE

THEY:

1 Write the source code for the unit test for the function to be developed;

2 Write the function’s source code which allows the test to be passed;

3 Rework the code to improve it, while making sure that the test continues to
be passed.

This method ensures that each function is associated with one or more unit tests,
and it thus facilitates the non-regression tests while, at the same time, detailing
the specifications, because the test describes the expected behavior.

TEST-DRIVEN DEVELOPMENT

1 TEST FIRST 2 DEVELOP 3 REFACTOR

Write the test for the Write the minimum Rewrite and
functionality to be developed functional code to pass optimize the code
the test

Check whether the test has Check whether the test has Check whether the test has
been failed been passed been passed

Repeat the sequence for any new features

21
EXAMPLES OF DEPLOYMENT METHODS

Web Server App Server DB Server

Version n

BLUE/GREEN Version n+1

DEPLOYMENT

Deployment of an n+1 version on an environment parallel to the production

version, n, and facilitated flip-flop from n to n+1, and from n+1 to n (rollback).

Version 3

INTERNAL USERS

Version 2

Small group of users

CANARY
RELEASE Version 1
CLIENTS
Main users

Deployment of several versions in parallel, some versions (or functionalities) are only
open to certain populations (alpha then beta testers) before being rolled out (or not).

22
 Version 1A
67%
50% conversion

Version 1B
A/B TESTING CLIENTS
50%
11%
conversion

Deployment of two variants of the same version in parallel in order to compare the
results and determine which one to retain.

NEW FEATURE FEATURE FLAG OR CONSUMERS

TOOGLES

ON

OFF
FEATURE
FLIPPING OFF

Deployment of features that can be activated via an application interface. This enables
certain functionalities not to be activated if the tests do not take place, without slowing
down release. Can be combined with the Canary Release.

23
Functional tests (or recipes) should be
mostly automated too, in order to check
that there are no functional regressions THE A NO NY M I ZATI O N
during each iteration, and verify that OF DATA
newly created, or modified, functions are
behaving correctly.

This is not trivial and involves being able

I n ce r t a i n s ecto rs ( i n p a rt i cu l a r,
to test function calls and human-machine
b a nking an d i n s u ra n ce) t h e n eed
interactions, in order to retrieve and
for d at a to rem a i n a n o ny m o u s i s
b e com i ng i n crea s i n g l y i m p o rt a nt .
analyze the elements (data or graphics)
I n co ntext s l i ke t h i s , t h e
returned, and to maintain and develop all
im p le m e nt at i o n o f D evOp s s h o u l d
the data sets required to perform the tests.
e nsure t hat t h e a u to m at i o n p u t i n
Enabling this automation for an existing p l a ce is ca pa b l e o f a n o ny m i zi n g t h e
application could mean a significant l ive d at a u s ed i n f u n ct i o n a l test i n g .
workload, even higher than that for unit-
test implementation, and could lead to an Cur re nt l y, t h i s i nvo l ves a
increase in delays and workloads to be consid e ra bl e ef fo rt b eca u s e, a s yet ,
managed. t he re a re no to o l s o n t h e m a rket t h at
a re s u f f i ci ent l y m at u re.
TECHNICAL DEBT IS NOT A PROBLEM,
PROVIDED IT IS MANAGED However, studies show that a DevOps
approach reduces the time spent on
More rapid construction of an application
unplanned work (bugs), or code recovery,
necessarily involves compromises. As a
by up to 22%.
result, technical debt (in terms of code,
infrastructure, management tools, etc.) is
quickly and easily incurred, with a need Total debt
to «pay it off» throughout the life of the
project. Toxic level of debt
(historical)
In a DevOps approach, it is important
to monitor this technical debt using a
KPI, and, as and when required - when
t h e a g re e d l i m i t s a re a p p ro a c h e d
- to i nve st t h e t i m e to p ay i t o f f.
Conversely, there is no benefit in trying
to get to a position of zero debt; aside Health level of debt
from the risk of over engineering, doing (recent)
this puts a real brake on Agility.
Attainable in pratice Time
Ideal position

* Puppet & DORA 2016 State of DevOps Report

24
 PILLAR II
CONTINUOUS DELIVERY FOR AUTOMAGIC DELIVERIES

Continuous Delivery (CD) is an automated software construction chain. It is a

set of processes, tools, and techniques to manage application deliveries, from
the production of code, through build, deployment, testing, and packaging, to
the delivery of functionality... The aim? To increase the frequency and speed
of deliveries in a reliable way—both rapidly and continuously.

DEVELOPMENT OF A NEW
ITERATION

TEST BUILD
1
3

2
DEPLOY

25
Continuous Delivery is normally Once this is confirmed, all Ops then
considered to be based on two automation has to do is to trigger the deployment
chains: of the application (i.e. “push-button”
deployment).
// The Continuous Integration (CI)
chain, targeted at development and C o nve r s e l y, d e p l oy m e n t o n o t h e r
integrating the processes of build, environments (such as non-production,
measurement of technical debt or pre-production) can be completely
(code quality), unit tests, and user automated.
acceptance;
Once a certain level of maturity has been
// T h e C o n t i n u o u s D e p l oy m e n t achieved, it is entirely possible to envisage
chain, which extends the CI chain automatic, end-to-end deployment (c.f.
by automating the provision diagram opposite).
of infrastructure environments
CHOOSE TOOLS ACCORDING TO THE
and application deliveries. This
CIRCUMSTANCES, NOT THE LABEL
extension is supported by Ops using
methodologies and tools that are Today, the tools for the Continuous
almost identical to those of Dev. Ops Delivery chain are quite heterogeneous:
thus manages the consumption of given the burgeoning market for DevOps
infrastructure elements, configuration tools, each function has its tool, which can
management, and application be chosen from a myriad of solutions.
deployment.

Therefore, the entire chain is automated The first reason for this is that there is
until going into production. Before no clear, common definition of DevOps,
release, Ops must verify that a number of which allows many vendors to apply
prerequisites have been met, such as the the DevOps label to any tool related
conformity of the application with the rest to software design, a software factory,
of the IS, that there are sufficient resources configuration management, or any other
available within the relevant teams to form of orchestration («DevOpswash»).
respond to incidents, the availability of
infrastructure, the timeliness of deploying
a new version, etc.

26
 CODE BUILD TEST DEPLOY

Continuous Integration

Source Code Automated Automated

Management builds tests

Continuous Deployment
A commit statement A successful build If the tests are
triggers the build triggers the tests passed, the build is
validated
At this point, Automated
the code can be Deployment
deployed at any
time

Continuous Delivery

27
Moreover, considerable effort is going into extending the scope of many tools beyond
their traditional technico-functional domains, which makes the actual contribution of
the various tools more complicated to discern, while still not producing true, end-to-end
software suites.

To f i n d a way t h ro u g h t h i s co m p l ex i ty, we re co m m e n d c l a s s i fy i n g to o l s a s s h ow n i n
the following matrix:

CONTINUOUS INTEGRATION

SOURCE CODE MANAGER CONTINUOUS INTEGRATION SERVER

• git • Bitbucket • Github

• AWS CodePipeline • XL
• CodeCommit • CVS
Release • TC • B amboo
• Subversion • Mercurial •
•Travis CI •
Helix •

BUILD TEST

• J Unit • Selenium
• Maven • Gradle • Grunt •
• S auce Labs • Test
Apach ANT • NPM •
Complete•

CODE QUALITY

• SonarQube • Kiuwan •
Semmle •

28
 DEPLOYMENT CONFIGURATION MANAGEMENT

• IBM Active Deploy • XL

• Vagrant • Puppets Labs •
Deploy • Google Cloud
Chef • Ansible • S altstack •
Deployment Manager •
Terraform • CF Engine •
Container & orchestration

Docker • Kubernetes • Mesos •

COLLABORATION

• Trello • Slack • Jira• HipChat •

Continuous Integration Continuous Deployment Collaboration

The present lack of consensus on the implementation of DevOps currently prevents

the software industry from offering dedicated solutions. However, these solutions will
emerge in the coming years, which will require adherence to their particular modes of
operation (and, therefore, the associated practices).

29
The type of tools to choose will depend on a company’s specific circumstances: if it
is an early adopter, it will prefer a best-of-breed model or a solution, based on a public
cloud with its associated tooling; if it is more of a “follower”, it will be able to choose
an integrated suite from a supplier in the market or an outsourced, turnkey solution.
EARLY ADOPTERS

PUBLIC CLOUD BEST OF BREED

ADOPTION

FULL EDITOR
OUTSOURCER
SUITE

IN-HOUSE SKILLS
EXPERTISE

Lastly, some tools naturally have to While the tools that lend themselves to
be centralized while others can be being instantiated by individual teams
instantiated on a team-by-team basis, may be:
with each one maintaining control of
// Applications builders;
the frequency of updates for the tool
in question, or managing some specific // Tools for unit testing, code cove-
aspects of configuration. rage, and compliance with coding
Generally, tools that are centralized and standards;
common to all are:
// D e p l oy m e n t to o l s (co n f i g u ra -
// Source/artifact management tools tion management and application
(libraries, configuration files, etc.); deployment).

// Test coverage management tools;

// Tools for publishing analyses of

results.

30
 PILLAR III
THE INFRASTRUCTURE AS CODE, AN INFRASTRUCTURE
DRIVEN BY THE APPLICATION CODE

Infrastructure as Code (IaC) is the ultimate stage of Agility and infrastructure

commoditization.

31
For several years now, the market has been IaC therefore allows the infrastructure
making considerable progress in moving to be defined in a new way: it becomes
toward the automation and consumption simply a form of computing power,
of infrastructure: we now commonly s c a l a b l e w i t h o u t d i f f i c u l t y, a n d
talk about “as a service”, «on demand“, manipulable by the Devs through normal
“catalogs of services”, “the Cloud,” “API,” application code languages.
and so on. Infrastructure as Code takes
this concept further still.
BEGIN MAKING INFRASTRUCTURE AGILE—BY
AUTOMATING IT
The purpose of IaC is to enable the
automatic creation, and configuration, of Of course, infrastructure automation
a complete execution environment (both remains a prerequisite for IaC: in order
infrastructure elements and middleware), to manipulate infrastructure through
through the application code. Developers application code, it must be exposed
manipulate the infrastructure in the through programmatic interfaces (APIs).
application code itself, in the same way This automation can be done in three
as functionality. steps, which correspond to three levels of
maturity.

I m plem ent in g a st ate - o f- t h e -a rt I AC i s n ot a p re re q u i si te for D ev Op s: yo u

can b egi n w i t h a n init ia l set of p roj e ct s by a utom at i n g o n l y p a rt o f t h e
i nfrast r u ctu re an d m ov i ng towa rd e nd -to-e nd I nf ra st ru ct u re a s Co d e t h ro u g h
succe ssi ve ite rat i ons.

32
 The first step - providing the These three steps can be carried out
1
envelope of the Virtual Machine - is sequentially, or at the same time,
often the simplest. From a DevOps depending on the extent to which the
perspective, however, final barriers infrastructure has been automated.
to complete automation (often the
There is also a need to move toward
configuration of the network) must
automation of infrastructure services:
be removed, and the environment
b a c ku p, te c h n i c a l a n d a p p l i c at i o n
provisionable in a single click.
supervision, scheduling, and security.
T h e s e c o n d s t e p - d e p l oy i n g The aim here is to ensure that resilience,
2 middleware - becomes immediately security, and operational services are
more complex. One way to simplify directly managed in the application by
it is to create Virtual-Machine models the developers themselves; it is, therefore,
with pre-installed middleware; important that developers can subscribe
but this method soon reaches its directly to these services through an API.
limits (as a result of difficulties in
managing the life cycle of the model,
adding new middleware, etc.). It PAA S - A N ACCE LE R ATO R
is therefore preferable to be able
to directly provision the required Pa a S ( P l at fo rm a s a S ervi ce) to o l s
machines and middleware in an ca n b e p owerf u l a ccel erato rs , i f yo u
automated fashion, perhaps even a re a b l e to m eet t h e ch a l l en g e o f
using defined application topologies inte g rat i n g t h em wi t h t h e I S , a n d , i n
(the deployment of a set of elements p a r ti cu l a r, t h e exp l o i t at i o n ch a i n .
according to a previously defined
scheme). We a re wa ry o f p ri vate Pa a S s o l u t i o n s
(d evel o p ed i n -h o u s e o r s o l u t i o n s
The third step is often the most f rom s o f twa re ed i to rs , d ep l oyed
3
complex, as it requires interaction on-prem i s es) wh i ch a re o f ten n ot
with other elements of the ve r y m at u re, a n d wh i ch s i m p l y d o
i n f ra s t r u c t u re ( f i rewa l l s , l o a d not in cl u d e s o l u t i o n s to t h e i s s u es
balancers, exchange gateways, etc.) a s s o ci ated wi t h i nf ra st ru ct u re
in order to provide the application se rvi ces ( b a cku p, s u p ervi s i o n ,
with a complete execution n etwo rk, a n d s ecu ri ty) .
environment.

33
S I M P L I F Y T H E I N F R A ST R U C T U R E TO G I V E U S E T H E P U B L I C C LO U D W H E N A P R OJ EC T
DEVELOPERS AUTONOMY STARTS WITH A BLANK SHEET OF PAPER
Mere automation of this process is not Tools are, above all, a matter of context.
sufficient to qualify it as Infrastructure There are numerous tools: from ones
as Code; the deployment must be designed for a particular function
accessible via an API and be able to only, to the complete suites offered by
define, in the application’s source code, large publishers, and Pure Player cloud
the infrastructure required to make the solutions; solutions exist for all contexts.
application function:
Thus, an organization with strong, internal
// The number of servers and asso- technical skills will use a different strategy
ciated middleware; to a company that typically relies on
external resources. Similarly, a company
// Application services to be deployed willing to take risks to differentiate itself
(memory cache, message queue, (an «early adopter») will not use the
etc.); same approach as a company that values
stability and seeks mature solutions to
This must make it possible to simplify the
safeguard the proper functioning of its
infrastructure in order to offer developers
business activities.
straightforward computing power only.
EARLY ADOPTERS

SOLUTION CLOUD PUBLIC BEST OF BREED SOLUTION

comprising various software

Microsoft • Azur • Heroku • Acquia •

Engine Yard • SAP • ORACLE Cloud • Chef • CF Engine • Ansible • Puppets
Google Cloud platform • IBM • Labs • S altstack •
Amazon web services •
ADOPTION

YOUR OUTSOURCER’S PLATFORM FULL EDITOR SUITE

IBM • Atos • Linkbynet • Sygma • HCL

• Capgemini • GFI • CGI • Tata • Wipro
BMC • WM Ware • IBM• HP• CA
• Cloud Temple • Accenture • Orange
• Atlassian •
Business Service • Sopra • Steria • CSC •
Claranet • HP Enterprise •

IN-HOUSE SKILLS
EXPERTISE

34
Whatever the circumstances, a Public Lastly, when designing an IaC, it is
Cloud approach is something to consider essential to standardize the infrastructure
because the players associated with and, therefore, make choices:
this type of Cloud are currently ahead
// Choose where to invest the effort
of the market. Amazon, Microsoft, and
to automate and mass produce the
Google have achieved a level of maturity
components that make sense.
that cannot be bettered by companies’
internal teams, because this area is not // Accept that workloads which do
a core activity for them. Therefore, if not fit with this standard will not be
you are using a Private Cloud strategy, it included. This also means that any
makes sense to know why, and for which new application must be designed
workloads, this strategy is the best choice. to follow these standards.

35
 PILLAR IV
BREAKING DOWN SILOS, AND DEVELOPING AGILE
AND COLLABORATIVE WORK PROCESSES

The DevOps culture draws on Agile and Lean methods (empowerment, trust,
respect, and transparent communication) as well as a business-centric
approach: a catalyst for greater cooperation between the business functions,
Development and Production.

36
This cultural change will not happen // Develop the indicators so that deve-
overnight, and it is best to spread it over lopers are not assessed only on the
two broad stages: quality of their code, or the frequency
of their releases, but also on having
a good understanding of the require-
ON A PROJECT ments of production (and vice versa
1
for Ops).
// Assemble a team that includes people
with all necessary skills (Devs and Ops, // Leverage collaborative tools (such as
but also members from Architecture, Trello or Jira Agile) to facilitate and
Security, Compliance, etc.)
strengthen the link between Dev and
// Refocus the Ops function on building
new, automated services Ops

// Make Dev accountable for ensuring the

operability its products “IT IS ALL ABOUT PEOPLE» #HUMANFIRST
A DevOps transformation is, above
ENTERPRISE-WIDE all, about people—human beings—and
2 collaboration.

Therefore, the first obstacles to be

// Broaden this way of working to most
projects removed will be those related to issues
// Propagate the DevOps culture widely by of collaboration: people who need to be
sharing issues and success stories convinced that things can be done better
// Plan the organizational structure of the by doing them differently, unhelpful
ISD and how the target operating models
will evolve
processes to be dismantled, objectives
(including supplier objectives) to be
reviewed, tools to be changed, etc. All
these things can be achieved only by
Achieving this requires a common,
drawing on reliable, motivated, and highly-
mutually-agreed language, and shared
competent people with a solid capacity
indicators and tools:
to adapt (Google talks about «Highly
// Share a vision for «products» rather Skilled Engineers» in its «Site Reliability
than «projects»: the teams can deli- Engineering» (SRE) methodology).
ver products that will be used by end
Moreover, as in any change management
customers rather than simply being
project, there will be a requirement to
contributions to a lambda project.

37
communicate the successes and failures pioneered by Google (SRE), Spotify,
on the objectives, and the impacts on the Amazon, and Facebook. These practices
organization and its business functions. are moving things further along the
road toward full Agility. They have led
ORGANIZATIONS ARE ALSO DRAWING to the emergence of somewhat complex
I N S P I RAT I O N F RO M T H E I N T E R N E T G I A N TS principles and methods aimed at
IN THEIR QUEST FOR AGILITY developing company-wide Agility.
Others are now emulating the practices

// Spotify is pursuing a methodology whose main pillar is the autonomy

given to its teams (known as feature teams). In order to maintain the
i nte g r i ty o f i t s I S , S p o t i fy h a s s et u p co m m u n i t i e s ( k n ow n a s c h a p -
te rs , t r i b e s , a n d g u i l d s) w h i c h b r i n g to g e t h e r t h o s e w i t h s p e c i a l i s t
knowledge of a particular topic to form a type of matrix-based hierarchy.
SPOTIFY
// Recognized as being a state-of-the-art structure for Agile organizations,
it nevertheless involves a methodology that is not well documented, and
one that requires a high level of maturity in terms of Agility and team
management.

// SAFe is a framework developed in 2011 by a team of multidisciplinary experts

on Agile organizations. It was designed for traditional organizations (rather
than internet Pure Players) to address complex programs involving nume- SAFe
rous teams. Scale Agile Framework

// It is aimed at companies who have already mastered the Agile Scrum

method.

// The Scrum of Scrums is a technique that enables several Scrum teams to

work together in a very straightforward way, without the need for a com-
plicated framework.
SCRUM OF SCRUMS
// While this technique does not help in developing Agility at enterprise level,
it can be a step toward developing it at large-project scale.

38
 TRADITIONAL AGILE
ORGANIZATION ORGANIZATION

ORGANIZATIONAL AND FUNCTIONAL MULTIDISCIPLINARY TEAMS

SILOS AND UNITS

PART-TIME INVOLVEMENT IN FULL-TIME INVOLVEMENT IN A TEAM

PROJECTS AND ON TASKS

STRUCTURE COMPLEX, MULTILEVEL HIERARCHY FEWER HIERARCHICAL LEVELS

CENTRALIZATION OF MANAGEMENT
CONFIDENCE AND DELEGATION
DECISIONS

CONTINUOUS CHANGE AND DELIVERY

MANAGEMENT PROCESS FOR MAJOR
PROJECTS

PROCESS BIG BANG V-CYCLE AND CHANGE DEVELOPMENT OF MINIMUM

VALUABLE PRODUCTS AND RAPID
MANAGEMENT
CLIENT FEEDBACK

NUMEROUS INDIVIDUAL KPIS MORE COLLECTIVE KPIS

FLEXIBLE PROCESSES ADAPTED TO

RISK AVERSION AND CONTROL THE NEEDS OF THE BUSINESS
CULTURE
PEOPLE

39
 MOBILIZE YOUR CHAMPIONS
TO BEGIN THE TRANSITION TO DEVOP

IaC, Continuous Delivery (CD), Culture... Where should you start? How can you
initiate a DevOps approach?

40
The transition from traditional methods A DevOps deployment strategy can be
to DevOps represents a real break in the broken down into three areas:
organization of work. Its deployment is a
// The choice of initial scope
progressive and delicate undertaking that
requires a degree of human and technical // The deployment of a platform1
investment not to be underestimated.
// Skills development
The early stages of the transformation are
key to assembling the relevant players,
setting out the rationale for future
investments, and creating a dynamic of CHOOSE A SHOWCASE PROJECT FOR
sustainable transformation. The path taken T H E T R A N S F O R M AT I O N , W H I C H I S B O T H
can, and must, make it possible to realize AMBITIOUS AND SAFE-TO-FAIL
returns on investment from the very first
Projects must be chosen to gain
stages of transformation.
commitment from the business functions
A project-by-project route makes it from the start, something that can then be
possible to stage the effort over the long- maintained for each subsequent project.
term, and to quickly obtain gains that are
To achieve this, it is essential to select
both visible and measurable.
a scope such that it focuses on the key
needs of the business functions, and
for which the returns from a DevOps
approach will be tangible, significant, and
simple to implement.

“The path taken can, and In DevOps, an iterative approach, coupled

with strong team involvement - from the
must, make it possible to business functions to production - makes
realize returns on investment it possible to quickly adapt to change by
removing operational constraints. DevOps
from the very first stages of
therefore fully guarantees a response
transformation.” adapted to the specific need, even if things
are clarified - or change - as the project
progresses. In any case, it is these projects
or products, whose needs frequently
change, that will allow a company to

1- Platform means: the deployment of collaborative tools, Continuous Delivery platforms, and automation (Infrastructure as
Code).

41
demonstrate that DevOps is a better However, the chosen scope must be secure
and faster approach than conventional («safe-to-fail»). As the chance of failure is
methods, including those that typically non-negligible, it is important to have an
require the close involvement of Ops. alternative plan in place that allows the
acceptance of such risks.

ALL PROJECTS CAN BENEFIT FROM AGILE METHODS, BUT THE PRIZE IS APPLYING IT TO PROJECTS
WITH RAPIDLY CHANGING NEEDS
Projects where the need is unstable (i.e. the end result is not predictable) are natural
candidates for the Agile and DevOps methodologies because they benefit directly from
their iterative approaches.

Simple and stable projects can be safely handled by conventional methods. In time, these
too could also be addressed effectively by Agile methodologies.

Lastly, complex projects with stable needs can use either approach, provided the needs can
be properly understood. If not, Agile methodologies are preferable.
complex

AGILE OR AGILE
AGILE
V-CYCLE
COMPLEXITY

V-CYCLE AGILE

INSTABILITY OF NEED
Unstable

42
STA RT W I T H E A S I LY AU TO M AT E D issues, as well as those with relatively
APPLICATIONS short development cycles. The greater
the obstacle associated with such
The choice of initial projects must also applications, the more obvious the
consider the applications involved. benefits of a redesign. This can also serve
The amount of effort required to integrate as a rationale for making the investments
an application into the continuous delivery required to automate application delivery.
chain is rarely negligible. On the Dev side, PRIORITIZE THE CONSTRUCTION OF THE IAC
there is a need to transform the usual
AND CD PLATFORM AS A FUNCTION OF YOUR
integration processes, and sometimes
PAIN POINTS
to change elements of the tools. On the
Ops side, all delivery process automation Deployment of the platform will require
scripts must be reviewed, in order that significant investment over the long-term,
they can be managed using the same tools though, paradoxically, this will not be very
as those employed by Dev (versioning, visible within the business. However, it is
build, testing, etc.). Avoiding breakdowns this platform that will sustain the success
in the delivery chain is at the heart of of the approach.
DevOps principles.
Worse still, if it is badly or half-heartedly
To minimize initial investments, it is implemented, the result can be to make
important to select applications for Ops’s pain points worse and endanger
which the integration effort, in terms of the success of the projects selected. This,
maintaining a continuous delivery chain, in turn, risks the business abandoning
is minimal. the DevOps approach and returning to
traditional methods.
Typically, software packages that require
a quasi-manual intervention for a license The first projects will be those to build
key to be acquired, or the use of a the initial platform for Infrastructure as
graphical interface for installation, should Code and Continuous Delivery. The scope
be set aside in the early stages of the of this platform will be extended over time,
transformation. project by project.

Similarly, some applications, by nature, Each DevOps project should be seen as

lend themselves very badly to the an opportunity to draw on the budget
automation of tests. to develop the building blocks that
constitute the platform - and each
Among the applications identified as
improvement to the platform as a way to
suitable, it makes sense to target those
reduce the effort required in subsequent
whose delivery process has already
projects. Prioritization is the key to
been identified as a barrier in terms of
maintaining this virtuous circle.
time-to-market and quality of service

43
A good practice is to set an automation Lastly, some organizations, faced with
goal for each project which will be the complexity of managing a very open
processed within a sprint, in the same and heterogeneous IS (multiplying, for
way as application functionality. In some example, the number of IaC platforms)
cases, if the project is sufficiently long and will need to pursue automation until an
complex, it may be possible to see a return orchestration layer can be put in place
on investment even before it ends. for their different IaCs (both internal
and external, if they rely on external
As for the automation of application
infrastructures) and an orchestration
deliveries, a particularly effective practice
platform for delivery chains.
is to make use of projects to transform the
building blocks already identified as pain A Meta-Orchestrator or Business Process
points by the teams. Management (BPM) may also be required
to manage deployment processes on a set
The deployment of collaborative tools,
of applications, by ensuring consistency
whether for project management or
across the business. The deployment of
application code, must be treated as a
a Meta-Orchestrator is the highest level
priority. These tools are key to improving
of automation of deliveries - it automates
interactions between teams and aligning
the releases, taking into account all
them toward common goals.
dependencies between different
applications.

THE P UBLIC CLOUD

AN ACC ELERATO R FO R DEVO PS TRANS FO R M AT IO N

Creating a n ew p latfo r m f ro m a n ex istin g o n e ca n b e l o ng a nd co st l y.

The P ublic Cloud can th e re fo re b e a p owe r f u l, a n d low-co st, acce l e rato r to l aunc h a
D evOps ex p e r im e nt u sin g a su ite th at is a lre a d y i nte g rate d .
All major P ublic C lo u d s ( Mic ro so f t A z u re, A m a zo n We b S e rv i ce s , a nd t he G o o g l e
App Engine) offer th e ir ow n su ite s. T h e se a re co m p o se d o f I aCs and to o l s to b ui l d
a Continuous-D elive r y d ata b a se, in c lu d in g a n u m b e r o f f re e to o l s (i n p ar t i c ul a r fo r
te stin g a n d co d e q u a lity) .
We strongly recom m e n d u sin g th e se in itia lly in o rd e r to b e ne fi t mo re q ui c k l y fro m
concrete res ults and e n a b le a m o re a m b itio u s tra n sfo r m atio n t hat d o e s not p re j ud g e
what ex ists a lre a d y o r th e p ro ce sse s a lre a d y i nst a l l e d .

44
 STA RT W I T H T H R E E « F E AT U R E T E A M S » O F In parallel with the first project, the IaC
C H A M P I O N S TO B U I L D T H E P LAT FO R M A N D and CD feature teams will put in place
the first elements of the platform needed
FIRST APPLICATION IN DEVOPS MODE
to launch the projects in DevOps mode.
In order to ensure the success of the The scale of these will be determined as
first project and effective propagation a function of the speed at which these
of the associated practices, three teams first elements are to be put in place and,
must be brought together - with their naturally, the means that will be used to
members selected from those who can be do this.
considered champions in their respective
At the beginning, these teams should
fields:
be based in the same place, or at least
linked using effective collaborative tools.
Similarly, they should undergo common
training in order to forge strong links from
the beginning.

A N IAC FE ATU RE TE AM , in c h a rg e o f b u ild in g th e

Infrastructure as Code p latfo r m (o rc h e stratio n ,
AP I, and deployment te m p late s) .

INFRASTRUCTURE APPLICATION
AS CODE

AN AP P L I C AT I ON F EAT U RE T EAM
A CD F E ATU RE TE A M , in charg e
(o r p ro d uct te a m), w hi ch i nc l ud e s
o f bu i l di ng the Continuous
an O p s te a m me mb e r, to b ui l d
Del i very pipeline (the
awa re ne s s w i t hi n D ev a b o ut t he
Co nti n u ous D elivery s erver, th e
i s s ue s t hat O p s face s .
pu tti n g in place of SVN tools ,
testi n g, etc. ) CONTINUOUS DELIVERY

45
THE ORGANIZATION WILL BE AGAINST YOU:
YOU NEED TO PROVE THEM WRONG! THE M I STA K E S TO AVO I D
Transformation toward an Agile model
T h e f irst sig ni fi cant t ransfo r mat i o ns to
will necessarily experience resistance to h ave b e e n a chi eve d i n t hi s a re a have
change. It is vital that the success of the a lre a d y reve a l e d s o me o f t he p i t fal l s to
first project is communicated widely. avo i d :

It is also essential to set up, right from the

• T H E SYSTE M WI LL BE AGAI NST YOU: you
initial project, quantified indicators that
m u st th e refore stres s the as s oci ate d ROI .
will help make the success of DevOps a
• T H E NEED TO D E MONSTRATE THAT YOU ARE
reality.
RIG H T: to do thi s , you must meas ure the
The tools used in the process allow b en efits of the transformati on.

detailed analysis of the code quality, • YOU W IL L E XP E RI E NCE FAI LURE s : i t i s

deployment times, numbers of essential to acce pt fai l ures and e rrors
by ta k in g an i te rati ve, « test and l e arn»
application deliveries, numbers of bugs, a p p roa c h.
etc. These aspects also serve as points
• “ONE SIZE D OE S NOT FI T ALL: » e ach
of measurement, making it possible to DevOp s approach must be adapte d to
demonstrate the attractiveness of the th e c irc umstances and chal l enge s of the
approach and the return on investment com p a ny whe re i t i s be i ng i mpl e me nted.
it brings. • RESPECT FOR THE MONOLI TH: i t i s e s s e nti al
to integ rate the new approach wi th
It is a question of highlighting these gains h istor ic / l egacy systems , and to re s pect
and promoting them, in order to provide existin g proces s e s , as appropri ate. D on’t
tr y to re bui l d eve rythi ng from s cratch.
the rationale for the investments already
made - and those required in the future.

KEY S UCCES S FACTOR S

S imilarly, there are s everal key s ucces s facto r s t hat ca n b e h i g h l i g hte d :

• S I M P LI F Y: p ro ce s s es, infra str u ctu re, etc . Ever y th in g m u st b e sta n dardi zed.

• AU TO M AT E : yo u r i nfra str u ctu re, p rocesses, a n d a ll rep etitive, low adde d-val ue acti ons .

• R ECRU I T H I GH - Q UAL ITY ENG INEERS A ND DEVELOPERS: tu r n in g th em i nto prope rl y qual i fi ed Ops
w i t h re s p o n s i b i l i ty for th e d esig n of n ew ser vices a n d IS b u ild in g bl ocks .

46
TOWARD A NEW OPERATIONAL MODEL
FOR THE ISD

Once the first projects have demonstrated the value of the approach, it will be
a question of extending good practices throughout the business.

T h e m e m b e rs o f t h e f i rst te a m s m u st s e r ve a s co a c h e s a n d a m b a s s a d o rs to
d i s s e m i n ate g o o d p ra ct i ce to t h e p ro d u ct te a m s t h at w i l l p ro g re s s i ve l y b e
formed within the ISD.

T h e te a m s t h at co nt r i b u te d to t h e co n st r u ct i o n o f t h e I a C a n d C D p l at fo r m
must be the first building blocks of the competence centers that will develop
the platform, according to the needs of the Product teams, and act as support
to Ops.

47
To ensure a degree of «cross-fertilization» (the dissemination of knowledge between
the teams), it is important to foster the construction of communities that share good
practices between Dev and Ops, but also Architects and others.

These communities should also allow a common reference framework on Agile

methodologies (project, management, community coordination, etc.) to be developed.

Lastly, this transformation must respect the legacy system and the work of those who will
continue to maintain it. Minimizing the risks of this stage is, therefore, not only a question
of managing the technical elements (such as interoperability, scalability, maintenance,
etc.) but also the people aspects (for example, the attractiveness of positions, skills
management, etc.). Later, it will also be necessary to develop it, either by refreshing it

T HE P RO D U C T TE A M S W I LL DE V E LO P TO CR E AT E M ULT I PLE T E AM S , ACCORD I NG TO

FU NC TIO N A L ITY, W ITH IN T H E DE PART M E N TAL I SDS
Wo rking as clos ely as po ssib le w ith th e b u sin e ss f u n ctio n s to a d a p t to t he i r ne e d s
I nte grating D evs and Ops , a n d u sin g Ia C a n d C D, to d e live r n ew f u nct i o na l i ty mo re ra p i d l y
an d frequently

T HE C RE ATIO N O F A N IN T EG RAT I O N AN D SE RV I CE S M AN AG E M E NT LAYER

Drawing on IaC and C D co m p ete n ce ce nte rs m a d e u p o f th e te a m s i nvo l ve d i n t he fi rst
DevOps projects
Wh ich als o has res pons ib ility fo r ove ra ll co n siste n cy ( a rc h ite ctu re, s e c ur i ty, to o l s , etc. )

Si mple, modular, IN FRA ST RUCT UR E SE RV I CE S LI N E S a n d a u to m ate d o p e rat i o ns , « s e c ure d

by des ign»

Developing IN N OVATIO N AN D R& D CAPAB I LI T I E S to stay a h e a d of eve nt s and ma i nt ai n

cl o s e links to the bus iness f u n ctio n s

BU T A L SO, s ustainable inte g ratio n w ith tra d itio n a l o p e ratio n a l mo d e l s

48
 (with new technologies), or by transforming it completely (rewriting it piece-by-piece
using an Agile philosophy).

JOB

SKILLS NETWORK FEATURE TEAM FEATURE

FETAURE TEAM “LEGACY” PROJECTS CROSS-FUNCTIONAL

MOA MOE

UX Build/ Build/ Projects (SI & Process) HUMAN

Dev Dev RESOURCES
Product Product
owner owner
FRONT-END Project management & solution design
Ops Ops
Scrum Scrum
Master Master
OPS Archi Archi
Development and maintenance
SUPPLIER
Appli/ Appli/ MANAGEMENT
TMA TMA
ARCHITECTURE Architecture

Integration and services management Recipe

Idéation, sketch ,prototyting

ECONOMIC
S upport MANAGEMENT
Infrastructure Continuous COMMAND CENTER
Architecture
as Code Delivery

LAB METHOD AND

QUALITY
INFRASTRUCTURE
Lignes de services

IaaS PaaS Workplace Sécurité Legacy Ops tools PROJECT

LAB

PORTFOLIO
ARCHITECTURE

DEVELOPMENT
SERVICES
OPERATIONS CATALOGUE

HARDWARE LAYERS Feature Feature Feature Feature Feature

Teams Teams Teams Teams Teams

HÉBERGEMENT ET TÉLÉCOMS CONFORMITY

49
S U P P O RT I N G YO U R D E V S & O P S I N T H E I R any environment without additional
MODIFIED DISCIPLINES management costs. From now on, they will
be part of a complete continuous-delivery
The new organizational design necessarily chain, integrating build processes (in
affects the disciplines of operations and contrast to their previous ways of working)
development. It is not a matter of turning and the measurement of technical debt
Ops into Devs, or vice versa, but of helping (code quality), as well as automated unit
the two disciplines evolve toward new and user acceptance tests.
practices.
This moves them toward:
Ops will evolve towards the preparation
of reusable and automated infrastructure // a better understanding of produc-
elements. This will take place at the same tion and application-deployment
time as the Devs are upskilling to ensure models in order to «variabilize
the development of the deployment the application,» enabling it to be
scripts for each application, something deployed differently depending on
that will be done using the same tools the environment in question;
as the Devs.
// following an approach known as
Development skills, and the knowledge of «test-driven development,» to
the configuration management tools, are ensure a high level of quality, and
particularly important here. Ops already non-regression to be controlled.
has a culture of scripting. The challenge
for them will be to move from old-style //
practices - scripts that are not reusable,
rarely reviewed, and difficult to maintain
- to using uniform practices and tools
throughout the IT value chain.

Conversely, increasing the automation and

quality of the deployments will lead to a
reduction in the number of incidents and
change requests that Ops have had to
manage until this point.

For their part, Devs can no longer simply

produce the application code. They
will take account of the deployment
constraints of environments, design
application deployment models, and
allow application materials to be varied
- such that they can be deployed in

50
 CONCLUSION

While it is now imperative for companies You need to start now, progressively
to be more Agile and deploy applications adopting these practices, using a test and
more quickly, the DevOps practices that learn approach, and drawing inspiration
need to be put in place to do this will, from the practices of the internet Pure
nevertheless, have profound impacts on Players. This requires a change of mindset:
ISDs: with a need to focus on results; think
“product” rather than “project,” and take
// Transformation of the way an appli-
smaller, but more frequent, steps. This is
cation is designed by making it more
a profound change which will not happen
modular, and integrating infrastruc-
in the space of a few months, but it will
ture and operations into its code;
yield rapid results.
// The automation and «softwariza- And with “NoOps” still a distant target,
tion» of infrastructure, and the pro- there is all the more need to move quickly.
vision of infrastructure services, via This concept means that the developers
programmable interfaces contained themselves are responsible for running
directly in the code; applications, while Operations focuses on
automation (and end-to-end supervision).
// The evolution of the Ops discipline
This may seem like a utopian vision,
toward development and vice versa
but it is already a reality for giants like
(and therefore the need to recruit
Amazon, who have derived real benefits
differently, train people, and manage
by refocusing people on the added value
change).
they can offer.
// Different ways of working with the
business functions, through feature
teams that involve all stakeholders
and also modify the ISD’s organi-
zational structure and operational
model.

51
www.wavestone.com