Dev Ops

DevOps Point of View
An Enterprise Architecture perspective
Amsterdam, 2020
Management summary
“It is not the strongest of the species that survive, nor the most intelligent, but the
one most responsive to change.”1
Setting the scene Goal of this Point of View
In the current world of IT and the development of This point of view aims to create awareness around the
IT-related products or services, companies from transformation towards the DevOps way of working, to
enterprise level to smaller sizes are starting to help gain understanding what DevOps is, why you need it
use the DevOps processes and methods as a part and what is needed to implement DevOps.
of their day-to-day organization process.
The goal is to reduce the time involved in all the An Enterprise Architecture perspective
software development phases, to achieve greater
Even though it is DevOps from an Enterprise Architecture
application stability and faster development
service line perspective, this material has been gathered
cycles.
from our experiences with customers, combined with
However not only on the technical side of the knowledge from subject matter experts and theory from
organization is DevOps changing the playing within and outside Deloitte.
field, also an organizational change that involves
merging development and operations teams is Targeted audience
required with an hint of cultural changes.
And last but not least the skillset of all people It is specifically for the people within Deloitte that want to
involved is changing. use this as an accelerator for conversations and proposals
& to get in contact with the people who have performed
these type of projects.
By all means, it is a deck that can be shared within
Deloitte and with our customers to provide a more holistic
1 Charles Darwin view.
© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 2

DevOps practitioners
For questions or remarks, feel free to reach out to our DevOps practitioners
Eric Onderdelinden Mark Maijs Donald Pondman

Director Senior Manager Manager
Enterprise Architecture Enterprise Architecture Enterprise Architecture
Deloitte Consulting Deloitte Consulting Deloitte Consulting
+31 6 83 33 98 16 +31 6 83 89 02 14 +31 6 83 33 02 56
[email protected] [email protected]
[email protected]
Balázs Nagy Boris Smits Marlies Quekel

Senior Consultant Consultant Analyst
Enterprise Architecture Enterprise Architecture Enterprise Architecture
+31 6 13 31 37 65 +31 6 82 67 44 36 +31 6 50 07 02 16
[email protected] [email protected] [email protected]

Contents
What is DevOps? 5
Why do I need DevOps? 9
Where is DevOps applicable? 12
What is needed for DevOps to work? 14

• People 16
• Process 24
• Technology 27
• Operating Model 33
How do I implement DevOps? 38
Deloitte Accelerators 42
Client Examples 46

What is DevOps?

What is DevOps?
DevOps is a new way-of-working that improves value delivery for the customer and
enables benefits for both development and operations
Definition Goal
DevOps is a new approach to optimize and DevOps primary goal is to improve the flow
manage end-to-end service delivery and from an idea towards value for the customer,
operations. It applies a set of principles to enabled by an environment in which
transform the entire software delivery lifecycle multidisciplinary teams work collaboratively to
to introduce new practices enabled by continuously deliver high quality solutions, in a
technology faster pace, that qualify for operations
New DevOps practices:

DevOps principles • Continuous Integration Benefits
• Continuous Testing
• Culture of shared responsibility • Increases the frequency and
and collaboration • Continuous Delivery quality of deployments and
• Continuous Operations releases
• End-to-end ownership of services
• Improves innovation and risk-
• Multi-disciplinary teams
taking
• Incremental value delivery
• Realizes faster time to market
• Flow optimization in the delivery Applying DevOps principles • Improves solution quality and
process
to the SDLC lead to new operational reliability
• Automate (almost) everything practices that benefit both • Improves the Mean Time to
• Measurement of everything Development and Operations Recover (MTTR)
• Continuous improvement

The History of DevOps
DevOps is becoming the norm in software delivery and is increasingly being adopted &
matured across enterprises, becoming the new best practice
The chronic conflict The grass roots movement DevOps State of DevOps
between Dev & Ops is takes off incorporated into report defines 5-
explored SAFe stage approach
DevOps expands upon the
2008 Based on personal experience 2010 practices of “infrastructure as 2015 SAFe is rapidly gaining 2018 From level 0 to 5, a
living in the world of Dev and code” and continuous integration traction in the enterprise descriptive, pragmatic
Ops, Patrick Debois from and deployment. DevOps principles arena, where DevOps is approach is introduced
Belgium starts investigating start being applied to the IT value adopted and scaled to guide teams and
the chronic conflict between stream. across. mature DevOps
Dev and Ops. initiatives, a report
sponsored by Deloitte
Pre-DevOps The “DevOps” term is “DevOps is the DevOps is the Enterprises embed
coined future” new norm for more IT functions
Pre- In IT, traditional high-performing in their teams next
2009 Andrew Shafer and Patrick 2011 March 2011, Gartner 2016 2019
2008 waterfall methods of companies to ‘Dev’ and ‘Ops’
application Debois meet at the predicts “By 2015
“Clearly, what was “organizations are
development were DevOpsDays 2009 and later DevOps will be adopted
state of-the-art three embedding security
losing ground to at Velocity conference, the by 20% of the Fortune
years ago is just not (DevSecOps), privacy,
iterative methods such term is picked up: 2000.”
good enough for policy, data (DataOps)
as agile. Speed “10+ Deploys a Day – a Most CIOs and IT today’s business and controls into their
became the goal, collaboration between Dev organizations are looking environment.” DevOps culture and
which took priority & Ops at Flickr” – Velocity, into doing work processes.”
p.18, 2016 State of
over development and 2009. differently.
DevOps Report Deloitte Tech Trends
deployment processes.
2019

DevOps practices
DevOps practices apply continuous automation cycles throughout software
development and operations processes
Continuous Integration Continuous Delivery
the streamlining of internal is the process of delivering

