DEVOPS

ADOPTION
Guiding Transformation
from Application to Enterprise
 ALIGN
ORGANIZATION

EMPOWER
LINE OF BUSINESS
AND IT DIVISIONS
ORGANIZE
APPLICATION CLUSTERS
AND PROGRAMS
OPTIMIZE
INDIVIDUAL APPLICATIONS
AND PROJECTS

EXECUTIVE
SUMMARY
The ultimate goal of DevOps is to unify devel- Most Accenture clients who find success with
opment and operations end to end, but many DevOps adoption use an approach spanning four
organizations struggle to realize the full adoption key layers of the organization structure, each with
journey from a single application to the enter- its own set of measurable practices that must be
prise level. Tactics and challenges vary at every synced and streamlined together.
stage; thus even the most promising efforts fail
to scale products and services through the entire • Optimize Individual Applications and Projects
scope of adoption. A comprehensive strategy is • Organize Application Clusters and Programs
critical to delivering sustainable business value • Empower Lines of Business (LoB) and IT Divisions
through DevOps. • Align the Organization

A DevOps journey is an
organization-wide journey
across all layers. Even if
your scope of DevOps
adoption is within one
single layer, you need to
sync it with other layers.

3
PURPOSE
AND AUDIENCE
This guide aims to help owners and stakeholders of DevOps adoption in each layer:

1. Understand each layer and its corresponding goals, challenges and recommendations.

2. Decide where to start and which recommendations to implement.

3. Plan and scale adoption across all layers.

LAYER AUDIENCE

Optimize Developers, Testers, Operators, Architects,

Applications/Projects Infrastructure Team

Organize Program Management and Release Management

Application Clusters/Programs Teams

Empower LoB/IT Division Leadership, Strategy and Change

LoBs/IT Divisions Management Teams

Align Top-Level Leadership, Strategy and Enterprise

The Organization Architecture Team

Definitions
When reading this document: “Application” refers to both applications and projects.“Cluster” refers to both clusters and programs.
“LoB” refers to both LoBs and IT Divisions.

4
 ALIGN
ORGANIZATION

EMPOWER
LINE OF BUSINESS
AND IT DIVISIONS
ORGANIZE
APPLICATION CLUSTERS
AND PROGRAMS
OPTIMIZE
INDIVIDUAL APPLICATIONS
AND PROJECTS

Figure 1 — DevOps Adoption Layers

ADOPTION
AT A GLANCE
OPTIMIZE ORGANIZE
APPLICATIONS APPLICATION CLUSTERS
Individual applications are the basis consideration A core tenant of DevOps is identifying dependen-
in every DevOps strategy. All other layers are cies among related applications and grouping
entirely dependent on solid DevOps implementa- them by release time and strategy. These group-
tion at this level; thus, stakeholders should keep ings are known as “clusters”. This allows for the har-
the broader adoption plan in mind when deciding monious implementation of DevOps to all applica-
which tools and practices to implement here. tions within a cluster, thereby promoting consistent
release speed and quality.

Organizations often overlook this critical step,

resulting in negative business impact. If DevOps
practices are not applied to every application
within a given cluster, the sluggish applications will
delay release of the entire cluster. This could result
in higher time-to-market for business functions
served by the those applications.

5
EMPOWER ALIGN
LOBS THE ORGANIZATION
Most large organizations are structured by LoBs. In today’s fast-changing ecosystem, IT helps drive
(For instance, Core Banking, Private Banking, Cor- business forward. Successful organizations need
porate Banking, Internal Functions, and Data and cutting-edge IT supported by an organizational
Warehouse may all be considered LoBs at a finan- culture that promotes innovation and agility. This
cial institution.) Each LoB is serviced by a number is where LoBs align with enterprise strategy and
of application clusters. governance to build a culture that fosters DevOps
adoption at every level.
LoBs often act as sub-organizations—it’s not
uncommon for each one to have its own IT team,
with independent objectives, strategies, roadmaps,
infrastructures, enterprise architectures, gover-
nance, tools, processes, etc. Applying DevOps uni-
formly among LoBs is as challenging as it is crucial
to the success of the overall adoption.

Let’s break it down

Aside from sharing a few common elements, each layer
in DevOps adoption has its own goals and practices.

