KEMBAR78
Creating a DevOps Team that Isn't Evil | PPTX
© 2014 IBM Corporation
Creating a DevOps Team
That Isn’t Evil
Curtis Yanko - Cigna
Eric Minick - IBM
Who are these guys?
• Eric is a DevOps Evangelist with
IBM where he helps customers get
the most out of their build, deploy
and release processes.
• Today he works with customers
and industry leaders to find the
best ways of adopting continuous
delivery and DevOps.
• @EricMinick
Eric
Minick
• Curtis has 17 years’ experience in
Application Development and
Delivery and is a leading
evangelist for DevOps in the
Enterprise.
• Curtis has a background in Config
Management, Continuous
Integration and is now driving a
DevOps vision and strategy in a
large Enterprise.
Curtis
Yanko
Evil?
And yet…
3
Slide from Stephen Elliot at #DOES14:
http://youtu.be/9_ZuEhgTdLc?t=12m16s
Is the industry
making a huge
mistake?
The Plan
• What Would Make a DevOps Team Evil?
• A Success Story: DevOps Team at Cigna
• Other Good Models
• Q&A
5
The Plan
• What Would Make a DevOps Team Evil?
• A Success Story: DevOps Team at Cigna
• Other Good Models
• Q&A
6
Silos
New silo = same old problems
7
Dev OpsDevOps
HT: Matthew Skelton
http://slidesha.re/1vOiHc4
8
Rebranding – Declaring Success without any
Doesn’t
sound
helpful
5 Signs your DevOps Team is Evil
Other groups interact with you via Tickets
Your team owns lots of things
The manager is growing his fiefdom
You share metrics “up” not “out”
Define success in IT terms, not business terms
9
The Plan
• What Would Make a DevOps Team Evil?
• A Success Story: DevOps Team at Cigna
• Other Good Models
• Q&A
10
Feedback From the System
11
Anti-Type C – “We Don’t Need Ops”
Dev OpsSCM
DevOps Patterns: Team Topologies – Mathew Skelton
The ‘Team’ was an Opportunity
12
To demonstrate something new
Two Ingredients for Change
13
Create an appetite for something new
Create a distaste for the status quo
Tracer Bullet
14
A Battle Plan For DevOps in the Enterprise – Willie Wheeler
Problem Domain - Zero Touch Deploys
15
Build Deploy Test Release
Code
Config
Data
Env
SystemDe-composition
In Scope
Value Stream
In Scope
Out of scope
Out of scope
Culture and Collaboration
16
No need to tear down silo’s just go knock
on the door and introduce yourself.
We offered transparency and inclusion
The Plan
• What Would Make a DevOps Team Evil?
• A Success Story: DevOps Team at Cigna
• Other Good Models
• Q&A
17
IBM – A global team of developers
18
Perth
Canada
Toronto, Ottawa
Montreal, Victoria
Haifa
Rehovot
China
Beijing
Shanghai
Xian
Yamato
Taiwan
Paris
Pornichet
Kirkland
Seattle
Foster City
San Francisco
SVL/San Jose
Almaden
Agoura Hills
Irvine
El Segundo
Costa Mesa
Las Vegas
Bedford, MA
Bedford, NH
Essex Junction, VT
Westborough
Cambridge
Littleton
Marlborough
Cork
Dublin
Galway
India
Bangalore
Pune
Hyderabad
Gurgaon
Vizag
Cairo
Rome
Gold Coast
Sydney Canberra
Fairfax
Raleigh
Charlotte
Lexington, KY
Atlanta
Boca Raton
Tampa
Krakow
Warsaw
Sao Paulo
Malaysia
DelftStockholm
Boeblingen
Southbury
New York City
Princeton
Hawthorne
Endicott
Moscow
Zurich
Pittsburg
Poughkeepsie
Somers
Yorktown Heights
Hopewell Junction
Wayne
Hursley
Warwick
York
Edinburgh
London /
Staines
Milton Keynes
Phoenix
Austin
Dallas
Dublin
Rochester, MN
Boulder
Denver
Lenexa, KA
Tucson
El Salto, MX
US 20,000
Canada 3,100
Latin America 600
EMEA 7,100
AP 11,800
Total 42,600
IBM’s DevOps Center of Competency
Responsible to drive the transformation
• Lead by example
• We work the way we ask teams to work, specifically
- Using IBM Design Thinking to determine how to best help our teams transform – user out come focused
- Report our transformation work in the context of our user – SWG teams
- Using Lean & Agile practices to deliver
SWG team can execute a simple experiment for a coded
hypothesis (based on a Design Hill) in < 7 days
SWG Team can find information on measuring a signal that will validate a hypothesis < 30
secs
SWG Team can continuously collect & visualize correlated signal data in < 7 days
Who
What
Wow
IBM CoC Approach
• Facilitate communication & collaboration
• Establish a Community (internal forums) to share what works and get support
• Roadshows / Presentations for techies and execs
• Internal educational sessions (webinars for several thousand participants)
• Online tutorials
• Build Support in the Org
• Recruit evangelists with grass roots and management respect
• Benchmarking and case studies across teams
• Recruit implementation managers on the individual teams
• Invest in Tooling
20
IBM CoC Approach cont.
• Invest in tooling
• Provide as a service
• Map business controls to DevOps techniques
• Does an experiment imply a commitment to a feature?
• Can we experiment with something in English only, for a product available in 10 languages?
• How should marketing work with a steady stream of features instead of big releases?
21
Success Story: Watson Analytics
Continuous Delivery to SoftLayer in 15 minutes
22
Environments
Manual Automated
Gain
Deploy Tests Deploy Tests
Test 4 hours 80 hours 20 min 3 hrs 96%
Staging
8 hours 4 hours 40 min 15 min 92.5%
Production
(25 environments)
200 hours 4 hours 3 hours 5 min 98.5%
Gain 98% 96% 98.5%
Success Story: Workload Automation
as a Service DevOps Solution
Rome, Italy
23
IBM SoftLayer
Monitor and Optimize
Rational Team
Concert
Rational Quality Manager
Rational Performance Tester
IBM Security AppScan
SmartCloud Control
Desk
IBM Application Performance
Management
IBM Endpoint Manager
IBM Security QRadar®
IBM UrbanCode Deploy
IBM Workload Automation
• Production deployment in few hours
• Change management process
• Automated tests
• No “black out” during update
Standard Model for a Center of X DevOps Team
24
Dev OpsDevOps
In Summary
DevOps as a Silo is bad
Teams done well Scale a good idea
Not a silo. A Facilitator
DevOps Teams should put themselves out of work
25
Questions
Acknowledgements and Disclaimers
© Copyright IBM Corporation 2015. All rights reserved.
– U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM
Corp.
IBM, the IBM logo, ibm.com, Interconnect, [IBM Brand, if trademarked], and [IBM Product, if trademarked] are trademarks or registered trademarks of
International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on
their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned
by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current
list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml
Other company, product, or service names may be trademarks or service marks of others.
• REMINDER: Please follow the guidelines for copying third party materials. Third party screen shots, logos, presentations and website content are
copyrighted materials owned by the third party, and as such we need permission from the third party to use them. Also, be sure the information you
put on a chart is verifiable. Be sure to cite the source on your deck when using words, ideas, facts, photos, news clips or other expression that did not
originate from yourself. This applies even if the content is publicly available and not confidential. If you have any questions, please contact your IP
Attorney.
Availability. References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which
IBM operates.
The workshops, sessions and materials have been prepared by IBM or the session speakers and reflect their own views. They are provided for
informational purposes only, and are neither intended to, nor shall have the effect of being, legal or other guidance or advice to any participant. While
efforts were made to verify the completeness and accuracy of the information contained in this presentation, it is provided AS-IS without warranty of
any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this presentation or any
other materials. Nothing contained in this presentation is intended to, nor shall have the effect of, creating any warranties or representations from IBM
or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software.
All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have
achieved. Actual environmental costs and performance characteristics may vary by customer. Nothing contained in these materials is intended to,
nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results.
Thank You
Your Feedback is
Important!
Access the InterConnect 2015
Conference CONNECT Attendee Portal
to complete your session surveys from
your smartphone, laptop or conference
kiosk.
Divider slide

