How could DevOps help major corporations break out of the legacy problem? Why is rapid deployment needed to go for an agile delivery?

1. Rational User Group
2014-05-06
Joakim Lindbom
Principal | Enterprise Architect

2. Today’s themes
- Why do you need DevOps?
- Squish’m bugs early!
- Why do you need to deploy 10
times/day?

3. Now, what’s this?

4. Speed Kills!

5. Speed Kills!

6. 0
10
20
30
40
50
60
70
80
90
100
2001 2003 2005 2007 2009 2011 2013 2015
Best & Beautiful
A Inc
B Inc
C Inc
Lack of speed kills!

8. The amount of
caos increases
by itself
Termodynamics
2:a main law

9. DevOps is about increasing your
responsiveness to customers

10. Devs  New features
Ops  Uptime, uptime & uptime
But – whatif Devs were meassured on uptime & Ops
on new features? Just a thought….

11. Squish’m bugs early!
Why? Because Early = Cheap

12. Reqs
Specify
system
Build SW
Design
system
Write
code
Build
system
Install
system
Test
Reqs
Test
Specs
Integr.
test
Test
design
Unit test
System
test
UAT
Design-Build-Run approach
A bit too waterfallish

13. Reqs
Specify
system
Build SW
Design
system
Write
code
Build
system
Install
system
Test
Reqs
Test
Specs
Integr.
test
Test
design
Unit test
System
test
UAT
Design-Build-Run approach
A bit too waterfallish

14. Cloud = access to abundance

15. Cloud = access to abundance
You can have as many development, test & staging
environments as you like!
But you cannot handle this manually!

16. http://www.capgemini.com/resources/world-quality-report-2013-14

17. Zero-Day forever
Your time to react on errors will approach ZERO
Will become reality with the growing mobile market and IoT.

18. Big IT  Slow IT
(not slow as in slow food….)

19. 3% 2% 3% 3%
12%
10% 8% 8%
39%
33%
25%
22%
36%
42% 43%
46%
12%
15%
22% 23%
CEO/ President/
Managing Director
C-Level executives and
board members
Managers Staff
Very Fast Fast About right Slow Very Slow
How slow is slow?OFF THE PACE
The pace of digital transformation is too slow – unless you’re the CEO.
Who are these
guys?!?
MIT Center for Digital Business and Capgemini Consulting

20. IT Legacy is #1 obstacle for innovation
Major corporations depend on core systems that
- Are 15-20 years old
- 3-4 persons know
- Some staff is retired, some will be it within 4-5 years
- Technology support is slow
- Are somewhat documented
- Have few formal test cases, but the staff know how to
test
Application
Landscape
Report 2014

21. IT Legacy is #1 obstacle for innovation
Major corporations depend on core systems that
- Are 25-45 years old
- 1-2 persons know
- All staff are retired, or will be it within 2-3 years
- Technology support is gone
- Are undocumented
- Have no/few formal test cases
Application
Landscape
Report 2014

22. The ability to innovate
is strictly coupled with
the ability to fail fast

23. Ten Observations on IT Complexity
1. Most IT systems are too complex.
2. "Best Practices" increase complexity.
3. Complex systems cost more to build.
4. Complex systems are harder to deliver.
5. Complex systems are less secure.
6. Complex systems are less reliable.
7. Complex systems are less agile.
8. Complex systems cost more to run.
10. Existing management approaches ignore complexity.

24. But what is SimpleIT?
1. Non complex
2. Small building blocks
3. Autonomous
4. They “know nothing”
5. Service based
6. Dynamic
7. Like lego bricks
8. Expose an OpenAPI
10. Connect development and operations

25. But what is SimpleIT?
Simplified
Modularised
Optimised
Hardened

26. Autonomous system?
Totally separate parts
Separate lifecycle!
Loose coupling paw rihk-titt

27. System
Stuff Data
Autonomous system?
We used to look at it from a technical boundaries
perspective

28. System
Stuff Data
DevsArchitect Ops
Autonomous system?
But in order to unsure agilit, we need to include
the people in the system definition

29. System
Stuff Data
DevsArchitect Ops
OpenAPI
Autonomous system?
OpenAPI mindset = not a solution design for a
specific purpose/project. Open for Innovation

30. ~Autonomous system?
Release = just a mountain to climb…

31. Basics, get things in order
Ad-hoc deployment
Structured & planned releases
Major event
Major RISKMajor hurdle

32. Climbing a Release-mountain, how many people
experience it…

33. Industrialisation of IT
IT development more and more viewed as
"manufacturing"
Square boxes, repeat over and over
IT is innovationMistake!

34. How good is good?
Compileable?
No warnings?
Runnable?
Passing tests?
Not breaking anything else?
When your developers check in code, how
good does it need to be?

35. Deploy 10 time per day
How will that help you?

36. Deploy often
Shorten feedback-loop
Bring back passion – show visible result early
Allow (small) failures
Allow experimentation
Follow Moore’s law
Learn by doing
But deploying often doesn’t mandate
deploying to production equally often!

37. Deploy often
Basis for Continuous Improvement
Slow break-down into µServices
Gradual transition towards smaller building
blocks

38. Continous improvement
Continuous rebuilding
Always. Even if “not needed”

39. Summing up
DevOps – increase responsiveness
Lack of speed kills
Simplify, make smaller & rebuild – to fight
complexity
Big kills!

40. Contact
Joakim
Lindbom
Principal | Enterprise Architect
Joakim.Lindbom@capgemini.com
08-5368 3934
0708-166404
twitter: JoakimLindbom
http://www.slideshare.net/JoakimLindbom
http://www.linkedin.com/in/joakimlindbom
Insert contact
picture

41. Image sources, marked as OK to use commercially
https://upload.wikimedia.org/wikipedia/commons/8/8b/Buck_Mountain_Grand_Teton_NP1.jpg
https://upload.wikimedia.org/wikipedia/commons/d/de/Eisklettern_kl_engstligenfall.jpg
https://c1.staticflickr.com/1/1/1118807_a751d65ba5_z.jpg?zz=1
https://upload.wikimedia.org/wikipedia/commons/4/4f/Eternal_clock.jpg
https://c1.staticflickr.com/9/8062/8189938256_2a683d2334_z.jpg
https://upload.wikimedia.org/wikipedia/commons/8/85/Git_branches_example.png
https://upload.wikimedia.org/wikipedia/commons/9/99/Highway_at_night_slow_shutter_speed_ph
otography_02.jpg
https://c2.staticflickr.com/6/5058/5490790304_dc3d7c2b91_z.jpg