development by integrating code that is production
code into a shared ready and is kept in an
repository several times a always releasable state, so
day. Each check in is then it can be deployed
verified by an automated (automatically) to
build, allowing teams to production at any given
detect problems early in time based on business
the cycle needs
Continuous Testing Continuous Operations
automating and integrating is proactively managing the

tests into the software solution based on feedback
delivery chain, and loops. Monitoring and
automatically executing telemetry become part of
those tests against each the backlog. Processes
build of the code base such as patching also fall
under this practice

Why do I need DevOps?

Traditional function separation for Development and Operations
Prior to DevOps change release frequency was low, Development and Operations
worked separately to serve business demands, having completely opposite mindsets
Business
Request Demand
features Stability
Development Operations
Changes Features Safeguards Stability
1. Focusses solely on development activities 1. Focusses solely on operational activities
2. Operational requirements are unclear between 2. Operational requirements are unclear, needing
environments making the hand-over cumbersome ad-hoc changes to the environment
3. Operational feedback is only retrieved after 3. Operational understanding and experience is

completing a release gained only when the app is released
4. After releasing, developers are no longer 4. Operators manage and control software
involved written by others

DevOps unifies the mindset of Development and Operations
Today business wants to release on demand. With DevOps, both functions continuously
collaborate to align business demands within the software delivery lifecycle
Business
Request Demand
features Stability
Development Operations
Changes Features Safeguards Stability
End-to-end management and
The DevOps culture emphasizes
traceability of software
a common goal over the
delivery during development
whole value delivery chain
and issue solving
All members understand IT governance (e.g. security)

change, are responsible and is embedded within the
accountable as a whole, and software development best
trust each other to deliver practices
The DevOps technology Integrated software testing

embraces CI/CD to automate DevOps approach to validate code
the broken delivery funnel quality earlier in the process

Where is DevOps applicable?

Indicators for DevOps Applicability
Several indicators help to determine if DevOps is applicable for your organization
DevOps is DevOps is
Applicable Not Applicable
Management trusts delivery teams to work Management requires direct involvement in the
autonomously and only shares a product vision
Leadership style delivery process and makes all decisions
Multiple teams are responsible to manage the end- Product or service delivery does not require a multi
to-end lifecycle of a single product
Team composition disciplinary (cross-functional) team
Environments where IT solutions are changing Environments where IT solutions have low change
rapidly
Change rate rate
Your delivery process has many sequential

An incremental delivery process that focuses on
early value delivery
Delivery process constraints, where outputs equal required inputs for
consecutive process steps
Desired product end-state is unknown, changing

Desired product end-state is known and business
business requirements give guidance on steering Business uncertainty requirements do not often change
development
People have great affinity with software and People have no affinity for new technologies, and
technology and are not change averse
Change willingness are change averse
Products are tangible, typically consisting of semi-

Product is software that could be delivered as-a-
service
Product type finished products provisioned by multiple partners
that don’t have a direct relation with each other
Indicator

What is needed for DevOps to work?

DevOps dimensions
The DevOps operating model is structured along People, Process and Technology, each
dimension is necessary for successful DevOps
Process Technology
Establish standardized interconnected process in Improve toolset to support the delivery and
the software development (and operation) automation of the process specifically to
lifecycle accelerate software delivery activities
• Continuous Everything: integration, delivery, • Container based delivery and immutable
testing, monitoring, release management and infrastructure blocks
planning
• Leverage the vast DevOps tooling landscape to
• Continuous Integration and Continuous automate and support Continuous Integration
Delivery are key to build quality into DevOps and Continuous Delivery and minimize user
processes Operating intervention
• Establish interconnected processes across all Model • Support of dynamic environment configuration
phases of development and operations for to help remediate the current bottleneck in
consistent and predictable deployments testing environment availability
People
People
Establish a DevOps Organization & Culture with cross-functional teams that are
open and trustful Operating Model
• T-shaped employees • People, Process and Technology
• Foster continuous learning and development to build cross functional capabilities combined in a governance model for
and a mindset open to continuous change the DevOps way-of-working
• Transformational leadership & balanced metrics to drive DevOps culture • Teams deliver services end-to-end in
the DevOps Target Operating Model
• Open and transparent communication enable feedback and short learning cycles

People

DevOps Organization & Culture
The principles of the DevOps way-of-working have extensive implications on the
organization structure, as well as on the culture of the workforce
DevOps principle Implication for Organization & Culture
Culture of shared Teams are accountable for progress and output, not an individual team member. Team setup is persistent and co-
responsibility and collaboration located to improve collaboration and performance.
End-to-end ownership of Team resources are allocated by services instead of organizational functions. Teams take end-to-end accountability
services and responsibility (vertically integrated) for the delivery of a service.
Teams are setup vertically, end-to-end responsible for the whole lifecycle of a product. It contains balanced T-
Multi-disciplinary teams
shaped skilled personnel from various domains (cross-functional) to achieve its targets.
Work is broken down into small pieces to continuously deliver value to the business using iterative and frequent
Incremental value delivery
releases.
Flow optimization in the Elimination of waste, shift left and limit work in progress optimizes the flow in the delivery process. Teams test as
delivery process early and as often as possible, minimize handoffs and maximize checkpoints to reduce dependencies and risks.
Tools automate as many tasks and process steps as possible in the delivery process to drastically reduce time,
Automate (almost) everything
effort, and risk of human errors.
Everything is monitored and measured by a balanced metric system focused on the speed and stability of service
Measurement of everything
delivery.
Teams organize retrospectives, (automated) feedback loops, and touchpoints with the business in order to
Continuous improvement
continuously improve their delivery and way-of-working.

