Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

VUCA - Planning for the essentially unplannable in a disruptive world

34 Aufrufe

Veröffentlicht am

Existing approaches used in delivering IT and business solutions are overthrown when the planning horizon is becoming shorter and shorter. How do you success and avoid being disrupted?

Veröffentlicht in: Business
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

VUCA - Planning for the essentially unplannable in a disruptive world

  1. 1. VUCAJoakim Lindbom CTO | Chief Architect Capgemini Scandinavia Stockholm 2018-10-17
  2. 2. Joakim Lindbom CTO | Chief Architect Cloud, Northern Europe Joakim.Lindbom@capgemini.com +468-5368 3934 +46708-166404 twitter: JoakimLindbom http://www.slideshare.net/JoakimLindbom http://www.linkedin.com/in/joakimlindbom Who am I?
  3. 3. Be innovative!
  4. 4. We’ll se more change the next 5 years than the previous 100 in the auto industry. Ian Robertson, Chairman of Rolls Royce Chief of Sales and Marketing, BMW
  5. 5. Towards #ZeroDayForever
  6. 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!
  7. 7. The market takes a turn
  8. 8. 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. MIT Center for Digital Business and Capgemini Consulting
  9. 9. What game are you playing?
  10. 10. Roulette or Poker
  11. 11. DevOps is about increasing your responsiveness to customers DevOps
  12. 12. Devs → New features, fast! Ops → Uptime, uptime & uptime
  13. 13. Devs → Uptime Ops → New features, fast! But what-if… Or…. …should it be one joint team per system/service?
  14. 14. But what’s setting the pace? The slowest component??!?
  15. 15. Or is it rippling requirements? CoreCoreCore Partners BI/DW Service Integration Ext Services Portals Orchestration Req Solution Or your linear thinking? Or your control needs?
  16. 16. So pace layering it is, then? Pace 1 Pace 2 Pace 3 ?
  17. 17. The server don’t know what the consumer/client is doing One key to decoupling: REST Level 3 + HAL https://en.wikipedia.org/wiki/Hypertext_Application_Language It presents Resources and Links – but don’t prescribe how to use them
  18. 18. Are requirements any good?
  19. 19. #NoRequirements
  20. 20. Requirements? If I had asked people what they wanted, they would have said faster horses. - Henry Ford
  21. 21. NO Requirements
  22. 22. “Any piece of software reflects the organisational structure that produces it” Conway’s law: Design-Build-Run
  23. 23. Waterfall Req Analysis Design Build Run
  24. 24. Agile Req sprint Analysis sprint Design sprint Build Sprint 1 Run Build Sprint 2 Build Sprint 3 This is no joke. I’ve seen it….
  25. 25. Requirement refinement What kind of movements What direction Assumptions Start with the very high level and assumptions Simplest way to prove it? Prototype Learn & refactor Re-iterate Actual requirements Output, not input
  26. 26. Open Data Open APIs
  27. 27. Open Data Tågtavlan Tåg.info Traffikverkets basdata
  28. 28. Open Data Tågtavlan Tåg.info Traffikverkets basdata
  29. 29. Platform thinking - Use platforms – let someone else integrate & innovate - Create platforms – to allow for someone else to innovate - Enable future solutions without knowing what will be requested – dare to be opportunistic - Darwinistic API Economy - Survival of the fittest API
  30. 30. How to (not) buld for innovation
  31. 31. Mobile first… API
  32. 32. Call for a New Mindset
  33. 33. 5 year (release) plan ? No more!
  34. 34. Dual-speed / Bi-modal IT (or Quarto-modal…) - Decouple market facing IT from backend IT timewise - Plan for the very different levels of velocity Requirements synchronisation? Release & rollout synchronisation? The problem lies in synchronisation of lifecycles But don’t make you Legacy systems dull!
  35. 35. Platform thinking - Use platforms – let someone else integrate & innovate - Create platforms – to allow for someone else to innovate - Enable future solutions without knowing what will be requested
  36. 36. Autonomous services Create agnostic & autonomous services Should act as Lego bricks ”No, I didn’t plan for you to use red lego bricks with the yellow ones. You need to file a CR...”
  37. 37. Don’t allow services to know anything (but the APIs) - Separate components - Separate lifecycles Loose coupling paw rihk-titt Autonomous services
  38. 38. Go from Deducted planning to Allowing opportunism Changed mindset
  39. 39. OpenAPI & Open Data Lakes - Don’t ask for requirements! - Provide what could be needed – and iterate - Create Integrations & BI with a NoRequirements thought - Darwinistic API Economy - Survival of the fittest API
  40. 40. Go from Assumed predictability to Creating serendipity Changed mindset
  41. 41. Continuous Delivery, anyone?
  42. 42. Go from Systems and project to Products Changed mindset
  43. 43. Focus on Ability to change Don’t worry (too much) about the target state Changed mindset
  44. 44. Would you dare to cool? or How do you unleash enthusiasm? #OpenSource mindset
  45. 45. You get what you meassure! Metrics - KPIs
  46. 46. You become what you meassure! Metrics - KPIs Leadtime to value Mean time to repair Cycletime Delivered business value
  47. 47. Case time!
  48. 48. Tablet based sales tool + Self serve App + End-user sales kiosk Open-endedAPI
  49. 49. Tablet based sales tool Releases/year Lead time to value Before 4 9-12-15 month Now 52 6 weeks
  50. 50. Delivery, so far Old core (Legacy Java) New core (Openshift) Clients Mashup Flat API Sales tool (Tablet) Sales tool (Kiosk ) Consumer tool (Smartphone) Core Business logic Beautiful API MVP MVP Gradual dismantling and shutdown
  51. 51. Layers and qualities Old core (Legacy Java) New core (Openshift) Local solutions, fair solutions, External apps/formats/whatever 4/8 releases/year 50 releases/year When ready TTV Channel specific Narrow Throwaway? TTV Adaptive Data Quality Predictability Sustainability Cont Improv. Landscape Throwaway? Share Reuse Proactive Reactive Proactive Simplify Refactor Shrink Specific Really good Desired qualitiesRelease pace Attitude Attributes
  52. 52. Why is smaller better? Big releases Big dependencies Big risk! Big testing Deployment All or nothing Big end-user interference
  53. 53. Big releases Big dependencies Big risk! Big testing Deployment All or nothing Big end-user interference Why is smaller better? µ releases Few & small dependencies Contained risk Contained testing Deployment Only delta Blue/Green Minimal end-user interference APIs Outside-in service design Assume change Versioned deployment API lifecycle
  54. 54. “The more I practice, the more lucky I get” - Ingemar Stenmark
  55. 55. API ≡ Integration Right? Utterly, fundamentally Wrong!
  56. 56. Summing up Don’t plan for the unplannable Embrace #NoRequirements Embrace cloud Embrace OpenAPI & OpenData Build (on) autonomous services Demo and fail with MVPs. Hacking the future DevOps & Automation Use and build platforms Be opportunistic & darwinistic Build simple prototypes Make! Interact and learn
  57. 57. Summing up Don’t plan for the unplannable Embrace #NoRequirements Embrace cloud Embrace OpenAPI & OpenData Build (on) autonomous services Demo and fail with MVPs. Hacking the future DevOps & Automation Use and build platforms Be opportunistic & darwinistic Build simple prototypes Make!
  58. 58. Summing up Complicated problems require simple solutions
  59. 59. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. Not to be shared without prior written permission. Copyright © 2018 Capgemini. All rights reserved. People matter, results count. Contact Joakim Lindbom CTO | Chief Architect Cloud, Northern Europe Joakim.Lindbom@capgemini.com +468-5368 3934 +46708-166404 twitter: JoakimLindbom http://www.slideshare.net/JoakimLindbom http://www.linkedin.com/in/joakimlindbom
  60. 60. 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_photography_0 2.jpg https://c2.staticflickr.com/6/5058/5490790304_dc3d7c2b91_z.jpg http://www.dailymail.co.uk/tvshowbiz/article-1176568/Andrew-Sachs-thanks-Jonathan-Ross-Russell-Brand- boosting-career.html https://upload.wikimedia.org/wikipedia/commons/8/8b/CERN_Server.jpg http://www.manufacturing-operations-management.com/manufacturing/2014/10/smart-manufacturing-needs-a- real-time-integrated-enterprise.html http://www.3ders.org/images/Dizingof-math-arts-3d-printing-2.png https://upload.wikimedia.org/wikipedia/commons/8/8a/Long_tail.svg
  61. 61. Image sources, marked as OK to use commercially https://upload.wikimedia.org/wikipedia/commons/6/61/Irish_jaunting_car,_ca_1890-1900.jpg https://upload.wikimedia.org/wikipedia/commons/thumb/1/1a/Lego_dimensions.svg/2000px- Lego_dimensions.svg.png https://upload.wikimedia.org/wikipedia/commons/1/1f/Feel_the_music.jpg https://upload.wikimedia.org/wikipedia/commons/thumb/b/bb/BestBeforeDate.png/640px-BestBeforeDate.png https://images-na.ssl-images-amazon.com/images/I/51dTFVDHRbL.jpg https://i.vimeocdn.com/video/574720083_1280x720.jpg

×