Architecture for flow: Scaling Decisions Without Centralising Control at DHL eCommerce BeNeLux @ DADD '26

As organisations scale, the tension between cohesion and team autonomy often defaults to centralisation: architecture boards and rigid approval gates that swap one bottleneck for another, stifling the delivery flow they were meant to protect.

At DHL eCommerce Benelux, scaling to 35 independent teams, we chose a radical alternative by dismantling the gatekeeping model entirely in favour of distributed thinking and Architecture for flow.

This session shares our journey from architecture as compliance to a collaborative practice enabled by architects: the Advice Process, collaborative modelling, and an honest look at the friction of decentralisation. A practical blueprint for architectural integrity that enables, rather than impedes, speed.

Transcript

1. Architecture for Flow: Scaling Decisions Without Centralising Control this is the story of what we did instead, including the parts that hurt. Kenny (Baas) Schwegler, Marc Rooding
2. Thank you 2
3. Our engineering culture came straight out of that film Entrepreneurship Pragmatism Can-do attitude See an opening, start the thing. Nobody waited for a mandate. Solve the problem in front of you, with what you already have. Say yes first, then work out the how along the way. 230 years of moving parcels was built on it. So were our software teams, each one solving the same problems in its own way. DHL | Architecture for Flow | Nieuwegein | October 2026 3
4. From 15 pioneers to 140 engineers in eight years 2018 4 years 2022 4 years 2026 15 pioneers 80 engineers 140 engineers Start-up phase 20 teams 35 teams The organisation grew nine times over. Nothing grew with it to connect the teams. DHL | Architecture for Flow | Nieuwegein | October 2026 4
5. Autonomy gave us speed, but few measures aligned the teams Speed without rules Free choice everywhere Limited impact architecture board One gate, at deploy time Decisions happened every day. Just not visibly, and not together. DHL | Architecture for Flow | Nieuwegein | October 2026 5
6. About us Marc Rooding Kenny Schwegler Director Architecture & Digital Strategy Team Lead Architecture (Enablement) • Co-author of Collaborative Software Design • Team Topologies Valued Practitioner DHL | Architecture for Flow | Nieuwegein | October 2026 6
7. “Questions about whether design is necessary or affordable are quite beside the point: design is inevitable. The alternative to good design is bad design, not no design at all.” — Douglas Martin DHL | Architecture for Flow | Nieuwegein | October 2026 7
8. We are not unique, so… What does the industry do to keep that cohesion? DHL | Architecture for Flow | Nieuwegein | October 2026 8
9. The default playbook TOGAF · SAFe When you scale, you centralise “control” to keep coherence. DHL | Architecture for Flow | Nieuwegein | October 2026 9
10. What TOGAF assumes The target state can be known. Decisions flow top-down. Design is a document. Define it up front, then plan the gap. A central board decides; projects conform. Signed off and contracted before anyone builds. None of the three held for a culture of 35 teams that learns by doing. DHL | Architecture for Flow | Nieuwegein | October 2026 10
11. A culture of freedom runs on action, not on more process Action & pragmatism More process How DHL works Will create policy resistance Try Learn Adjust Board Stage gate Sign-off Build worked around ▪ The knowledge is already in the teams ▪ Boards and gates get resented ▪ Transparency instead of approval ▪ Or quietly ignored ▪ Collaboration surfaces the best solution ▪ Compliance arrives before cohesion ▪ Enable teams, don't guard a gate ▪ Not what we believe in either DHL | Architecture for Flow | Nieuwegein | October 2026 11
12. “A method you must redesign before using isn’t really prescribing much.” DHL | Architecture for Flow | Nieuwegein | October 2026 12
13. The architecture paradox + Teams decide and ship at own speed + Parts fit: interfaces, data, flow – Fragmentation across boundaries – Local optimisation – Teams need to wait on central decisions DHL | Architecture for Flow | Nieuwegein | October 2026 13
14. How do you bring coherence to a culture built on freedom, without it feeling like freedom is being taken away? DHL | Architecture for Flow | Nieuwegein | October 2026 14
15. Three lenses 2. Visualizing the Current Business Landscape Wardley Mapping Domain-Driven Design Flow Team Topologies 3. Collaborative Software design with and by the teams 1. Focus on flow, not structure After Susanne Kaiser DHL | Architecture for Flow | Nieuwegein | October 2026 15
16. Focus on flow Small batches Steady pace Idea DHL | Architecture for Flow | Nieuwegein | October 2026 No waiting Customer 16
17. Blockers to flow Work piles up wherever it has to stop Handoffs DHL | Architecture for Flow | Nieuwegein | October 2026 Dependencies Waiting for approval Cognitive overload 17
18. The board became the biggest blocker, and teams route around it Architecture board Delivered One at a time Requests wait in line 35 teams The workaround: build it anyway, tell them later DHL | Architecture for Flow | Nieuwegein | October 2026 18
19. Architecture advice process DHL | Architecture for Flow | Nieuwegein | October 2026 19
20. Advice process: one rule Anyone — a development team member, or someone playing a cross-team role — can make options, decide which option to select, and communicate an architectural decision, as long as during the option-making stage they seek advice from: 1. Stakeholders: everyone who will be meaningfully affected by the decision 2. Consultants: people who have expertise in the area the decision is being taken DHL | Architecture for Flow | Nieuwegein | October 2026 You keep the decision You must seek advice, hear it, understand it and take it into account. You do not have to follow it. Nobody approves your decision and nobody signs it off. With that freedom comes accountability for the decision and for the people it affects. 20
21. We moved from corridor decisions and architecture board to an advice process in four steps 4 3 2 1 Architects lead by example Architects already took decisions, so they started to adopt the advice process. Start with a few teams Started within the foundation teams, which the architects where part of. DHL | Architecture for Flow | Nieuwegein | October 2026 Management trust Management accepted that the right thing would happen without approval. The board became an advice board. Advice process Teams decide bottom up after seeking advice, and record the decision for everyone to see. 21
22. Power games turn anarchy into chaos. Transparency keeps it anarchy. DHL | Architecture for Flow | Nieuwegein | October 2026 22
23. When teams start to adopt 01 Advice != opinion 02 Taking the decision is owning the decision 03 Some teams start while others don't will lead to resent DHL | Architecture for Flow | Nieuwegein | October 2026 Essentially, the architecture advice process is a social contract created on trust 23
24. The architecture board became an advice board, so teams could decide Before: a gate After: an advice board Architecture board Affected teams Advice board Experts decides for teams Teams Teams wait for its verdict. Team The team asks, weighs the advice and decides. Advice binds as input, never as approval. DHL | Architecture for Flow | Nieuwegein | October 2026 24
25. What this asks of leadership Leading for flow DHL | Architecture for Flow | Nieuwegein | October 2026 25
26. Every breakage cost trust, and lost trust caused the next breakage Organisation grows external driver − Team overview − of the whole process Breakages at deploy time − + R1 Manager trust in teams trust spiral − Shared why reasoning known − Central decisions fast, little input R1 Trust spiral • As the organisation grew, no team saw the whole process, so changes broke at deploy time. • Each breakage cost managers’ trust, so they decided centrally, on little input. • Teams never learned the why, so their overview shrank further. + moves in the same direction, − in the opposite direction. R = reinforcing loop. DHL | Architecture for Flow | Nieuwegein | October 2026 26
27. Unexplained decisions got reopened and pulled more decisions upward Organisation grows external driver − − Team overview Breakages of the whole process at deploy time − + R1 Manager trust in teams trust spiral − Shared why − reasoning known − Central decisions fast, little input R2 decision churn Decision churn new meeting, new outcome DHL | Architecture for Flow | Nieuwegein | October 2026 R2 Decision churn • Managers decided centrally, so teams knew what was decided, but not why. • Without the why, each new meeting brought new input and often a new outcome. • The churn kept decisions with managers. Both loops run through the missing why. + + moves in the same direction, − in the opposite direction. R = reinforcing loop. 27
28. Advice process as the leverage point Organisation grows external driver − − Team overview Breakages of the whole process at deploy time − Advice up front + the leverage point R1 Manager trust in teams trust spiral − + Shared why − reasoning known − Central decisions fast, little input R2 decision churn + Decision churn new meeting, new outcome DHL | Architecture for Flow | Nieuwegein | October 2026 28
29. Managers now give input early, and a veto tells us the process failed 1 Proposal 2 Advice 3 Written decision 4 Veto The owning team writes up the initiative and who it affects. Managers give input here, before anything is decided. We treat it as advice, not approval. Decision and reasoning on paper, so impacted teams see why, not just what. An escape hatch and a red flag. The manager should have been asked at step 2. We track every veto and run a retrospective. Written decisions moved the debate from “I know best” to facts nobody can deny. Trust took time, examples, and effort to rephrase managers’ opinions as input to the advice process. DHL | Architecture for Flow | Nieuwegein | October 2026 29
30. Leadership and organizational design principles Structure: someone is responsible No structure: nobody is responsible DP1 DP2 Laissez-faire Responsibility for coordination and control sits above the work Responsibility for coordination and control sits with the team doing the work Nobody is responsible for coordination and control Redundancy of parts Decisions are made for the team, and tasks are handed out. Redundancy of functions Teams decide within goals and budget negotiated with management. No design principle Decisions happen, nobody coordinates them. Looks like autonomy, behaves like chaos. The advice process is how we coordinate in DP2. Budget control still sits above the teams, so one foot stays in DP1 Merrelyn Emery, "The Current Version of Emery's Open Systems Theory", Systemic Practice and Action Research 13(5), 623–643, 2000. DHL | Architecture for Flow | Nieuwegein | October 2026 30
31. Autonomy and alignment: a polarity to manage, not a problem to solve Autonomy Alignment Upside Upside Teams own decisions and move fast Team decisions add up to one direction Overdone: laissez-faire Overdone: DP1 Decisions drift apart Control moves back above the team ADRs show where vision is missing. Providing it is management's job; vetoing isn't Polarity map after Barry Johnson, “Polarity Management”, HRD Press, 1992 DHL | Architecture for Flow | Nieuwegein | October 2026 31
32. Autonomy handed out by mandate is still a directive, with the burden moved onto the team. DHL | Architecture for Flow | Nieuwegein | October 2026 32
33. Autonomy is a container word, and it should be collaboratively defined Collaborative Software Design van Kelle, Verschatse, Baas-Schwegler DHL | Architecture for Flow | Nieuwegein | October 2026 33
34. Wardley mapping the landscape Architecture for Flow Susanne Kaiser DHL | Architecture for Flow | Nieuwegein | October 2026 34
35. Value chains + Team Topologies -> User needs maps DHL | Architecture for Flow | Nieuwegein | October 2026 35
36. User Needs Maps became the one diagram people want to see Light start Nothing demanded from teams. Diagrams only served decision making. The shift User Needs Maps showed the business flow, the what and the how, to management, business stakeholders and engineers alike. Today User Needs Maps are the only diagram we mandate, kept up to date together with teams every month. Alongside User Needs Maps we use C4 diagrams, but only the top two levels: context and container. DHL | Architecture for Flow | Nieuwegein | October 2026 36
37. The value is in the modelling session, not in the diagram DHL | Architecture for Flow | Nieuwegein | October 2026 37
38. With the three lenses in place, where does that leave us now? Our new bottlenecks, and how we keep improving them DHL | Architecture for Flow | Nieuwegein | October 2026 38
39. Victims of our own success Too few of us Wide impact Demand varies Upkeep slips Teams now require us instead of routing around us. Most big decisions cross domain boundaries. Requests and changes arrive unevenly. Monthly model syncs get pushed back. We can't do all architecture work. The capability must grow in the teams. DHL | Architecture for Flow | Nieuwegein | October 2026 39
40. We used the advice process to establish the advice process, then kept improving it SEPTEMBER 2025 Established: We decided our architecture approach through the advice process itself. SINCE THEN Experimenting: We keep testing and improving the process and the tooling around it. Quarterly DX survey: how often people take part “How many times in the past 3 months have you participated in the architecture advice process and/or architecture decision records?” ONGOING Listening: User interviews with many teams gave us feedback and tested our assumptions. OCTOBER 2026 Revalidated: We informed the architecture board on gathered feedback and revalidated their buy-in for the process. DHL | Architecture for Flow | Nieuwegein | October 2026 40
41. The effect of moving from central to decentral decision making 315 Architecture decision records created in about one year Ownership first The advice process settles many topics before a board meeting is needed What still hurts • Bypassing under deadline pressure • Tooling that doesn’t guide the process • Authors have a lot of responsibility (implicitly) What we’re changing Investing in a new decision system to remove these pain points What we would do differently • Write small ADRs together with teams, and sooner DHL | Architecture for Flow | Nieuwegein | October 2026 41
42. So the question is not who decides. It is how well the deciders are equipped. DHL | Architecture for Flow | Nieuwegein | October 2026 42
43. So, what is next? Enabling team and Platform ("ETAP") dynamic Team X Facilitating Team Y Enabling: what we do Team X • Facilitate teams learning architectural capabilities • Provide temporary facilitation and guidance • Clarify unclear domain boundaries between teams • Help teams become selfsufficient Architecture Team DHL | Architecture for Flow | Nieuwegein | October 2026 Over time Platform: what we provide • Architectural guidance and tooling as-a-service Team Y • Teams consume independently via clear interfaces XaaS • Self-service tools for autonomous decision-making Architecture Team • No ongoing coordination needed Platform grouping 43
44. The pushback we got "Our engineers aren't ready for big architecture decisions." "Then what's left for managers?" "People are used to being told. They won't take ownership." "Without control, this becomes chaos." DHL | Architecture for Flow | Nieuwegein | October 2026 44
45. “Start by writing one decision down, in the open. Where it's safe, and where it helps the team. Each one that works earns trust for the next.” DHL | Architecture for Flow | Nieuwegein | October 2026 45
46. Thank you Please provide us feedback-> DHL | Architecture for Flow | Nieuwegein | October 2026 46