DevOps principles are the starting point for an organization structure
Based on DevOps principles, an organization allocates resources by service instead of
functions to enable end-to-end ownership and increase agility within teams
Product/Service multi- Service A Service B Tech Lead is a product team
DevOps principles disciplinary team(s) are aligned to member with extensive technical
a particular service development experience who can
Culture of shared lead the Product Team in the
responsibility and collaboration PO TL PO TL execution of its work
Product Owner a fixed business
resource empowered to shape and Functional
End-to-end ownership of services CoPs
Functional Communities of
direct the development of a DevOps DevOps Practices are the knowledge
product in a way that maximizes team 1 team 1
sharing and communication glue
business value
Multi-disciplinary teams Functional that keeps functional expertise
CoPs (e.g. QA, development, testing
DevOps DevOps
team 2 team 2 etc.) together
Incremental value delivery Cross Functional DevOps team
is a long-standing, fully-allocated,
Functional
cross functional team that is end- CoPs
Flow optimization in the delivery to-end responsible for (a module DevOps
team 3
process of) the delivered product
Solutions Solutions
Architect Architect Solution Architect is a product
Automate (almost) everything team member who governs
architecture, design and
Common Core services are Common Core services implementation while enforcing
Measurement of everything shared services provided, architecture standards and
Shared functions
preferably through self-service (e.g. Service Desk) guidelines
portals, by teams of the
Continuous improvement technology organization to be
used by the different DevOps Infrastructure functions
teams

Key DevOps roles and responsibilities
Several key roles should be represented in a cross functional DevOps team; a team
member with a T-shaped profile can fulfill more than one role
The DevOps Engineer writes and
Service A Service B verifies code, fixes bugs, executes
patch management, maintains
asset and configuration repository
The Business Analyst and functions as 2nd line support The Test Engineer creates and
engages the business for executes test scripts, automates
PO TL PO TL
requirements, helps defining tests, supports usability testing &
Functional features, user stories & test UAT, and manages test
CoPs cases, and validates designs environments and test data
DevOps DevOps
team 1 team 1
Functional
CoPs
DevOps DevOps
team 2 team 2
Functional
DevOps CoPs
team 3
Solutions
Architect
Solutions
Architect DevOps Team
The Infrastructure Engineer* The Operations Specialist executes
Common Core services configures, maintains and monitors the day-to-day technology operations
provisioned infrastructure that is hosting (functional maintenance), monitors
Shared functions
(e.g. Service Desk)
the application (full-stack responsibility) technology operations, performs
Problem Management, manages
The Scrum Master facilitates the change processes (Approves/Rejects)
team on processes & approach,
Infrastructure functions*
manages impediments and
*The scope of infrastructure engineer role depends on enables continuous improvement
the maturity of the shared infrastructure function.

Different team topologies
No one-size-fits-all approach, DevOps can be implemented in many different
organizational and team setups
DevOps setup Team topology When to use? DevOps setup Team topology When to use?
1 DevOps team with an expiry As an organizational 5 Ops as infrastructure-as-a- Traditional

date pilot or hybrid state service organizations with
for organizations several products or
Temporarily setup DevOps team Infrastructure operations are
aiming to adopt services in which the
as separate entity to existing fully covered in the self-service
DevOps Ops teams provides
Dev and Ops Teams model consumed by the DevOps
IaaS
team
2 Dev and Ops collaboration To move away from an 6 DevOps Evangelists Team When the organization
“us vs them” mindset. is reluctant to change,
Enables collaboration and co- Team setup facilitates
(NB: the extent of this setup could be
creation between Dev and Ops communication between Dev and
overlap depends used to slowly
through a common vision and Ops teams while keeping the
mainly on organization transitions towards a
shared responsibilities majority of the existing team
size and resource DevOps organization
setup
resources)
3 Fully shared Ops Works best for 7 Separated responsibilities for When organizations
responsibilities organizations with a regulated industries report to external
single main product or supervisory bodies to
Fully integrated DevOps team Separate responsibility for Dev
service comply with industry
with shared goal and and Ops on the DevOps team in
regulations
responsibilities order to provide an auditable
trail
4 DevOps as an external Organizations with

service limited operational
issues, DevOps team
DevOps team supporting smaller
focusses on
Dev teams
supporting dev teams
in the problem
domains
© 2020 Deloitte The Netherlands Development team DevOps team Operations team Deloitte DevOps Point of View 20
T-shaped profiles
Ideally, DevOps team members have a T-shaped profile, teams have a combination of
different profiles covering all knowledge and skills areas
Knowledge Areas* Skills Areas*
Why we advise T-shaped profiles
Security, Risk &

Business Value
Architecture &
Infrastructure
Programming
Teambuilding
improvement
Optimization
Specification
Engineering
Compliance
Continuous
Continuous
Leadership
A T-shaped profile entails that a team member covers
Business
Courage
Delivery
Analysis
DevOps
Design
Test
different knowledge areas and skills in varying levels
of expertise.
A team with T-shaped profiles does not have a

1
hierarchy since everyone’s skills and knowledge
complement each other.
2 A lack of hierarchy brings a team closer together and

creates a sense of shared ownership.
Level
3
Level
Level
1 —1Novice
— Novice Level 2 — Competent Level 3 — Proficient Level 4 — Expert Level 5 — Master
Strict obedience to rules, no Still limited with situational Sets priorities, actions are seen Perceives deviations from the Has a wealth of experience,
experience, little situational perception, knows the aspect partly in longer term goals, normal patterns, makes decisions creative solutions and visions,
perception, no discretionary guidelines and treats all attributes deliberate planning, standardized more easily, assesses situations as breaks the rules when needed,
judgement and aspects separately, yet equally procedures part of the “big picture” uses analytic approaches
sparingly, makes good decisions
quickly yet professionally
*DevOps Agile Skills Association (DASA)