GOAL
Embrace DevOps at the highest
organizational levels to drive business ALIGN
and stay competitive. ORGANIZATION
Adopt DevOps culture across
EMPOWER
LINE OF BUSINESS
subdivisions to improve quality,
speed and cost-effectiveness of
software development. AND IT DIVISIONS
Improve combined maturity ORGANIZE
and time-to-market of APPLICATION CLUSTERS
dependent applications.
AND PROGRAMS
Improve individual application OPTIMIZE
quality and time-to-market.
INDIVIDUAL APPLICATIONS
AND PROJECTS

6
 COMMON
PRACTICES CONSIDERATIONS
• Consolidate LoB governance • DevOps Transformation Alignment with Other
• Align DevOps with enterprise strategy and architecture Transformations e.g. Agile, Application Modernization

• DevOps Alignment with Infrastructure

• Governance (enabling standardization) Optimization e.g. Journey to Cloud
• Organizational structure
• DevOps-as-a-Service and Self-Service models
• Scalable multi-tenant platform • Cultural and Change Management

• Stakeholder and Vendor Management

• Identify clusters
• Create a consolidated release plan
• DevOps Analytics and Artificial Intelligence

• Select the right applications

• Devise an implementation plan
• Tool setup and process design
• Pilot for quick wins
• Continuous integration, delivery and more

7
COMMON
GROUND
CONSIDERATIONS THAT
CUT ACROSS EACH LAYER

8
The DevOps journey is not merely technical; it
also includes governance and metrics, tools and
technology, people and culture, and change
management. The following principles apply to almost
every layer of DevOps adoption.

ture setup and operations by automating practices

Transformation Alignment like provisioning/deprovisioning, scalability, moni-
toring, backup, and security provisioning through
Most organizations undergo several transforma- infrastructure-as-code techniques.
tions at various levels. Infusing DevOps into these
transformations can streamline and reduce the
overall implementation effort.
Cultural and
EXAMPLE Change Management
When an application is transitioning from Water-
fall to Agile, DevOps can augment the benefits of Studies show organizations that ignore cultural and
Agile through continuous integration and delivery. change management during a transformation jour-
DevOps principles can also inform resourcing ney fail to transform successfully. Like any other
decisions, e.g., structuring operations roles into transformation, DevOps adoption requires training,
scrum teams. mentorship, up-skilling/cross-skilling, behavioral
change, motivation/reward, sentiment analysis,
and assessment across all levels of the organiza-
tion. Cultural and change management experts
Alignment with should approach DevOps with a concrete roadmap
Infrastructure Optimization of implementation details, executional checkpoints
and feedback loops.
Bloated infrastructure drives up IT costs. DevOps
unlocks efficiency through both optimization and
modernization, i.e., considering how the organi-
zation might benefit from modern infrastructures,
such as cloud. These types of improvements
directly contribute to business competitiveness.

EXAMPLE
When an organization is undergoing cloud adop-
tion, DevOps can significantly enhance infrastruc-

9
Stakeholder and EXAMPLE
Vendor Management Adoption owners can find the root cause of a bot-
tleneck in software agility much faster among large
Most organizations have multiple stakeholders application portfolios using DevOps analytics.
and vendors managing various IT and business
functions (e.g., development or testing), but when Artificial intelligence also helps in making DevOps
vendors fail to collaborate cohesively, adoption ecosystems more intelligent by replicating aspects
tends to fail. Becoming an “owner of the adoption” of human behavior. Through pattern recognition,
is a success factor in scaling the DevOps trans- learning, logic and decision-making, artificial
formation. This requires commitment to change intelligence can facilitate DevOps practices and
and effective coordination of stakeholders, with a significantly improve adoption maturity.
strong show of support from senior leadership.
EXAMPLE
Organizations can automate the rectification of
software delivery issues as well as create systems
DevOps Analytics and that learn by themselves using only the input of
Artificial Intelligence sample data.

It is critical to continue implementing new technol-

ogies that bring added value to the adoption pro-
cess as it matures. Two such technologies include
DevOps analytics and artificial intelligence.

DevOps analytics turns data from DevOps tools

into insights that aid in decision-making. It also
gives stakeholders visibility into various DevOps
practices, helping them identify strengths and
opportunities for improvement across every aspect
of the adoption process.

10
STRATEGY
IN ACTION
A TACTICAL DEEP DIVE
INTO EACH LAYER

11
 High

LOW
I
J

MEDIUM
COST
C
F
D B

