Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
© 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, deplo...
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 g...
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 ...
Culture and Collaboration
16
No need to tear down silo’s just go knock
on the door and introduce yourself.
We offered tran...
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
...
IBM’s DevOps Center of Competency
Responsible to drive the transformation
• Lead by example
• We work the way we ask teams...
IBM CoC Approach
• Facilitate communication & collaboration
• Establish a Community (internal forums) to share what works ...
IBM CoC Approach cont.
• Invest in tooling
• Provide as a service
• Map business controls to DevOps techniques
• Does an e...
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 hour...
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 the...
Questions
Acknowledgements and Disclaimers
© Copyright IBM Corporation 2015. All rights reserved.
– U.S. Government Users Restricted...
Thank You
Your Feedback is
Important!
Access the InterConnect 2015
Conference CONNECT Attendee Portal
to complete your ses...
Divider slide
Upcoming SlideShare
Loading in …5
×

Creating a DevOps Team that Isn't Evil

1,259 views

Published on

DevOps seeks to tear down barriers between development and operations that lead to slower change and worse quality. Implementing a DevOps Team that adds yet another silo to an organization can be counterproductive. Rebranding infrastructure or operations teams as "DevOps" doesn't help, either. However, scaling DevOps benefits from a dedicated team. This session looks to answer key questions when building a team to enable DevOps transformations. What are common DevOps team structures? Are there existing groups that can lead the transformation? Who should I include on the team? What should its charter be?

This deck is from a session delivered at IBM Interconnect 2015.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Creating a DevOps Team that Isn't Evil

  1. 1. © 2014 IBM Corporation Creating a DevOps Team That Isn’t Evil Curtis Yanko - Cigna Eric Minick - IBM
  2. 2. 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
  3. 3. Evil?
  4. 4. And yet… 3 Slide from Stephen Elliot at #DOES14: http://youtu.be/9_ZuEhgTdLc?t=12m16s
  5. 5. Is the industry making a huge mistake?
  6. 6. The Plan • What Would Make a DevOps Team Evil? • A Success Story: DevOps Team at Cigna • Other Good Models • Q&A 5
  7. 7. The Plan • What Would Make a DevOps Team Evil? • A Success Story: DevOps Team at Cigna • Other Good Models • Q&A 6
  8. 8. Silos New silo = same old problems 7 Dev OpsDevOps HT: Matthew Skelton http://slidesha.re/1vOiHc4
  9. 9. 8 Rebranding – Declaring Success without any Doesn’t sound helpful
  10. 10. 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
  11. 11. The Plan • What Would Make a DevOps Team Evil? • A Success Story: DevOps Team at Cigna • Other Good Models • Q&A 10
  12. 12. Feedback From the System 11 Anti-Type C – “We Don’t Need Ops” Dev OpsSCM DevOps Patterns: Team Topologies – Mathew Skelton
  13. 13. The ‘Team’ was an Opportunity 12 To demonstrate something new
  14. 14. Two Ingredients for Change 13 Create an appetite for something new Create a distaste for the status quo
  15. 15. Tracer Bullet 14 A Battle Plan For DevOps in the Enterprise – Willie Wheeler
  16. 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. 17. 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
  18. 18. The Plan • What Would Make a DevOps Team Evil? • A Success Story: DevOps Team at Cigna • Other Good Models • Q&A 17
  19. 19. 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
  20. 20. 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
  21. 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. 22. 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
  23. 23. Success Story: Watson Analytics Continuous Delivery to SoftLayer in 15 minutes 22
  24. 24. 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
  25. 25. Standard Model for a Center of X DevOps Team 24 Dev OpsDevOps
  26. 26. 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
  27. 27. Questions
  28. 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. 29. 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.
  30. 30. Divider slide

×