The mindset of a DevOps team member
DevOps team members foster certain cultural aspects contributing to the end-to-end
ownership of services
A mindset of effectiveness Inspirational and fun environment
We continuously improve our delivery to improve our An environment in which people perform at best,
effectiveness. We define effectiveness as our ability to adapt where they feel inspired, where they want to be,
to “market” circumstances and the success (value) of the feel welcomed and are encouraged to think out of
product features delivered. Note that this also includes the the box
effectiveness of activities, such as backlog prioritization
Continuous learning &

A mindset of taking responsibility Continuous improvement
All members of our team are responsible for the We have the desire to explore and learn in all
complete product, which includes the full activities we do. We strongly believe that working
delivery cycle as well as operating/providing together, transparency, and sharing knowledge is
customer support throughout the lifecycle of the vital. We care about our job enough to not pass the
product in a collaborative mindset buck, we want to learn all the parts as a whole and
not just our little world
An engineering mindset
We have the desire to utilize our knowledge,
skills, and creativity to solve problems, implement Experimentation & Risk taking
product features, and optimize our delivery We always conduct experimentation using solid
process. We do not settle for the current status methodologies to ensure ideas are evaluated on
quo. We strive to improve our craftsmanship the real value instead of the assumed value
Build quality in
Quality is built-in from the initiation of the
A mindset of product thinking
teams up to discharge. It is at the heart of Our application is our product. It must deliver
every activity. It is never compromised. We value when it runs in production. We need
value full transparency continuous improvements to ensure the
application delivers value now and in the future

Factors influencing DevOps organization design
DevOps theory doesn’t always apply to practice, client specific factors need to be
taken into account for an applicable and effective DevOps organization design
DevOps organization design is client specific
Existing Setting up DevOps teams or an entire DevOps
Regulatory
organizational
Requirements
Structure organization requires understanding of existing, but also
future organizational structures.
Client specific factors might increase the complexity and

Process & effort that is required to transform towards a DevOps
technology Archi-
hetero- tecture organization.
geneity
Client specific factors to be There is no “one-size-fits-all” DevOps organization
taken into account for an design. Client specific factors must be taken into
DevOps organization design account.
Example considerations for an effective “to-be” DevOps

Business Resource
organization design are:
Needs Capacity
• Keeping some functional hierarchy intact to
facilitate collaboration with the enterprise
• Re-architecting the technology stack to enable
Product Sourcing DevOps practices
Varieties Model
• Adhering to some degree of separation of duties to
comply with regulations

Process

The DevOps model is significantly different from the traditional IT model
DevOps integrates the application lifecycle into an end-to-end, iterative process
Traditional IT Model Implications

▪ Straightforward sequential process
assuming all is known
App
Dev
Define Design Develop

▪ Big chunks of work
▪ Maximizes each process-step, big-
bang delivery
Infra &
▪ Many separated functions (silos)

Ops
Release & with (manual) handoffs

Test Operate Retire
Deploy
▪ Specialization (I-shaped roles)
▪ Rigid change ability
Target State DevOps Model Implications

▪ Complex iterative process to
manage unknowns
▪ Small chunks of work
DevOps
model
▪ Maximizes flow, incremental delivery

Continuous Continuous Continuous Continuous
Plan Retire
Integration Testing Delivery Operations ▪ Fewer handoffs (less silos)
▪ Generalists (T-shaped roles)
▪ More flexible to adapt to change
Continuous Improvement

DevOps leverages technologies to automate the software delivery process
While extending agile, DevOps optimizes the software delivery process by leveraging
CI/CD which automatically promotes developer’s source code to operational solutions
Agile Development DevOps
Software
Delivery
Process Ideation
Requirement & Source & Build & Release &
Operate Monitor
Design Develop Test Deploy

DevOps extends the Agile Integration Testing Delivery Operations
DevOps process and puts emphasis … its practices focus on bridging the stage gate gaps between phases to
Practices on the software delivery cycle accelerate throughput by promoting more frequently with smaller products…
and operations…
… next to this, DevOps practices incorporate feedback loops continuously in
the process for value creation and learning by experience
CI/CD pipelines integrate process into technology
Automates almost everything - Automation drastically reduces time, effort, and risk of human errors
The
Done means released - Deliver releases for pre-deployment or deploy new releases to productions in minutes instead of months
CI/CD
Pipeline
Everything in Version Control - Versioning ensures that no work gets overwritten and that the latest versions are built upon
Builds Quality Into the Process – The quality of every deliverable is guaranteed errors and problems are detected early

Technology

A legion of tools are available to support DevOps practices
As DevOps is a tool intensive practice, a thorough tool selection incorporating client
maturity is a crucial part of the DevOps transformation
DevOps is a tool intensive practice

The voluminous amount of tools available, delivering one or
multiple capabilities brings consequences when transforming
towards a DevOps organization
• Selecting the right tools requires an iterative approach

(a procedure per capability)
• Selection is, among others, based on engineering
skills, prior experience, or tools (architecture) already
in place
XebiaLabs published A sample selection of DevOps tools categorized in capabilities