HIGH
H G
Low A
Low BENEFIT High

Figure 2 — Cost-Benefit Analysis of Sample Applications A–J

• Business and IT Priority Analysis – Outline busi-

Optimize Applications ness and IT priorities of each application under
consideration. The higher the priority, the earlier
Select the Right application should be slated for DevOps adop-
Applications tion, assuming the above analyses support the
same finding.
Some applications benefit more from DevOps than
others. Selecting and prioritizing the right ones Devise an Implementation Plan
can be tricky, especially in large organizations with
broad application portfolios. Typically performed After selecting your applications, proceed to
at the same time, the following assessments are assess each application’s current state of DevOps
helpful in culling down a shortlist. maturity across the following aspects:

• Cost-Benefit Analysis – Compare the tentative • Delivery Approach

cost of implementing DevOps with the potential • Release Management and Governance
benefit for each application. In the Figure 2, appli- • Build Management
cations A and G represent optimal targets, based • Continuous Integration
on this analysis. • Deployment and Platform Provisioning
• Continuous Delivery (including Quality Engineer-
• Application Characteristics Analysis – Fac- ing and Infrastructure)
tors like risk, complexity and time-to-market also
impact selection. Analyzing ROI for each char- Next, work with stakeholders to identify target ma-
acteristic in a given application helps to illustrate turity levels. The gap between current and target
the potential for improvement from DevOps as a levels will help you create a detailed implementa-
whole. Figure 3 suggests the “System of Engage- tion plan and schedule.
ment” application should be prioritized, as it stands
the gain the most.

12
 Degree of
Changes and Risk and Organization Potential
Engagement Requirement Opportunity Need for Team Cost of and Benefits for Priority of
System with for Time to for Collaboration Implementing Technology Adopting Implementing
Type Business Market Innovation /Co-location Changes Complexities DevOps/Agile DevOps

System of
Engagement

System of
Insight

System of
Processing

System
of Records

Figure 3 — Application Characteristics Analysis

Tool Setup and Process Design Continuous Integration,

Delivery and More
Tools and process should be established prior to
implementation. Following the “standardization at This is the heart of DevOps adoption. Your appli-
higher levels and industrialization at lower levels” cations are selected, your tools and processes are
model of governance, strategic decisions at the in place, and you created a promising pilot. Now
LoB and application cluster layers should drive it’s time to execute the following practices against
tool and process selection here. Setup should your implementation plan.
also be completed in tandem with other activities
in those layers. Continuous Integration
• Application Lifecycle Management
To ease standardization and scaling of DevOps • Project Collaboration
adoption, the tool set should be hosted in a central- • Software Configuration Management
ized DevOps platform, as opposed to each applica- • Peer Review
tion building its own. • Automated Code Analysis
• Automated Security Code Scanning
Pilot for Quick Wins • Automated Build/Packaging and
• Dependency Management
“Start small, prove right and then scale the trans-
formation quickly.” This philosophy aims to provide Continuous Delivery
early benefits and assurance to stakeholders before • Automated Deployments
they invest to fully scale the DevOps transformation. • Automated Functional and Non-Functional Testing
• Automated Test Data Management and Service
Make a small investment to pilot one of your select- Virtualization
ed applications with the goal of demonstrating ini- • Integrated Monitoring and Operations
tial DevOps improvements and benefits to others.
Then continue with other applications and further
layers of adoption.

13
Organize Create a Consolidated
Application Clusters Implementation Plan
Planning the consolidated release of an application
Identify Clusters cluster requires an assessment of the challenges at
hand as well as the techniques to overcome them.
All dependent applications should move through Understanding both strengths and opportunities for
development and testing cycles together at the improvement is a key part of this assessment, which
same pace, aiming for a consolidated release. should recommend an optimal release speed that is
Grouping related applications into clusters is the attainable by every application in the cluster.
first step to improving overall release speed. This
requires coordination, which can be difficult due The assessment and implementation plan should
to lack of leadership, circular dependencies, or respect all genuine caveats as well as issues that
disparities among stakeholders, vendors, geogra- are beyond the team’s control or those cannot be
phies, release plans and processes. improved within reasonable cost and time.
Once a cluster is established, DevOps should be  
applied to all or most applications within it. If not,
the non-DevOps applications will move slower than
others, delaying the target consolidated release
speed. In these cases, it can be beneficial to imple-
ment techniques like feature toggling and back-
ward compatibility in faster applications so as to
maintain speed while allowing slower applications
catch up when they are ready.

