Creating a DevOps Team that Isn't Evil

30
© 2014 IBM Corporation Creating a DevOps Team That Isn’t Evil Curtis Yanko - Cigna Eric Minick - IBM

Transcript of Creating a DevOps Team that Isn't Evil

Page 1: Creating a DevOps Team that Isn't Evil

© 2014 IBM Corporation

Creating a DevOps TeamThat Isn’t Evil

Curtis Yanko - CignaEric Minick - IBM

Page 2: Creating a DevOps Team that Isn't Evil

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

Page 3: Creating a DevOps Team that Isn't Evil

Evil?

Page 4: Creating a DevOps Team that Isn't Evil

4

And yet…

Slide from Stephen Elliot at #DOES14: http://youtu.be/9_ZuEhgTdLc?t=12m16s

Page 5: Creating a DevOps Team that Isn't Evil

Is the industry making a huge

mistake?

Page 6: Creating a DevOps Team that Isn't Evil

6

The Plan

• What Would Make a DevOps Team Evil?• A Success Story: DevOps Team at Cigna• Other Good Models• Q&A

Page 7: Creating a DevOps Team that Isn't Evil

7

The Plan

• What Would Make a DevOps Team Evil?• A Success Story: DevOps Team at Cigna• Other Good Models• Q&A

Page 8: Creating a DevOps Team that Isn't Evil

8

Silos

New silo = same old problems

Dev OpsDevOps

HT: Matthew Skeltonhttp://slidesha.re/1vOiHc4

Page 9: Creating a DevOps Team that Isn't Evil

9

Rebranding – Declaring Success without any

Doesn’t sound helpful

Page 10: Creating a DevOps Team that Isn't Evil

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

Page 11: Creating a DevOps Team that Isn't Evil

11

The Plan

• What Would Make a DevOps Team Evil?• A Success Story: DevOps Team at Cigna• Other Good Models• Q&A

Page 12: Creating a DevOps Team that Isn't Evil

12

Feedback From the System

Anti-Type C – “We Don’t Need Ops”

Dev OpsSCM

DevOps Patterns: Team Topologies – Mathew Skelton

Page 13: Creating a DevOps Team that Isn't Evil

13

The ‘Team’ was an Opportunity

To demonstrate something new

Page 14: Creating a DevOps Team that Isn't Evil

14

Two Ingredients for Change

Create an appetite for something new

Create a distaste for the status quo

Page 15: Creating a DevOps Team that Isn't Evil

15

Tracer Bullet

A Battle Plan For DevOps in the Enterprise – Willie Wheeler

Page 16: Creating a DevOps Team that Isn't Evil

16

Problem Domain - Zero Touch Deploys

Build Deploy Test Release

Code

Config

Data

EnvSys

tem

De-c

om

posi

tion

In Scope

Value Stream

In Scope

Out of scope

Out of scope

Page 17: Creating a DevOps Team that Isn't Evil

17

Culture and Collaboration

No need to tear down silo’s just go knock on the door and introduce yourself.

We offered transparency and inclusion

Page 18: Creating a DevOps Team that Isn't Evil

18

The Plan

• What Would Make a DevOps Team Evil?• A Success Story: DevOps Team at Cigna• Other Good Models• Q&A

Page 19: Creating a DevOps Team that Isn't Evil

19

IBM – A global team of developers

Perth

CanadaToronto, Ottawa Montreal, Victoria

Haifa Rehovot

ChinaBeijingShanghaiXian

Yamato

Taiwan

ParisPornichet

KirklandSeattleFoster CitySan FranciscoSVL/San JoseAlmadenAgoura HillsIrvineEl SegundoCosta MesaLas Vegas

Bedford, MABedford, NHEssex Junction, VTWestboroughCambridgeLittletonMarlborough

CorkDublinGalway

IndiaBangalorePuneHyderabadGurgaonVizag

Cairo

Rome

Gold CoastSydney Canberra

Fairfax RaleighCharlotteLexington, KYAtlantaBoca RatonTampa

KrakowWarsaw

Sao Paulo

Malaysia

Delft

Stockholm

Boeblingen

SouthburyNew York CityPrincetonHawthorneEndicott

Moscow

Zurich

PittsburgPoughkeepsie

SomersYorktown HeightsHopewell Junction

Wayne

HursleyWarwickYork

EdinburghLondon / StainesMilton Keynes

PhoenixAustinDallasDublin

Rochester, MNBoulderDenver

Lenexa, KATucson

El Salto, MX

US 20,000

Canada 3,100

Latin America 600

EMEA 7,100

AP 11,800

Total 42,600

Page 20: Creating a DevOps Team that Isn't Evil

IBM’s DevOps Center of CompetencyResponsible 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 secsSWG Team can continuously collect & visualize correlated signal data in < 7 days

WhoWhatWow

Page 21: Creating a DevOps Team that Isn't Evil

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

21

Page 22: Creating a DevOps Team that Isn't Evil

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?

22

Page 23: Creating a DevOps Team that Isn't Evil

Success Story: Watson Analytics

Continuous Delivery to SoftLayer in 15 minutes

23

Page 24: Creating a DevOps Team that Isn't Evil

Environments

Manual Automated

GainDeploy Tests Deploy Tests

Test 4 hours 80 hours 20 min 3 hrs 96%

Staging8 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 SolutionRome, Italy

24

IBM SoftLayer

Monitor and Optimize

Rational Team Concert

Rational Quality ManagerRational Performance TesterIBM Security AppScan

SmartCloud Control Desk

IBM Application Performance Management

IBM Endpoint ManagerIBM Security QRadar®

IBM UrbanCode Deploy

IBM Workload Automation

• Production deployment in few hours• Change management process• Automated tests• No “black out” during update

Page 25: Creating a DevOps Team that Isn't Evil

25

Standard Model for a Center of X DevOps Team

Dev OpsDevOps

Page 26: Creating a DevOps Team that Isn't Evil

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

Page 27: Creating a DevOps Team that Isn't Evil

Questions

Page 28: Creating a DevOps Team that Isn't Evil

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.

Page 29: Creating a DevOps Team that Isn't Evil

Thank YouYour Feedback is

Important!

Access the InterConnect 2015 Conference CONNECT Attendee Portal to complete your session surveys from your smartphone, laptop or conference

kiosk.

Page 30: Creating a DevOps Team that Isn't Evil

Divider slide