Road-movie architectures

This slide deck is about one of the drivers of accidental complexity in IT, I often see: The current target architecture of a company, often embedded in big technical transformation initiatives with the goal to "get rid of the existing mess for good" and eventually result in a nice, superior, homogeneous system landscape.

While the idea sounds nice in theory, in practice these initiatives are never completed, but are being replaced by a new target architecture, piling up more and more complexity.

Hence I continue, the better approach is to accept that our system landscapes will always be heterogeneous to a certain degree and design systems that do not only work nicely with other systems of the same kind, but with all kinds of systems that are there.

Then I present a few desirable properties of such systems and some ideas how to implement them. The list is not complete by any means, but is meant as a starting point for further discussion.

As always, the voice track is missing (but I hope a recording of this talk will be published soon). Still, I hope it gives you a few ideas to ponder and maybe even some new ideas that you want to share with the community.

Transcript

1. Road movie architectures
   A different perspective on architectural design
   Uwe Friedrichsen – codecentric AG – 2019- 2022
   

   View Slide

2. Uwe Friedrichsen
   Works @ codecentric
   https://twitter.com/ufried
   https://www.speakerdeck.com/ufried
   https://ufried.com/blog/simplify_intro/
   

   View Slide

3. IT has become indispensable in our business and private lives
   

   View Slide

4. In IT, we are drowning in complexity
   and every day it becomes a bit worse
   

   View Slide

5. And what do we do to tackle the problem?
   

   View Slide

6. We happily add more complexity
   

   View Slide

7. This session is about one of the culprits ...
   

   View Slide

8. Sensing the problem
   

   View Slide

9. Current target architecture
   • Many companies have a target architecture
   • Either implicit or explicit
   • Default for all new development projects
   • Usually strongly influenced by current fashions
   • Usually targets an ideal “end state”
   • Will unfold full benefits after entire conversion of IT landscape
   • Often accompanied by big transformation initiatives
   

   View Slide

10. Reality check
    • Target architectures change over time
    • Transformation initiatives are never completed
    • IT landscapes never become fully homogeneous
    • Promised benefits of ideal “end state” never fully unfold
    • Deviations from the target architecture are the norm
    • The Pareto principle (80/20 rule) strikes surprisingly often
    • Silent deviations often go undetected for a long time
    

    View Slide

11. The complexity trap
    • Aiming for an ideal “end state” increases complexity
    • Layers of incomplete implementations add to IT landscape
    • Different target architectures usually do not play well
    with each other
    • IT landscape complexity grows disproportionally
    • Everything and everyone suffers
    • Understandability, reliability, maintainability, evolvability, …
    • Growing headaches for the people involved
    

    View Slide

12. “We know our current landscape is a mess.
    But with this new initiative, we will clean it up for good.”
    

    View Slide

13. Until the next CIO abandons the initiative midway
    and starts a new, “better” initiative
    

    View Slide

14. Or the new fashion appears to be so much better
    that we push for a new target architecture
    

    View Slide

15. And here we go again …
    

    View Slide

16. The challenge
    

    View Slide

17. We need to accept that eventually reaching an “end state”
    when the whole IT landscape homogeneously conforms to
    a given target architecture is an illusion
    

    View Slide

18. Architecture never reaches an end state
    

    View Slide

19. There will always be multiple architectures
    

    View Slide

20. We need to take the diversity of our IT system landscape
    into account when designing solutions
    

    View Slide

21. We need to design our solutions in a way they become
    "good citizens" of a heterogeneous system landscape
    

    View Slide

22. We need to design road movie architectures
    

    View Slide

23. Approaching a solution
    

    View Slide

24. Desirable solution properties
    • Collaborative and inclusive
    • Simple to interact with (from the perspective of other systems)
    • Traveling light
    • Simple to be removed (from the IT system landscape)
    • Topical and flexible
    • Keeping its value, aging slowly
    

    View Slide

25. Collaborative and inclusive
    • Simple to be used by other systems
    • Integration first system design
    Benchmark
    Ø The application can be used from another application
    in less than a day
    

    View Slide

26. Traveling light
    • Simple to be removed from the IT system landscape
    • Construction for deconstruction (C4D)
    Benchmark
    Ø The application can be shut down and removed within 1 day
    while keeping the remaining system landscape intact
    

    View Slide

27. Topical and flexible
    • Maintaining its business value over time
    • Preserving its changeability and evolvability
    Benchmark
    Ø The application can still be evolved easily after 20 years,
    i.e., changes do not take longer and are not riskier
    than a year after the application's first release
    

    View Slide

28. Solution design
    

    View Slide

29. Collaborative and inclusive
    • Minimal, well-documented APIs
    • Not only API reference but also concepts, tutorials, how-to, …
    • Keep need for synchronous responses low
    • At the functional level, not necessarily at the technical level
    • Offer fallback integrations that older systems can also use
    • Not all systems talk REST, GraphQL, Events, gRPC or alike
    

    View Slide

30. Traveling light (1/2)
    • Plan the systems with its removal in mind
    • Work hard for good functional design with low coupling
    • Make global dependencies explicit and keep them minimal
    • Keep APIs minimal (and design them usage-driven)
    • Think in flows (behavior and data), not state and entities
    

    View Slide

31. Traveling light (2/2)
    • Document well what the system does (but keep it concise)
    • Document how to shutdown and remove the system
    • Plan how to remove data that is used locally only
    • Consider stepwise shutdown
    • Reserve time to continually simplify your landscape
    

    View Slide

32. Topical and flexible (1/2)
    • Understand the domain
    • Follow the “low coupling, high cohesion” principle
    inside the application/service, too
    • Create dependable and secure systems
    • Create the simplest solution possible
    without compromising dependability
    

    View Slide

33. Topical and flexible (2/2)
    • Document your system for those who will follow
    • High-level functional structure
    • Architectural style
    • Core principles and idioms
    • (Non-obvious) design decisions
    • Avoid fashions – use boring technology instead
    • Manage technical debt – and throw things away!
    

    View Slide

34. Additional considerations
    • Observe system obsolescence
    • Watch functional fitness and ease of evolvability
    • Monitor tool chain dependencies
    • Limit access to (out)dated systems
    • Makes removal simpler
    • Many solution options rooted in organization and processes
    • Money is not the constraint
    

    View Slide

35. Summing up
    

    View Slide

36. Summing up
    • Ideal “end state” of a target architecture is an illusion
    • Aiming for a homogeneous “end state” increases complexity
    • Accept heterogeneity in your system landscape
    • Take diversity into account when designing solutions
    • Design road movie architectures
    • Collaborative and inclusive
    • Traveling light
    • Topical and flexible
    

    View Slide

37. "Ultimately, design is a tool to enhance our humanity”
    -- Ilse Crawford
    

    View Slide

38. Uwe Friedrichsen
    Works @ codecentric
    https://twitter.com/ufried
    https://www.speakerdeck.com/ufried
    https://ufried.com/blog/simplify_intro/
    

    View Slide