Rational User Group - May 2014 Stockholm - DevOps from an EA perspective
Download as PPTX, PDF1 like655 views
The document discusses the necessity of DevOps in improving responsiveness and speed in software development, emphasizing that a lack of speed can hinder innovation. It highlights the complexity of IT systems and the need for simpler, modular approaches to enhance agility and reduce risks associated with software deployment. The importance of early bug fixing, frequent deployments, and continuous improvement are also underscored as key factors in modern IT practices.
Rational User Group - May 2014 Stockholm - DevOps from an EA perspective
- 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?
- 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!
- 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 [email protected] 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
Editor's Notes
- #5: (Computer in a RJ45 enclosure)Moore’s law – does your org follow it??!?
- #9: There are roughly 160 rooms, including 40 bedrooms, 2 ballrooms (one completed and one unfinished) as well as 47 fireplaces, over 10,000 panes of glass, 17 chimneys (with evidence of two others), two basements and three elevatorsNow 1.8 ha (bare minimum for the remaining buildings)Stairs with no endDoors ending in the façade at third floorBuilt without architecture – more or less totally unfunctional
- #10: William Thomson, 1st Baron KelvinA system will always strive towards more chaos, unless energy is added in order to lower chaos.Second law: An isolated system, if not already in its state of thermodynamic equilibrium, spontaneously evolves towards it. Thermodynamic equilibrium has the greatest entropy amongst the states accessible to the system.
- #16: Immediate testing and patching will need to be extremely speedy, automated and invisible (to the end-user)
- #17: Immediate testing and patching will need to be extremely speedy, automated and invisible (to the end-user)
- #19: Immediate testing and patching will need to be extremely speedy, automated and invisible (to the end-user)
- #21: Source: MITSloan Management Review – Research Report 20132013 Digital transformation global executive study and research project
- #34: Weeks of planning, people flown in, gather everybody 1 week
- #40: Horisaki – The object is not protected, the craftmen’s skills are. In order to keep knowledgeAdd new aspect area - Knowledge – to arch frameworks?If the architect doesn’t add this capability upfront, how can it be assured?