Source: https://xebialabs.com/periodic-table-of-devops-tools/
Patterns to setup a CI/CD pipeline
Selecting the right set of tools (Best-of-Suite, Best-of-Breed or hybrid) for the CI/CD
pipeline depends heavily on IT maturity and tech-savviness of the organization
Applicability of the toolset Best-of-Breed
“Selecting the best product of its kind”
Hybrid Advantages
“Best of both worlds”
• Flexibility – you are not depending on a
Best-of-Suite one-size-fits-all solution1
“Bundle of end-to-end enterprise Advantages
• Independent – you can pick and choose
software applications”
• Quality cascade – new capabilities regardless of the core
iterate upon the current solution
setup and consider best
Advantages Disadvantages option available Disadvantages
IT Maturity
• Control – one central • Standard solution – Often a Disadvantages • Maintenance – requires knowledge of the
place to manage users, bit more rigid than best-of- setup of each, and dependencies between
applications etc. breed solutions, offering • Effort to determine applications
less room for specialization concurrent tools – The
• User experience – one hybrid approach • Vendor segregation – issue solving might
similar user interface • Partner dependency – The considered a thorough cover multiple vendors with different
for the pipeline performance and reconsideration for support models
development of the features every requirement
• One integrated depend on a single provider
platform to process the between Best of Breed
pipeline from • Integration focus – New and Suite
features have the objective
to integrate with the core
instead of being the best of
its kind
Tech-savviness

A basic functional flow through a CI/CD pipeline
A CI/CD Pipeline can be build in various ways considering the desired tooling patterns,
covering the same functional flow with different tools and integrations between them
Source & Develop Build & Test Release & Deploy Operate & Monitor
Distributed source code repository and Build and test automation process the Central repository manages and Monitoring the performance of the team
version control system manages code application code based on the latest versions the released application in the software delivery process using
changes during software development changes in the source code repository artifacts and dependencies DevOps metrics and KPIs
Source Code Repository Code Build and

Artifact Repository Software Delivery Process
and Version Control Automated Testing
Agile Planning and Test Strategy, Execution

Automated Deployment Software Operations
Collaboration and Reporting
Collaboration environment supports Test repository manages test Deployment automation deploys the Monitoring of the deployed system’s
the delivery process and planning of strategies, test cases, test execution released application artifacts and health & performance using application
the DevOps Teams and reporting of test results dependencies to target environments and infrastructure monitors
Best-of-Suite Hybrid Best-of-Breed
Azure DevOps covers the full extent of the CI/CD Only a few interfaces are required as Atlassian’s The pipeline orchestrator (Jenkins) becomes the
pipeline, with no external integration required suite covers the majority of required functionality central component to integrate all applications
Same suite, no interface

Interface between tools/suites
DevOps and Cloud go hand-in-hand
The DevOps way-of-working makes instrumental use of cloud automation. However,
DevOps practices can also be applied in hybrid or on-premise environments
DevOps is accelerated using automation principles that are applied in the

Cloud. DevOps methods and tools require a platform that is able to change
quickly. Due to the agile and self-service nature of cloud, DevOps teams can
collaborate on a single platform, in which they can source & develop, test
and deploy new functionalities without the burden of underlying
infrastructure.
Cloud

Hybrid
Integration Testing Delivery Operations
On-premise Solution
On-premise environments increases the scope of the DevOps teams.

Fortunately, DevOps practices are not environment specific and the DevOps
teams can add team members with skills required to develop and operate
the on-premise infrastructure.

Operating Model

DevOps Target Operating Model (TOM)
The DevOps TOM aims to land the DevOps way-of-working in the organization by
describing the DevOps practices using Deloitte’s framework ‘Technology TOM in a box’
The Technology TOM in a box is an holistic framework to

Technology TOM in a box describe the governance structure of an technology
organization and how it functions as an entity
The capabilities of the DevOps practices will be described

DevOps practices
through the dimensions of the Technology TOM in a box
DevOps The DevOps Target Operating Model (TOM) outlines the

governance structures on how an organization should govern
TOM
and operate the DevOps practices

Governance through a DevOps TOM
We use the DevOps TOM to explain to a client how it should Organize, Execute and
Behave in a DevOps world
DevOps TOM The Technology TOM describes a number of inter-related dimensions that reflect how
Using a number of inter-related dimensions we a Technology organization is Organized, how it Executes and how it Behaves
explained to the client:
What
Personas Services Mission
1. What services the organization is going to
deliver, and to whom
Capabilities Metrics &
Processes
& Skills KPI’s
How
2. How these services are delivered using
DevOps capabilities, processes and CI/CD Funding &
Charging
Functions &
Interactions
Tooling
tooling
Where
Sourcing & Collaboration Culture /
3. Where these DevOps capabilities are sourced Ecosystems & Location work style
from, what the ecosystem looks like, and how
to collaborate in a DevOps culture
Organization Governance Incentives &
Structure & Mandate Rewards
Who
4. Who are responsible for service delivery and
Roles & Res-
support using DevOps roles and organization ponsibilities
structure
Dimension category: Organization Execution Behavior
© 2020 Deloitte The Netherlands 34

Detailing the DevOps practices
The DevOps TOM describes capabilities that are part of the DevOps practices
Organization
Execution
Behavior Integration Testing Delivery Operations
Test Automation Telemetry & Logging
Test Environments & Data Metrics / Dashboards
Bug Reporting & Defect Management Self-Service Portals
Data Security Incident Response

System Architecture Release Orchestration
DevOps
Development Practices Deployment Automation
capabilities
(non-exhaustive) Development Environments Configuration & Asset Management
Source Code & Version Control Environment Management
Automated Code Build Infrastructure automation
CI/CD Metrics and Tracking

DevOps operating model differentiators
The DevOps way-of-working has several implications on the operating model that
differentiates from traditional operations
Differentiators of the DevOps TOM
Organize Execute Behave
Impact: Impact: Impact:

