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?

1. VUCAJoakim Lindbom
CTO | Chief Architect
Capgemini Scandinavia
Stockholm 2018-10-17

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. Be innovative!

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

6. Towards #ZeroDayForever

8. 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!

9. The market takes a turn

10. 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

12. What game are
you playing?

13. Roulette
or
Poker

14. DevOps is about increasing your
responsiveness to customers
DevOps

15. Devs → New features, fast!
Ops → Uptime, uptime & uptime

16. Devs → Uptime
Ops → New features, fast!
But what-if…
Or…. …should it be one joint team per system/service?

17. But what’s setting the pace?
The slowest component??!?

18. 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?

19. So pace layering it is, then?
Pace 1
Pace 2
Pace 3
?

20. 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

21. Are requirements any good?

22. #NoRequirements

23. Requirements?
If I had asked people what they wanted,
they would have said faster horses.
- Henry Ford

24. NO Requirements

25. “Any piece of software reflects
the organisational
structure that produces it”
Conway’s law:
Design-Build-Run

26. Waterfall
Req Analysis Design Build Run

27. 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….

28. 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

29. Open Data
Open APIs

30. Open Data
Tågtavlan
Tåg.info
Traffikverkets basdata

31. Open Data
Tågtavlan
Tåg.info
Traffikverkets basdata

32. 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

33. How to (not) buld for innovation

34. Mobile first…
API

35. Call for a
New Mindset

36. 5 year (release) plan ?
No more!

37. 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!

38. 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

39. 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...”

40. Don’t allow services to know anything
(but the APIs)
- Separate components
- Separate lifecycles
Loose coupling paw rihk-titt
Autonomous services

41. Go from
Deducted planning
to
Allowing opportunism
Changed mindset

42. 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

43. Go from
Assumed predictability
to
Creating serendipity
Changed mindset

44. Continuous Delivery, anyone?

45. Go from
Systems and project
to
Products
Changed mindset

46. Focus on
Ability to change
Don’t worry (too much) about the
target state
Changed mindset

47. Would you dare to cool?
or
How do you unleash enthusiasm?
#OpenSource mindset

48. You get what you meassure!
Metrics - KPIs

49. You become what you meassure!
Metrics - KPIs
Leadtime to value
Mean time to repair
Cycletime
Delivered business value

50. Case time!

51. Tablet based sales tool
+ Self serve App
+ End-user sales kiosk
Open-endedAPI

52. Tablet based sales tool
Releases/year Lead time to value
Before 4 9-12-15 month
Now 52 6 weeks

53. 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

54. 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

55. Why is smaller better?
Big releases Big dependencies Big risk! Big testing
Deployment
All or nothing
Big end-user
interference

56. 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

57. “The more I practice,
the more lucky I get”
- Ingemar Stenmark

58. API ≡ Integration
Right?
Utterly, fundamentally
Wrong!

59. 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

60. 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!

61. Summing up
Complicated problems require simple solutions

62. 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

63. 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

64. 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