14
 ALIGN
ORGANIZATION

EMPOWER CENTRALIZED CoE FUNCTIONS DevOps OTHER IT

LINE OF BUSINESS CoE
AND BUSINESS
AND IT DIVISIONS FUNCTIONS ALIGNED TO LOWER LAYERS FUNCTIONS

ORGANIZE
APPLICATION CLUSTERS
AND PROGRAMS
OPTIMIZE
INDIVIDUAL APPLICATIONS
AND PROJECTS

Figure 4 — DevOps CoE Structure

Empower LoBs DevOps governance can also be combined with gov-

ernance of other ongoing transformation initiatives.
These practices help to scale adoption across
various LoBs. An organization cannot realize the Organizational Structure
benefits of DevOps until it has successfully scaled
and matured at all levels. Well-structured IT teams greatly enhance DevOps
adoption, but there is no single recommendation in
Standardization at Higher this area. Distinct LoBs often build structure differ-
ently while maintaining the ability to work together
Levels, Industrialization at efficiently. When devising new structures, it’s criti-
Lower Levels cal to respect the boundaries of other IT functions
and adhere to LoB guidelines.
Governance is one of the most critical success
factors in scaling a transformation. Lean gover-
A shared DevOps team (also called a “Center of
nance accelerates adoption by avoiding overhead
Excellence” or “CoE”) is a highly effective structural
and promoting faster decision-making. Using this
solution in most cases. A CoE is a virtual team of
model, DevOps standards are defined at the LoB
DevOps experts of varying experience and skill
level and systematically adopted at lower levels.
levels designed to aid adoption in lower layers. This
model relies on the DevOps principles of coopera-
Lean governance expedites adoption at lower
tion and collaboration.
levels with bureaucracy-free workpaths, light-
weight processes, regular checkpoints, continuous
CoE experts should be organized in two levels, as
monitoring, and a clear escalation and authority
shown in Figure 4.
hierarchy with key stakeholder involvement. This
type of governance is fueled by a strong manage-
1. Application and Cluster Level - These experts
rial commitment to adapt and fine-tune guidelines
have a dual agenda: The first is to implement
with speed, lead by example, and facilitate and
DevOps practices and accelerate adoption. The
authorize tools and processes at lower levels.
second is to train and mentor application teams to
become self-sufficient in DevOps methods.

15
DEVOPS-AS-A-SERVICE MODEL

Define and Estimate units Define and Publish and

build service of effort and associate begin serving
catalog complexity metrics/KPIs requests
for each for each
service service

FEEDBACK AND FINE TUNING

Figure 5 — DevOps Services Lifecycle

2. Centralized CoE Level – These experts are re- vices from a published catalog using the DevOps-
sponsible for defining DevOps practices, building as-a-Service model, where they can also track the
and maintaining a centralized platform, develop- status and quality of service delivery. Alternatively,
ing innovations, and executing pilots and proofs self-service may be a practical way to speed up
of concept. certain aspects of adoption at the ground level.
The catalog and other service features are typically
The CoE model requires a great degree of align- accessible through an online portal.
ment, communication and sharing of work be-
tween groups. It is also beneficial to rotate experts Sample DevOps Portal Features
regularly to help them gain experience and diver- • Service catalog
sify learning. This enables the CoE to improve both • Service status and tracking (using service met-
functions by leveraging the collective knowledge rics/KPIs/SLAs)
of the whole. • Self-service access
• Guidelines and best practices
A Scalable Multi-Tenant Platform • Training and resources

One of the primary services provided by the CoE is Figure 5 depicts the process by which a CoE would
the creation of a DevOps platform using the tools develop a service catalog, which offers the follow-
outlined by the governance structure. This platform ing information at minimum:
is used at lower levels to onboard applications and
facilitate DevOps practices. • Service name
• Description and full scope
Depending on the strategy defined by the gover- • Complexity level
nance team, this secure platform can be hosted on • Unit of effort consumed by the CoE in providing
premise or in the cloud, with continuous monitoring. said service
• Metrics/KPI/SLA associated with service
DevOps-as-a-Service and
Self-Service Models Building on this model, a CoE may also offer reus-
able DevOps artifacts through an App Store-like
CoEs become more sophisticated with scale. For interface, where consumers can download and use
instance, application teams can request CoE ser- various applications locally.