• Service Oriented Organization: • Redefined Roles & • Structured Vision: Vision adapted to
Resources organized around services, Responsibilities: Redefined changing business needs of the
focused on delivering designated managerial roles, integrated within business and customers
business outcomes self-organizing scrum teams
• Collaborative Services &
• Organize the People: Creating high • Iterative and Frequent Releases: Capabilities: Increase in usage of
performing teams working focusing on Introduction of DevOps practices for collaborative services and capabilities
a common goal iterative and frequent releases to the support business expectation
• Venture-Capital style Budgeting: • Speed Up the Work: Providing tools • Visibility and Transparency:
Funding dependent on minimal viable and automating processes to minimize Greater visibility and transparency
product, and its performance handoffs and maximizes checkpoints across the firm with merging of
to reduce dependencies and risk development and support functions
• Organize the Work: Slicing the work
and capabilities
into smaller chunks that add value to • Improved Interaction: Siloes
customers immediately and then broken down between and within the • Cross functional Team: Resources
investing in it business units and IT organization formed from Run, Change, Design,
and Test, to focus on specific product
• Sourcing Model: Sourcing model
or service which needs to be delivered
aligned to need of firm based on
to customer or business
additional capabilities and delivery
methodologies introduced
Source: Deloitte Technology TOM in a box

How do I implement DevOps?

Option 1: Standard Deloitte transformation approach
The DevOps transformation journey across a large organization takes 2-3 years, but
starts with a clear Alignment & Vision created in 8-10 weeks
Scale and Speed

Pilot Adopt
Alignment Vision
Do we have a Do we have Have we rolled Are we

holistic view of clarity on Do we have a sense of what “good” is out new getting full
issues and target state like? capabilities to benefits of
options? and roadmap? key areas? DevOps?
Alignment/Vision Pilot MVP/Targeted Assistance Adopt/Implementation

Help articulate the vision, execution Select a pilot to build a MVP with a CI/CD Establish Nerve Center/Center of
plan and funding requirements in a pipeline to establish a model for rapidly Excellence for scaling DevOps capability.
short sprint. identifying and launching projects to
propagate DevOps thinking into practice Typically done in a Build Operate Transfer
Deloitte team leads with sponsorship quickly across organization. (BOT) model.
and co-leadership from client team.
Deloitte acts as facilitator and starts the
transition as the client takes on a more
coaching/managing role.
8-10 weeks 8-12 weeks 18-24 months

Option 2: Co-created transformation
A future vision stays the basis for the DevOps TOM, but for delivery we can shift
towards a bottom-up approach and co-create change iteratively with the client
Phase
Alignment / Vision Co-created transformation Adopt / Scale

Implement Improve
Iteration
Define
What
Operating Model
What What
dimension(s)
How How How
Where Where Where
Who Who Who
Imagine the future of services in the Co-create the DevOps Operating Model iteratively using Scale the DevOps Operating Model and
service organization (dot on the a combined Deloitte client project team: technology within the client organization
horizon): depending on the transformation need.
• Each iteration defines and implements a prioritized set
• What is the mission of service of DevOps capabilities based on the delivery of CI/CD Establish Nerve Center/Center of
organization? pipeline technology Excellence for scaling DevOps capability.
• What IT services, and to whom, is the • Scope is determined prior to each sprint based on:
service organization going to deliver? 1. Actual CI/CD pipeline technology delivered
2. Relevant Technology TOM in a box dimensions
• Collaboration with the client:
1. Full support and dedication of DevOps champions
(dedicated client project team members)
2. 2-wk alignment with internal client stakeholders

What are the challenges of implementing DevOps?
DevOps majorly challenges skills of everyone involved: management and team. It may
lead to development slowdown and will not compensate for lack of responsibility
1. Skill Challenge: Keeping pace with the required skills may challenge your team
2. Scarce talent: Some special skills in your organization can’t be replicated for every DevOps team
3. No magic: DevOps will not compensate for potential lack of responsibility in your organization
4. Lack of Overview: Progress and stability are spread across the teams and overview may lack
5. Dev Slowdown: Operations may hamper progress in development
6. Self-organization Challenge: Clear Service-Level Structures in operations may be challenging
7. Management Challenge: DevOps can mean management challenges for your team leads

Key Lessons Learned
During our engagements we gathered the following key takeaways that we will bring
to future projects
People You cannot “buy DevOps” Management support is crucial Break down silos Assign champions from client
DevOps adoption cannot be bought and Management involvement is crucial in Break down silos. Not only between Ensuring the support of the client can
“bolted on” the existing organization. It the DevOps transformation, as change departments, but also between be accelerated by having a champion
requires a cultural shift around how starts and stops with them organizations from their side spreading the DevOps
people deliver their work culture and principles
Process Consider secondary impacts Collaboration is key DevOps ≠ Agile Focus on E2E responsibility
Product roadmaps will be impacted and DevOps requires close collaboration DevOps can be seen as an extension of Limit handovers as much as possible,
delivery bottlenecks reduced. New across dev, test, operations and Agile, with the same level of agility teams must adopt an end-to-end
budget to build a DevOps organization business teams to effectively deliver driven into development, test and responsibility for the product or service
will be needed value to the organization operations they deliver
Technology Modern architecture is critical Show value quickly DevOps ≠ Automation Use Cloud as an accelerator
Platforms built on modern architectures ‘Prove’ the DevOps concept by Release and Deployment Automation or Ensure parity between cloud and on-
based on modular design, decoupling demonstrating working solutions early App Release Automation are only a part premise implementations (e.g. Azure
and good componentization enables and often (e.g. CI/CD tooling) of DevOps. End-to-end automation is DevOps)
deeper adoption of DevOps key
Operating DevOps journey is client

Collaborate with Tech Stream Change incrementally DevOps ≠ Organization
Model specific
Design the DevOps operating model in Apply an agile approach for adopting There are different organizational DevOps target operating model
parallel and close collaboration with the DevOps and introduce change patterns to setting up DevOps and it transformation depends heavily on
technology implementation incrementally with focus on the doesn’t always have to be making it a where the client is in their DevOps
outcomes separate organization journey

