Devops Point of View an Enterprise Architecture Perspective

Home , Build automation, Continuous delivery, Continuous integration, Development testing, DevOps, Software build

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.

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 Deloitte Consulting Deloitte Consulting Deloitte Consulting +31 6 13 31 37 65 +31 6 82 67 44 36 +31 6 50 07 02 16 [email protected] [email protected] [email protected]

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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 5 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 releases • End-to-end ownership of services • Continuous Operations Improves innovation and risk- • Multi-disciplinary teams • taking • Incremental value delivery • Realizes faster time to market • Flow optimization in the delivery Applying DevOps principles process • Improves solution quality and 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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 6 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 2009 2011 2016 high-performing 2019 in their teams next 2008 waterfall methods of Andrew Shafer and Patrick March 2011, Gartner companies to ‘Dev’ and ‘Ops’ Debois meet at the predicts “By 2015 application “Clearly, what was “organizations are DevOpsDays 2009 and later DevOps will be adopted development were state of-the-art three embedding security at Velocity conference, the by 20% of the Fortune losing ground to years ago is just not (DevSecOps), privacy, term is picked up: 2000.” iterative methods such 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. Deloitte Tech Trends deployment processes. DevOps Report 2019

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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 9 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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 10 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

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 constraints, where outputs equal required inputs for early value delivery Delivery process 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- finished products provisioned by multiple partners service Product type that don’t have a direct relation with each other Indicator

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 14 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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 16 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.

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 17 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 Functional Communities of End-to-end ownership of services direct the development of a CoPs 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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 18 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 Solutions Architect 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 the application (full-stack responsibility) technology operations, performs (e.g. Service Desk) 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.

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

A T-shaped profile entails that a team member covers

different knowledge areas and skills in varying levels

Test

Design DevOps

Analysis of expertise.

Delivery

Courage

Business Business

Leadership

Continuous Continuous

Compliance

Engineering

Specification

Optimization

improvement

Teambuilding

Programming

Infrastructure Infrastructure

Architecture & Business Business Value Security, Security, &Risk A team with T-shaped profiles does not have a hierarchy since everyone’s skills and knowledge 1 complement each other.

2 A lack of hierarchy brings a team closer together and creates a sense of shared ownership.

3 Level

LevelLevel 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)

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 21 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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 22 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 Regulatory Setting up DevOps teams or an entire DevOps 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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 24 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 Define Develop

Design ▪ Big chunks of work

Dev App App ▪ Maximizes each process-step, big- bang delivery ▪ Many separated functions (silos) Release & Test Operate Retire with (manual) handoffs

Deploy Ops

Infra & & Infra ▪ Specialization (I-shaped roles) ▪ Rigid change ability

Target State DevOps Model Implications ▪ Complex iterative process to manage unknowns ▪ Small chunks of work ▪ Maximizes flow, incremental delivery Plan Continuous Continuous Continuous Continuous Retire

Integration Testing Delivery Operations ▪ Fewer handoffs (less silos) model DevOps DevOps ▪ Generalists (T-shaped roles) ▪ More flexible to adapt to change

Continuous Improvement

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 25 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 Requirement & Source & Build & Release & Ideation Operate Monitor Design Develop Test Deploy

Continuous Continuous Continuous Continuous 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 CI/CD Done means released - Deliver releases for pre-deployment or deploy new releases to productions in minutes instead of months 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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 27 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/ © 2020 Deloitte The Netherlands Deloitte DevOps Point of View 28 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 • 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 cover multiple vendors with different

IT Maturity IT considered a thorough 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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 29 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 © 2020 Deloitte The Netherlands Deloitte DevOps Point of View 30 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

Continuous Continuous Continuous Continuous 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.

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 32 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

DevOps practices The capabilities of the DevOps practices will be described through the dimensions of the Technology TOM in a box

DevOps The DevOps Target Operating Model (TOM) outlines the TOM governance structures on how an organization should govern and operate the DevOps practices

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 33 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: Personas Services Mission

1. What services the organization is going to What deliver, and to whom Capabilities Metrics & Processes & Skills KPI’s 2. How these services are delivered using

How How Funding & Functions & Tooling DevOps capabilities, processes and CI/CD Charging Interactions tooling

Sourcing & Collaboration Culture / 3. Where these DevOps capabilities are sourced Ecosystems & Location work style

from, what the ecosystem looks like, and how Where to collaborate in a DevOps culture Organization Governance Incentives & Structure & Mandate Rewards 4. Who are responsible for service delivery and

Roles & Res- Who support using DevOps roles and organization ponsibilities structure Dimension category: Organization Execution Behavior

Organization

Execution Continuous Continuous Continuous Continuous 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 DevOps Release Orchestration capabilities Development Practices Deployment Automation (non-exhaustive) Development Environments Configuration & Asset Management Source Code & Version Control Environment Management Automated Code Build Infrastructure automation CI/CD Metrics and Tracking

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 35 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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 37 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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 38 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

Alignment / Vision Co-created transformation Adopt / Scale Phase Implement Improve

Iteration Define

What What What How How How Where Where Where Who

dimension(s) Who Who Operating ModelOperating

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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 39 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

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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 42 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 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

What is is What 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, ▪ 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 Benefits Benefits ▪ Provides priorities for capability improvement ▪ Identifies areas for capability improvement

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

Cost Output

Industry

Sample Capability Release Planning Continuous Integration Benchmark Prioritization Maturity Maturity

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 43 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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 45 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 • Tailored DevOps Target as defining a culture to facilitate Obtain as much insight, by logging all data Operating Model collaboration, knowledge sharing and 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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 47 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 Check if the repositories Code review & Security checks & guidelines & used are whitelisted (only Security checks Source code Training validation approved software) 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

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 49 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 • Unit testing • Security Type of tests user stories Regression tests (E2E) • Disaster Recovery • Deployment tests • Regression tests (E2E) • Prepare for go-live execution

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 50 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

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

Andries van Dijk Tessa van den Berg Andreas Boon Director Senior Manager Manager IT Strategy Human Capital Enterprise Architecture Deloitte Consulting Deloitte Consulting Deloitte Consulting +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 [email protected] [email protected]

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 [email protected] [email protected]

© 2020 Deloitte The Netherlands Deloitte DevOps Point of View 54 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.