DevOps: You Can't Just Be a Developer Anymore/media/Files/Session801.pdf · DevOps, “you can’t be just a developer anymore” Ken Lewis, PA Consulting We have a DevOps team…

SESSION 801 Friday, November 4, 10:15 AM - 11:15 AM

Track: DevOps and Agile

DevOps: You Can't Just Be a Developer Anymore

Ken Lewis Consultant,PA Consulting [email protected]

Session Description

With the increasing need to respond to the marketplace, IT is charged with changing product functions, data, and new business processes with faster turnaround. Enter DevOps. But as a member of a DevOps team, what are you required to know? This session will explore the different roles and responsibilities of each member of the DevOps team and how they should work together to maintain an incident-free IT service offering. (Experience Level: Intermediate)

Speaker Background Ken Lewis is an ITIL professional with more than twenty-five years of experience in the architecture, design, deployment, disaster recovery, and day-to-day operational management of global internal and outsourced IT infrastructures. Ken has led IT transformation programs for clients large and small, acting as program/project manager and technical and business architect.

Session 801 - The disciplines of DevOps, “you can’t be just a

developer anymore”Ken Lewis, PA Consulting

We have a DevOps team…so why are they arguing with each other and other groups?

• Businesses are being challenged to deliver IT capability/product faster but not melt down a running environment because of a slip-up• In response, DevOps “groups” are created to straddle the divide

The Question: Do these DevOps team members understand each other and the new responsibilities in terms of the disciplines they need to adopt? Do they know their place in the larger legacy context? Are these disciplines fit for purpose in today’s world?

We will look at a bit of history, compare existing roles, consider where to consolidate, simplify , or even reconsider how to organize the delivery of services in the future

Are you a developer? Let’s talk…

When developing software have you…

Talked to a user about when and how often they need to solution?

Talked to the business owner about availability, reliability and criticality of the software?

Talked to the compute, network and data teams about what your application will need to run? – internal and external?

Talked to the back up team?

Explained your software to a service desk or application support team?

When building software have you…

Determined where the software could fail and how to recover?

Standardized program functions as modules or used stock capabilities from products?

Created on-going accessible “health” logs that monitoring can help in troubleshooting?

Record the software components used to build and how they transact with each other? Are there artifacts identifying the modules?

Created automated testing scripts?

As a developer are you..

More comfortable with

• A large pile of work that never goes away (even though you complain about it)

• Handing off an application and it’s flaw that you still know is there… to an application support team and let the admins’ fix script just restart your software when it crashes?

• Asking the system administrator for root privileges to make your software work rather than figure out what system privilege you really need?

• Putting all your code on a file system that no one backs up

Are you annoyed when..

• You are on call overnight?

• A nasty bug in that software from 12 months ago comes up and you have to fix it – dropping that cool thing you are doing today

• Being on a 35 person bridge discussing your application outage and find out it was somebody else’s problem

• Having to write a back-out plan for a change?

• When a user asks when the application will be running again?

Where do these behaviors come from?Competitive bidding and specialization have led to sub-optimized silos

18th to 20th Century commercial product business practices• Bidding to win contracts with fixed prices – second lowest wins

• Murphy’s Law intrudes - unpredictable happens

• And purchasing lowest cost solution – not the one that provides the best business value

• Conservative approach to risk – high premium on planning and budgeting

• Organizational Silo Mentality - organization by expertise and skill, familiarity with co-workers, “family” and protective shell from blame. • Leads to optimization of the silo, not of the overarching concern of the firm

• Tribal blame games – not focusing on external threats

• Product bunching up “inventory” between the silos

• Broken hand-offs between silos – leading to Conway’s law

Product delivery disciplines comparedSilo handoffs from design to delivery created a waterfall effect.

Requirements –Marketing

DesignImplementation

CommercializationProduction Maintenance

Service Strategy Service Design Service Transition Service Operation

Continuous Improvement

Define Concept

Define Requirements

Code Integrate &Test Run – Application supportSystem Design

Detailed Design

Physical Product

Software Products

IT Service Phases and Gates provided points to re-evaluate the reason

and cost of a product/service

introduction

Concurrent EngineeringSpeed to Market becomes key – how to speed up product introductions• With new engineering design technology – speed to market became the

differentiator. Recognizing you can’t know or plan everything up front.

• Concurrent Product Engineering (1986) - is a systematic approach to the integrated, concurrent design of products and their related processes, including manufacture and support” 1

Requirements –Marketing

DesignImplementation

CommercializationProduction Maintenance

Requirements – Marketing

Design

Implementation Commercialization

Production Test