Deloitte Accelerators

Deloitte DevOps Maturity Assessment Offerings
To understand the current state DevOps capabilities and to identify areas for
improvement, we have two assessment methodologies available.
Deloitte’s DevOps Maturity Assessment (DDMA) is an extensive

What is
DORA provides a SaaS questionnaire that benchmarks DevOps questionnaire for assessing current state against desired future state
it?
performance against 2000+ leading Enterprises across industries maturity of DevOps capabilities across the DevOps domains: from
Release Planning to Continuous Deployment and Monitoring.
▪ “Gold standard” for DevOps assessments ▪ 180 questions along each of the DevOps domains (Release
Planning, Continuous Development, Continuous Integration,
Benefits
▪ Compare your results against others in industry Continuous Testing, Continuous Deployment, Continuous
▪ Two assessments included – one to baseline and one to measure Monitoring)
progress ▪ Assesses maturity against desired future state
▪ Provides priorities for capability improvement ▪ Identifies areas for capability improvement
Cost
Deloitte receives a 30% discount from DORA; will be an additional

Included in price of DevOps KickStart or DevOps Dojo
cost on top of pilots
Sample Output
Industry Capability Release Planning Continuous Integration

Benchmark Prioritization Maturity Maturity

Deloitte Global Accelerators
Our Global DevOps Community of Practice has a wide variety of accelerators available
that we can use in our engagements
Learning Sales Materials Tools and Enablers Eminence and Point of Views
Learning Series Proposal templates & DevOps DevOps Local toolkit Eminence
brochures
Basic introduction course An integrated toolkit of local Examples of Deloitte DevOps
to various DevOps practices Templates & brochure to help you DevOps tools to gain hands-on materials published in popular
kickstart your DevOps proposal experiences media
Learning Resources DevOps Qualifications Deloitte supplied tools DevOps Point of Views (PoV)
A collection of documents to assist ‘Quals’ to help you display Tools that can be supplied for • Cloud platforms
learning DevOps and specific Deloitte’s capability to deliver client engagements:
• Collaboration tools
elements or specific vendors DevOps transformations, including • Agile Manager
• HP Application Lifecycle Management
tooling • Fortify
• Development suite tools
• JRebel
• Performance Center
• Software Build tools
• SonarQube
• Unified Functional Testing and UFT Pro
• Software Deployment tools
• Container persistence
Videos & Demos DevOps Case studies Enablers
• DevSecOps
A collection of videos and demos Case studies of client Enabling materials for specific
regarding Deloitte methodologies engagements, with success stories vendors, industries, such as the
and instructions for DevOps and demos. The Client demo can Cloud Compass, PoC for SAP or
tooling showcase DevOps automation Google Cloud enablers, Cards for
capabilities Agility, Technology TOM in a Box
Note: non-exhaustive, Global examples, which may be updated continuously

Client example 1
DevOps journey and CI/CD
pipeline implementation

Client example 1: Global parcel delivery services company
We took our client on a DevOps transformation journey across all five dimensions to
streamline the software delivery lifecycle of their mission critical system
Process Technology
Develop a chain of full end-to-end From requirements, to tool selection, architecture
processes to facilitate the DevOps way-of- design and full implementation; we built a CI/CD
working and continuous software delivery pipeline base on MS Azure DevOps to enable
• Described CI/CD processes to operate continuous integration and continuous delivery
the pipeline through all DevOps • Automated as much as possible, while
practices maintaining stage gates for deploying to
• Implemented continuous feedback mission critical environments
loops into process flows to facilitate • Supported persistent configuration
continuous improvement management to deliver tailored software to
• Defined and implemented auxiliary distributed, distinct production systems
processes to support and smoothen the
execution of the DevOps lifecycle Operating Model
Designed and implemented a
governance structure to
successfully have business-
Organization & Culture and value-driven DevOps
teams that take full ownership
Designed and implemented a fully fledged of their product/service,
DevOps organization, along with teams including:
covering the full lifecycle of services, as well Data
as defining a culture to facilitate • Tailored DevOps Target
Obtain as much insight, by logging all data
collaboration, knowledge sharing and Operating Model
and monitoring relevant metrics, by
continuous improvement employing DataOps
• T-shaped role descriptions for team • Gather data from CI/CD process
members • Infrastructure logging & monitoring of
• Described ways-of-working to enhance develop, test and production environments
visibility and feedback • Operational data logging, monitoring and
• Defined a culture based on CALMR analytics on operational process execution
principles, with accompanying metrics to • Provide dashboards to view and report on
enhance adoption performance

Client example 2
A CI/CD Pipeline for a Banking
Platform

Client example 2: CI/CD pipeline
Deloitte developed an Open Banking Platform as a global asset with an CI/CD pipeline
to ensures continuous integration and deployment
| Build & Deployment Security &

Quality Control
Local Unit tests, static code

Development Code Repository (GIT) checks, code smells Repository Management
Secure coding Security checks & Check if the repositories

Code review &
guidelines & Source code used are whitelisted (only
Security checks
Training approved software)
validation Controlled deployment to
production & testing
environment based on
agreed release candidate
Microservice is packaged in Docker Amazon ECR handles the Container is deployed

container and published to container container registry to the platform
registry Manual approval
An image scan is performed to Validation of security
detect known vulnerabilities baseline
Image is hardened and
checked if in accordance
with security baseline Secrets Management Container is immutable
Fuzz testing, Pentesting &
Vulnerability scans

Client Example 3
Test Automation for a Banking
Application