16
Align the Organization For example, if an organization’s strategy is to
become a digital organization within three years,
The intent to become a DevOps organization and it will likely undergo several transformation
the commitment required to do so lie at the high- programs across various LoBs at the same time.
est level of the pyramid. Here, it’s important to DevOps must align with these programs at every
streamline adoption by syncing LoBs with organi- level to accelerate them and reach its own maxi-
zational strategy and enterprise architecture. mum business potential.

 
Consolidated Governance
 
If multiple governance models are at play among
various LoBs, they should be consolidated at the
organizational level to facilitate DevOps adoption.
This is a key principle of “lean” governance, which
allows for more responsiveness and collaboration
among LoBs to promote reusability, collective
learning, thought leadership and measurability.

The DevOps Effect

DevOps adoption is a multidimensional journey
that affects many functions within an organiza-
tion. As such, it is critical to align DevOps with the
overall enterprise strategy in addition to business
and IT architecture. This enables measurement of
results against organizational objectives.

17
BOTTOM-UP OR
TOP-DOWN?
WHERE TO START
The answer is: Both.
Ideally, DevOps adoption should begin at higher
levels to foster the proper setup of standardized
governance structure, platforms, tools, processes
and guidelines—all of which are to be industrialized
at lower levels.

However, application teams should be empowered

to “just start with DevOps” at lower levels prior
to standardization, in the spirit of attaining quick
wins and pilots. They can implement basic DevOps
practices (e.g., SCM, Unit Test Automation, Build
Automation, etc.), knowing to expect minor
adjustments as platform, governance and CoEs are
formally established down the road. At that point,
higher levels become the driving force of DevOps
adoption across all layers.

In this way, an organization can start and scale (i.e.,

standardize and industrialize) DevOps adoption with
continuous learning.

18
LET US KNOW
WHAT YOU THINK
The content of this paper is based on the authors’
experience and understanding of organization’s
requirements, challenges and what has worked in
various projects.

Please reach out to the key contacts below if you

would like to provide any feedback or experiences
on the content of this paper.

Disclaimer
This paper contains generic advise for DevOps adoption in an organization, based on the experience of the authors, which may also
overlap the views/ideas of other DevOps practitioner in the industry shared in public domain. The organizations and individuals
should consider their respective ecosystem/landscape/requirements/scope and do the required due diligence before applying them.
Accenture or the authors are not responsible for the implementation or the outcome of DevOps adoption (advised in this paper) unless
consulted/engaged in the adoption.

The paper is the property of Accenture and its affiliates and Accenture be the holder of the copyright or any intellectual property
what-soever in the Paper. No part of this Presentation may be reproduced, distributed, copied in any manner without the written permis-
sion of Accenture. Opinions expressed herein are subject to change without notice.

19
AUTHORS
Manoj Seth
Global Lead of DevOps Solution Architecture

Manoj Seth is Global Lead of DevOps Solution Architecture in Accenture Technology

Services. In this role, he has been helping various industry clients in building and im-
plementing DevOps strategy for their transformational and modernization programs.
[email protected]

Vijeth Hegde
Lead of DevOps Accenture Technology Services

Vijeth Hegde is the Lead of DevOps within Accenture Technology Services-India. In

this leadership role, Vijeth focuses on the overall DevOps capability building, asset
creation, solutioning, consulting, architecture, new offerings, industrialize, training,
delivery and sales support.
[email protected]

Rajendra Prasad
Global Lead of DevOps, Agile, Automation and AI

Rajendra Prasad is the Global Lead of DevOps, Agile, Automation and Artificial Intelli-
gence in Accenture Technology Services. In this leadership role, Rajendra Prasad
focuses on driving efficiency in Application Services and IT operations for clients
across industry. He leads the team that created and currently deploys Accenture
myWizard®, an intelligent automation platform with artificial intelligence at its core and
integrated with DevOps/Agile tools/technologies.
[email protected]

CONTACTS
Federica Falcone
Global DevOps Lead
[email protected]

Marianne Breen – Hart

Global DevOps Strategy and Operations Lead
[email protected]

Copyright © 2018 Accenture

All rights reserved.
 
Accenture, its logo, and High Performance Delivered
trademarks of Accenture.

20