Production Maintenance

Product changes

Design changes

Manufacturing changes

Prototype products

Concurrent Software EngineeringSoftware products had it’s “concurrent engineering” moment as well.

• Agile (Scrum/XP) brings together the ideation, elaboration, build and test disciplines within short time boxes - providing value quickly to engaged business customer.

Ideation

Plan/Elaborate/Done?

Design/Code

Test

Run – Application support

Dem

o

Design/Code

Test

Design/Code

Test

Refactor

VALUE being realized

Define Concept

Define Requirements

Code Integrate &Test Run – Application supportSystem Design

Detailed Design

Dem

o

Plan/Elaborate/Done? Plan/Elaborate/Done? Plan/Elaborate/Done?

Dem

o

IT Services Life CycleDoes ITIL still live in the 20th Century?

ITIL’s main concern in 1989 was the continuous execution of services for users; The disciplines developed focused on the delivery system – the physical servers, networks, wires, data centers; With V3, there were new processes focusing on some of the software engineering disciplines

ITIL V3

ITIL V2

Strategy (2007-2011) Design (2007-2011) Transition (2007-2011) Operation (2007-2011)

Service Support (2000)Service Delivery (2001)

ICT Infrastructure (2002)

Application management (2002)

Security Management

Software Asset Management (2003)

Planning to implement Service Management (2002)

ITIL Small Scale Implementation

Continuous Improvement (2007-2011)

ITIL V1

Service Level Management (1989)

Help Desk (1989)

Contingency Planning (1989)

Change Mgmt (1989) Problem Mgmt (1990)

Configuration Mgmt (1990)

Cost Management of IT Services

(1990)

Software Control and Distribution (1991)

Availability Mgmt. (1992)

Business Perspective (2004)

DevOps – The definition• The IT Skeptic calls it the “operational spawn” of Agile

• The Scrum Alliance defines it as “A philosophy under which the business teams, development teams, and the operations organization collaborate on a continuous basis to make sure that IT solutions are available to business on time and that they run without disruption. It calls for automation, collaboration, cultural change, and an organizational structure that is less complex and is easy to navigate. It addresses the people, process, and tools, as well as the technology dimensions needed to secure this collaboration and sync up the different stakeholders to move functionality to production faster

• Gene Kim defines it as “emerging professional movement that advocates a collaborative working relationship between Development and IT Operations, resulting in the fast flow of planned work (i.e. high deploy rates), while simultaneously increasing the reliability, stability, resilience and security of the production environment.” ”

• Ethan Strider, A DevOps engineer defines it “as an extension of Agile. Agile focuses on helping software developers create better software faster. Now that many corporations are hosting their own software in the “Cloud,” there is a need for these Agile practices to be extended to the hosting (operations) side of things. DevOps focuses on helping teams create, deploy, and host software faster and more resiliently.

The two worldviews collide So what is the problem in building effective delivery of software as services?

• CTO Alexander Pluim of BVA Auctions: “When I looked at people behind their desks, trying to guess on their own without communicating with the other disciplines, I was amazed”

• Development by Agile (Scrum/XP/Safe)• Driven by Owners – Business Representatives or Intermediaries (Business Analysts)

• Driven by Function - Utility

• Requirements are “Functional and/or Non-Functional”

• Software Systems Oriented

• Biases toward interactions, collaboration, response to change, and delivery of value

• Operations• Driven by Users and Senior Management

• Driven by “Uptime” - Warranty

• Requirements are expectation of continual delivery

• Delivery Systems Oriented – Facilities, Compute, Network, Storage and the underlying supporting software utilities

• Biases toward documentation, “completer/finisher” mindset, responsibilities, stability, driving to lowest cost

Disciplines of

RequirementsGathering

DesignCoding (Construction)

Testing

Configuration Management

Incident Management

Problem Management

Engineering Mgmt

Engineering Process

Engineering Methods& Models

Quality

Professional Practices

Engineering Economics

Computing Foundations

Mathematical Foundations

Engineering Foundations

Event Management

Access Management

Troubleshooting Foundations

Technology Mgmt Functions

Operations Facilities Functions

Application Mgmt Functions

Service MgmtFoundations

Maintenance

Request Management

BUILD SoftwareEngineering

RUN ServiceOperations

Service Desk

Let’s recognize the overlaps

RequirementsGathering

Design

Coding (Construction)

Testing

Configuration Management

Incident Management

Problem Management

Engineering Mgmt

Engineering Process

Engineering Methods& Models

Quality

Professional Practices

Engineering Economics

Computing Foundations

Mathematical Foundations

Engineering Foundations