Creating a DevOps Team that Isn't Evil

  • 1.
    © 2014 IBMCorporation Creating a DevOps Team That Isn’t Evil Curtis Yanko - Cigna Eric Minick - IBM
  • 2.
    Who are theseguys? • Eric is a DevOps Evangelist with IBM where he helps customers get the most out of their build, deploy and release processes. • Today he works with customers and industry leaders to find the best ways of adopting continuous delivery and DevOps. • @EricMinick Eric Minick • Curtis has 17 years’ experience in Application Development and Delivery and is a leading evangelist for DevOps in the Enterprise. • Curtis has a background in Config Management, Continuous Integration and is now driving a DevOps vision and strategy in a large Enterprise. Curtis Yanko
  • 3.
  • 4.
    And yet… 3 Slide fromStephen Elliot at #DOES14: http://youtu.be/9_ZuEhgTdLc?t=12m16s
  • 5.
    Is the industry makinga huge mistake?
  • 6.
    The Plan • WhatWould Make a DevOps Team Evil? • A Success Story: DevOps Team at Cigna • Other Good Models • Q&A 5
  • 7.
    The Plan • WhatWould Make a DevOps Team Evil? • A Success Story: DevOps Team at Cigna • Other Good Models • Q&A 6
  • 8.
    Silos New silo =same old problems 7 Dev OpsDevOps HT: Matthew Skelton http://slidesha.re/1vOiHc4
  • 9.
    8 Rebranding – DeclaringSuccess without any Doesn’t sound helpful
  • 10.
    5 Signs yourDevOps Team is Evil Other groups interact with you via Tickets Your team owns lots of things The manager is growing his fiefdom You share metrics “up” not “out” Define success in IT terms, not business terms 9
  • 11.
    The Plan • WhatWould Make a DevOps Team Evil? • A Success Story: DevOps Team at Cigna • Other Good Models • Q&A 10
  • 12.
    Feedback From theSystem 11 Anti-Type C – “We Don’t Need Ops” Dev OpsSCM DevOps Patterns: Team Topologies – Mathew Skelton
  • 13.
    The ‘Team’ wasan Opportunity 12 To demonstrate something new
  • 14.
    Two Ingredients forChange 13 Create an appetite for something new Create a distaste for the status quo
  • 15.
    Tracer Bullet 14 A BattlePlan For DevOps in the Enterprise – Willie Wheeler
  • 16.
    Problem Domain -Zero Touch Deploys 15 Build Deploy Test Release Code Config Data Env SystemDe-composition In Scope Value Stream In Scope Out of scope Out of scope
  • 17.
    Culture and Collaboration 16 Noneed to tear down silo’s just go knock on the door and introduce yourself. We offered transparency and inclusion
  • 18.
    The Plan • WhatWould Make a DevOps Team Evil? • A Success Story: DevOps Team at Cigna • Other Good Models • Q&A 17
  • 19.
    IBM – Aglobal team of developers 18 Perth Canada Toronto, Ottawa Montreal, Victoria Haifa Rehovot China Beijing Shanghai Xian Yamato Taiwan Paris Pornichet Kirkland Seattle Foster City San Francisco SVL/San Jose Almaden Agoura Hills Irvine El Segundo Costa Mesa Las Vegas Bedford, MA Bedford, NH Essex Junction, VT Westborough Cambridge Littleton Marlborough Cork Dublin Galway India Bangalore Pune Hyderabad Gurgaon Vizag Cairo Rome Gold Coast Sydney Canberra Fairfax Raleigh Charlotte Lexington, KY Atlanta Boca Raton Tampa Krakow Warsaw Sao Paulo Malaysia DelftStockholm Boeblingen Southbury New York City Princeton Hawthorne Endicott Moscow Zurich Pittsburg Poughkeepsie Somers Yorktown Heights Hopewell Junction Wayne Hursley Warwick York Edinburgh London / Staines Milton Keynes Phoenix Austin Dallas Dublin Rochester, MN Boulder Denver Lenexa, KA Tucson El Salto, MX US 20,000 Canada 3,100 Latin America 600 EMEA 7,100 AP 11,800 Total 42,600
  • 20.
    IBM’s DevOps Centerof Competency Responsible to drive the transformation • Lead by example • We work the way we ask teams to work, specifically - Using IBM Design Thinking to determine how to best help our teams transform – user out come focused - Report our transformation work in the context of our user – SWG teams - Using Lean & Agile practices to deliver SWG team can execute a simple experiment for a coded hypothesis (based on a Design Hill) in < 7 days SWG Team can find information on measuring a signal that will validate a hypothesis < 30 secs SWG Team can continuously collect & visualize correlated signal data in < 7 days Who What Wow
  • 21.
    IBM CoC Approach •Facilitate communication & collaboration • Establish a Community (internal forums) to share what works and get support • Roadshows / Presentations for techies and execs • Internal educational sessions (webinars for several thousand participants) • Online tutorials • Build Support in the Org • Recruit evangelists with grass roots and management respect • Benchmarking and case studies across teams • Recruit implementation managers on the individual teams • Invest in Tooling 20
  • 22.
    IBM CoC Approachcont. • Invest in tooling • Provide as a service • Map business controls to DevOps techniques • Does an experiment imply a commitment to a feature? • Can we experiment with something in English only, for a product available in 10 languages? • How should marketing work with a steady stream of features instead of big releases? 21
  • 23.
    Success Story: WatsonAnalytics Continuous Delivery to SoftLayer in 15 minutes 22
  • 24.
    Environments Manual Automated Gain Deploy TestsDeploy Tests Test 4 hours 80 hours 20 min 3 hrs 96% Staging 8 hours 4 hours 40 min 15 min 92.5% Production (25 environments) 200 hours 4 hours 3 hours 5 min 98.5% Gain 98% 96% 98.5% Success Story: Workload Automation as a Service DevOps Solution Rome, Italy 23 IBM SoftLayer Monitor and Optimize Rational Team Concert Rational Quality Manager Rational Performance Tester IBM Security AppScan SmartCloud Control Desk IBM Application Performance Management IBM Endpoint Manager IBM Security QRadar® IBM UrbanCode Deploy IBM Workload Automation • Production deployment in few hours • Change management process • Automated tests • No “black out” during update
  • 25.
    Standard Model fora Center of X DevOps Team 24 Dev OpsDevOps
  • 26.
    In Summary DevOps asa Silo is bad Teams done well Scale a good idea Not a silo. A Facilitator DevOps Teams should put themselves out of work 25
  • 27.
  • 28.
    Acknowledgements and Disclaimers ©Copyright IBM Corporation 2015. All rights reserved. – U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. IBM, the IBM logo, ibm.com, Interconnect, [IBM Brand, if trademarked], and [IBM Product, if trademarked] are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml Other company, product, or service names may be trademarks or service marks of others. • REMINDER: Please follow the guidelines for copying third party materials. Third party screen shots, logos, presentations and website content are copyrighted materials owned by the third party, and as such we need permission from the third party to use them. Also, be sure the information you put on a chart is verifiable. Be sure to cite the source on your deck when using words, ideas, facts, photos, news clips or other expression that did not originate from yourself. This applies even if the content is publicly available and not confidential. If you have any questions, please contact your IP Attorney. Availability. References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. The workshops, sessions and materials have been prepared by IBM or the session speakers and reflect their own views. They are provided for informational purposes only, and are neither intended to, nor shall have the effect of being, legal or other guidance or advice to any participant. While efforts were made to verify the completeness and accuracy of the information contained in this presentation, it is provided AS-IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this presentation or any other materials. Nothing contained in this presentation is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results.
  • 29.
    Thank You Your Feedbackis Important! Access the InterConnect 2015 Conference CONNECT Attendee Portal to complete your session surveys from your smartphone, laptop or conference kiosk.
  • 30.

Editor's Notes

  • #13 While this may be an anti-pattern for a goal state it’s a common starting point.
  • #14 We were given license to innovate
  • #15 A large part of my career was spent in this configuration dating back to when CI was the hot topic.
  • #16 Take one asset and automate Code, Config & Data from Dev to Prod.
  • #17 This focused on getting control of the artifacts entering and moving through the system in a consistent way
  • #21 The “hill” on this slide is an example of how we are working as we ask the teams to. Create a vision and work toward as an aligned team. IBM Design Thinking keeps us focused and aligned on what the user needs. We are focused on the next wave of support the teams will need and are doing user research, interviewing teams to ensure we are solving the right problem.
  • #29 3/5/2015