SESSION 801 Friday, November 4, 10:15 AM - 11:15 AM Track: DevOps and Agile

Transcription

1 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 ken.lewis@paconsulting.com 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.

2 Session 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

3 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?

4 Where do these behaviors come from? Competitive bidding and specialization have led to sub-optimized silos 18 th to 20 th 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 compared Silo handoffs from design to delivery created a waterfall effect. Physical Product Requirements Marketing Implementation Commercialization Production Maintenance Software Products Define Concept Define Requirements System Detailed Code Integrate &Test Run Application support IT Service Phases and Gates provided points to reevaluate Service Strategy Service Service Transition Service the Operation reason and cost of a Continuous Improvement product/service introduction

5 Concurrent Engineering Speed 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 Implementation Commercialization Production Maintenance Requirements Marketing changes Manufacturing changes Product changes Implementation Commercialization Production Test Prototype products Production Maintenance Concurrent Software Engineering Software 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. Define Concept Define Requirements System Detailed Code Integrate &Test Run Application support Ideation Plan/Elaborate/Done? Plan/Elaborate/Done? Plan/Elaborate/Done? Plan/Elaborate/Done? /Code Test Demo /Code Refactor Test Demo /Code Test Demo VALUE being realized Run Application support

6 IT Services Life Cycle Does ITIL still live in the 20 th 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 V1 Cost Management of IT Services (1990) Service Level Management (1989) Contingency Planning (1989) Availability Mgmt. (1992) Configuration Mgmt (1990) Change Mgmt (1989) Software Control and Distribution (1991) Problem Mgmt (1990) Help Desk (1989) ITIL Small Scale Implementation ITIL V2 Planning to implement Service Management (2002) Business Perspective (2004) Service Delivery (2001) Software Asset Management (2003) ICT Infrastructure (2002) Service Support (2000) Application management (2002) Security Management ITIL V3 Strategy ( ) ( ) Transition ( ) Operation ( ) Continuous Improvement ( ) 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.

7 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 BUILD Software Engineering Requirements Gathering Engineering Methods & Models Mathematical Professional Practices Quality Computing Testing Engineering Mgmt Engineering Economics Engineering Process Maintenance Coding (Construction) Engineering RUN Service Operations Problem Management Configuration Management Event Management Incident Management Troubleshooting Service Mgmt Access Management Request Management Application Mgmt Functions Technology Mgmt Functions Operations Facilities Functions Service Desk

8 Let s recognize the overlaps Requirements Gathering Engineering Methods & Models Engineering Mathematical Quality Incident Management Troubleshooting Computing Service Mgmt Maintenance Application Mgmt Functions Technology Testing Mgmt Functions Problem Management Coding (Construction) Operations Professional Facilities Functions Configuration Practices Service Desk Management Access Management Engineering Mgmt Event Management Engineering Economics Engineering Process Request Management And missing link.. Transitioning Services Change Evaluation Transition Planning & Support Engineering Methods & Models Requirements Gathering Quality Testing (SV&T) Release & Deployment Mgmt Change Management Computing Knowledge Mgmt Service Mgmt Incident Management Access Management Service Desk Functions Request Management Mathematical Engineering Engineering Mgmt Professional Practices Engineering Economics Engineering Process Maintenance Coding (Construction) Configuration Management Troubleshooting Application Mgmt Functions Event Management Problem Management Technology Mgmt Functions Operations Facilities Functions

9 Robustness Balancing agility with lowering risk by adopting warranty as important as service functionality Availability Mgmt IT Security Mgmt Service Level Mgmt Demand Mgmt Capacity Mgmt Portfolio 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?

10 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 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 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: Learn Developers 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

11 Take Away 2: Improve Strive 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: Adapt Accept 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

12 Recap Realizing that our DevOp teams have discipline luggage they bring to the table when creating a new IT operating model for the 21 st 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. Ken.Lewis@PAconsulting.com (646)