Event ManagementAccess Management

Troubleshooting Foundations

Technology Mgmt Functions

Operations Facilities Functions

Application Mgmt Functions

Service MgmtFoundations

Maintenance

Request Management

Service Desk

And missing link .. Transitioning Services

RequirementsGathering

Design

Coding(Construction)

Testing (SV&T)

Configuration Management

Incident Management

Problem Management

Engineering Mgmt

Engineering Process

Engineering Methods& Models

Quality

Professional Practices

Engineering Economics

Computing Foundations

Mathematical Foundations

Engineering Foundations

Event Management

Access Management

Troubleshooting Foundations

Technology Mgmt Functions

Operations Facilities Functions

Application Mgmt Functions

Service MgmtFoundations

Maintenance

Request ManagementChange Management

Release & Deployment Mgmt

Transition Planning & SupportChange Evaluation

KnowledgeMgmt

Service Desk Functions

RobustnessBalancing agility with lowering risk by adopting warranty as important as service functionality

Availability Mgmt

Capacity Mgmt

IT Security Mgmt

Demand Mgmt

Portfolio Mgmt

Service Level Mgmt

Food for Thought 1 : Does DevOps apply to all of delivery infrastructure? Do you slice by silo? Or slice by type of service? What happens when a cloud becomes your delivery infrastructure?

Should bi-modal IT cleave IT between Interaction Services and Utility Delivery Services ?

Food for Thought 2: Should we look at DevOps in the eyes of the IT4IT model?

• Most congruent IT4IT value flow with DevOps focus today is the Requirement to Deploy (R2D) flow supported by the Service Design and Transition disciplines • This was original pain point of DevOps community where the bureaucracy of change

approvals were slowing the delivery of software to the production• Automation has been a fast growing product market and now begins to fulfill that promise

• The Detect to Correct (D2C) flow is represented by chain of Event, Incident, Problem and Change (in context of repair). This is a target rich environment to automate - Is this the next step?

• The Strategy to Portfolio (S2P) flow based on parts of Service Strategy and Design provide the guardrails to DevOps teams

• The Request to Fulfill (R2F) flow is focused on request management, service level agreements and service catalog disciplines – Does that fit with a DevOps model?

Take Away 1: LearnDevelopers have a whole new set of disciplines to understand and follow:

• Recognition by developers that software function only is not enough

• Solution design needs to incorporate warranty - following availability, capacity , business continuity, knowledge management disciplines

• Learning the lean disciplines as they relate to operation of their solutions

• Learning and integrating with existing event, incident and problem management practices and processes - help in the automation of keep it running, keep it current operational disciplines

Take Away 2: ImproveStrive for KISL (Keep it Simple and Light) ITIL disciplines for Interaction Delivery Services

• Operations and Transition teams have to simplify the disciplines when deploying customer interaction services• Change processes simplified for small incremental changes - drive toward

communication of change vs. control/approval.

• Automation of application and infrastructure maintenance – “toil” needs to be removed

• Modular delivery systems - Services providing levels of offerings ( Gold, Silver, Bronze, “Coal”) -> Implies flexible architecture designs – based on interfaces

• Consider the Malcom Fry book on ITIL Lite. It proposes which service management disciplines that should be deployed based on need, the type of service and external demands on the IT organization

Take Away 3: AdaptAccept more discipline structure for underlying “utility” services – the bedrock of agile customer facing services

• Certain Development and Delivery systems components will always need waterfall and strict service management disciplines• Utility services – Data Centers, Network infrastructure.

• High expense data collection system – Specialized data collection systems – satellites, oil well control systems, nuclear plant and power systems.

• Critical safety systems – aircraft, automobile and other transport information system, 911/999 software and technology support

• Utilities services need to be modular, scalable and provide easy to use, flexible standardized interfaces – (e.g. providing instant capacity upgrades)

• Agile LEAN improvement projects still can be used to perfect these R2F service value flows

RecapRealizing that our DevOp teams have discipline luggage they bring to the table when creating a new IT operating model for the 21st century – we have to learn, improve and adapt

• Takeaway 1 – Learn: Developers have a whole new set of disciplines to understand and follow

• Takeaway 2 – Improve: Operations team must strive for KISL (Keep it Simple and Light) ITIL processes for Interaction Delivery Services

• Takeaway 3 – Adapt: Accept more discipline structure for underlying “utility” services but making them more robust using lean principles

Thank you for attending this session and any questions? .

Please don’t forget to complete an evaluation for this session!

Evaluation forms can be completed electronically on the

FUSION 16 Conference App.

[email protected]

(646)-919-5721