Client example 3: Automating End-to-End Testing
We helped our customer to setup their testing capability, a vital but time-consuming
part of the software delivery process
Customer aims to speed up release and ensure software

S OFTWARE V ENDORS quality through UI-based E2E Integration and Acceptance
testing with the Selenium Framework
Requirement & Build & Test & Operate &

Ideation Develop Release
Design Deploy Acceptance Monitor
C USTOMER C USTOMER
Test Phase System Integration E2E Acceptance PAT
• System tests • Deployment tests • Deployment tests • Non-functional tests

• Bug testing • Performance
• Integration tests based on • Business Acceptance
Type of tests • Unit testing • Security
user stories Regression tests (E2E)
• Disaster Recovery
• Deployment tests
• Regression tests (E2E)
• Prepare for go-live execution

Client example 3: Automating End-to-End Testing
Using a test automation framework based on Selenium, Deloitte delivered a total of 15
automated end-to-end test cases
Requirement & Build & Test & Operate &
Ideation Develop Release
Design Deploy Acceptance Monitor
CI/CD Automation Server
Develop Build Run
Behavior-Driven Build Automation Tool Web Browser Automation

Development Framework
Given I navigate to “Deloitte.com”
And I click “About Deloitte” Trigger test run based on
Then I should see title “About us” • Time
• Code commit
• JIRA update

Recommended resources
In case you got excited and would like to learn more…
Books:
• The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations
− by Gene Kim, John Willis, Patrick Debois, Jez Humble
• The Phoenix Project

− by Gene Kim, Kevin Behr, George Spafford
• Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
− by Jez Humble and David Farley
• Accelerate: Building and Scaling High Performing Technology Organizations

− by Nicole Forsgren, Jez Humble, Gene Kim
Websites:
• https://notafactoryanymore.com/
Video’s:
• John Smart (Deloitte colleague) at the DevOps Summit: https://www.youtube.com/watch?v=-Rq-fuiKNCU

Appendices
© 2020 Deloitte The Netherlands

Additional contributors
A big thanks to all our colleagues that contributed to this Point of View
Andries van Dijk Tessa van den Berg Andreas Boon

Director Senior Manager Manager
IT Strategy Human Capital Enterprise Architecture
+31 6 52 04 87 05 +31 6 10 04 25 78 +31 6 83 33 96 09
[email protected] [email protected] [email protected]
Tom Pennings Jan Prüst

Consultant Consultant
Enterprise Architecture Enterprise Architecture
Deloitte Consulting Deloitte Consulting
+31 6 22 17 87 17 +31 6 82 51 86 04
Audrey Sie Jasper Lelijveld

Analyst Analyst
Enterprise Architecture Enterprise Architecture
Deloitte Consulting Deloitte Consulting
+31 6 50 06 26 13 +31 6 50 06 25 77

Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee (“DTTL”), its network of member firms, and their related entities. DTTL and each of its member firms
are legally separate and independent entities. DTTL (also referred to as “Deloitte Global”) does not provide services to clients. Please see www.deloitte.nl/about to learn more about our global network of member
firms.
Deloitte provides audit, consulting, financial advisory, risk advisory, tax and related services to public and private clients spanning multiple industries. Deloitte serves four out of five Fortune Global 500® companies
through a globally connected network of member firms in more than 150 countries and territories bringing world-class capabilities, insights, and high-quality service to address clients’ most complex business
challenges. To learn more about how Deloitte’s approximately 245,000 professionals make an impact that matters, please connect with us on Facebook, LinkedIn, or Twitter.
This communication contains general information only, and none of Deloitte Touche Tohmatsu Limited, its member firms, or their related entities (collectively, the “Deloitte Network”) is, by means of this
communication, rendering professional advice or services. Before making any decision or taking any action that may affect your finances or your business, you should consult a qualified professional adviser. No entity
in the Deloitte Network shall be responsible for any loss whatsoever sustained by any person who relies on this communication.
© 2020 Deloitte The Netherlands

Dev Ops

Uploaded by

Copyright:

Available Formats

Dev Ops

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dev Ops

Uploaded by

Copyright:

Available Formats

DevOps Point of View

An Enterprise Architecture perspective

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 2

Eric Onderdelinden Mark Maijs Donald Pondman

Balázs Nagy Boris Smits Marlies Quekel

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 3

Why do I need DevOps? 9

Where is DevOps applicable? 12

What is needed for DevOps to work? 14

How do I implement DevOps? 38

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 4

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 5

New DevOps practices:

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 6

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 7

Continuous Integration Continuous Delivery

the streamlining of internal is the process of delivering

Continuous Testing Continuous Operations

automating and integrating is proactively managing the

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 8

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 9

1. Focusses solely on development activities 1. Focusses solely on operational activities

3. Operational feedback is only retrieved after 3. Operational understanding and experience is

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 10

All members understand IT governance (e.g. security)

The DevOps technology Integrated software testing

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 11

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 12

Your delivery process has many sequential

Desired product end-state is unknown, changing

Products are tangible, typically consisting of semi-

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 13

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 14

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 15

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 16

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 17

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 18

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 19

1 DevOps team with an expiry As an organizational 5 Ops as infrastructure-as-a- Traditional

4 DevOps as an external Organizations with

Security, Risk &

A team with T-shaped profiles does not have a

2 A lack of hierarchy brings a team closer together and

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 21

Continuous learning &

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 22

Client specific factors might increase the complexity and

Example considerations for an effective “to-be” DevOps

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 23

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 24

Traditional IT Model Implications

Define Design Develop

▪ Many separated functions (silos)

Release & with (manual) handoffs

Target State DevOps Model Implications

▪ Maximizes flow, incremental delivery

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 25

Continuous Continuous Continuous Continuous

CI/CD pipelines integrate process into technology