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

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

IT has become indispensable in our business and private lives

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

And what do we do to tackle the problem?

We happily add more complexity

This session is about one of the culprits ...

Sensing the problem

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

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

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

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

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

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

And here we go again …

The challenge

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

Architecture never reaches an end state

There will always be multiple architectures

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

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

We need to design road movie architectures

Approaching a solution

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

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

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

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

Solution design

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

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

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

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

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!

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

Summing up

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

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

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