Killing the ivory tower: how Jumbo rebuilt architecture around teams and not titles!

Main Ideas, Concepts, and Lessons

• “Ivory tower” architecture is obsolete

  • Architecture should be democratized: not owned by a single architect role, but enabled through collaboration, shared models, and team ownership.
  • Engineers should “think like architects”; teams should take responsibility for placing changes in the right part of the system.

• Modernization changes the architecture problem

  • Early phase: shift from two large monolithic systems to microservices (motivated by scale and hiring growth).
  • Current phase: with many services, changes become harder; the organization now restructures for faster, safer delivery using a sociotechnical view (technology + communication + people).

• Silos create architectural decay (Conway’s Law)

  • During “big picture event storming,” they discovered multiple microservices for similar concerns (e.g., “shares/stocks”).
  • Root cause: teams operate in silos with no communication channels, leading to duplicated functionality.

• Use architecture workshops to onboard and align teams

  • They run structured exercises to help developers understand:
    • how the system creates and fulfills business flows (order flow),
    • boundaries and responsibilities,
    • and where cognitive load is coming from.

• Cognitive-load mapping + simplified core domain mapping

  • Teams write “everything” onto stickers:
    • could be infra, functions, microservices, or support elements causing cognitive load.
  • They group stickers to reveal different team perspectives and inconsistent language.
  • They capture:
    • action points / suggestions
    • problem areas
  • They then define general levels (e.g., support vs. base) and decide roadmap items using C4 and ADRs.

• Keep diagrams useful by tying them to specific purposes

  • Instead of diagramming the whole landscape everywhere, they create diagrams for:
    • a particular scenario/flow (e.g., order flow),
    • only the services that matter for that scenario.
  • This creates a direct path to update and reason about change.

• Documentation staying accurate: link C4 to operations

  • They use C4 diagrams with IcePanel to keep them synchronized and updated.
  • They link C4 charts to incident management/support:
    • during production incidents, responders can follow the flow diagram to identify which services/components are impacted.

• C4 usage guidance: mostly “container” level

  • They primarily use C2 (container level) because:
    • higher-level context changes less often,
    • code-level diagrams/UML are not helpful due to constant code change.
  • This helps teams understand impact across ownership boundaries.
  • Changes at C2 typically require updating ADRs and stakeholder communication.

• Team transformation (flow-oriented) is hard culturally

  • Transition from technology-labeled teams (SAP team, integration team, X-tech team) to flow-oriented structures.
  • Mostly bottom-up transformation:
    • listen to teams’ biggest challenges quarterly,
    • form guilds/chapters to align on concepts (flow rate, command topology, etc.),
    • then use success stories to win management support.
  • They balance change effort across domains:
    • not everything should be transformed identically (e.g., SAP ecosystems may require different approaches).

• Friction management: aim for “happy medium,” not 100% uniformity

  • Not all teams can follow the same model; they negotiate compromises (e.g., stream-oriented with different mindset).
  • Transformation is “not a one-way door”—they can adjust course per scenario.
  • Key recommendation: classify and isolate subdomains so different domains can use different architectural characteristics and cultures appropriately.

• Collaborative modeling + cross-cutting work

  • For features spanning multiple domains:
    • they use a technical leadership group (lead engineers + architects), biweekly + asynchronous collaboration.
    • they also use workgroups: temporary meta-teams for 6–8 weeks to implement cross-domain requirements without dismantling established streams.

• AI noise vs. practical adoption

  • They avoid “shove AI everywhere” thinking.
  • They use a layered approach:
    1. customer-facing applications (slower change, more risk)
    2. internal applications (faster, still controlled)
    3. developer experience (highest readiness; output still fed into deterministic systems)
  • They experiment with AI for documentation/ADRs and agentic workflows, but prioritize safeguards.

• Agent engineering process (pipeline)

  • Instead of plain prompting, they use an agent workflow with checks/challenges and style constraints.
  • Example pipeline:
    • Analyst agent: reads tickets (e.g., Jira) and produces requirements + action plan.
    • “Rubber duck” agent: experienced reviewer that challenges trade-offs and refines the plan.
    • Architect agent: checks existing ADRs and ensures the proposed change aligns with prior decisions.
    • Executor: implements and tests the change.
  • They use “skills” and context to enforce company-specific coding/style conventions (e.g., API style, naming conventions, error handling patterns).

• Why engineers accept agents

  • Juniors/mids initially fear replacement, or skeptics doubt quality.
  • With agent workflows plus skills:
    • engineers feel more senior because they challenge and validate outputs,
    • PR review quality improves (comments become more thoughtful),
    • and output quality increases when the agent has the right context.

• Deterministic + probabilistic systems: keep the best tools

  • They see value in combining:
    • deterministic tooling (e.g., Dependabot, reliable checks),
    • with probabilistic/agentic components.
  • They split AI adoption decisions by scenario and avoid opening probabilistic systems directly to customers too early.
  • They experiment with AI-augmented workflows (e.g., analysis converting natural language to SQL, campaign impact analysis).

---

Methodologies and “How They Do It” (Detailed)

A) Onboarding & Boundary Finding Workshops

• Run Big Picture Event Storming (Alberto Brandolini concept)
  • Focus on a key end-to-end flow (e.g., order flow).
  • Invite relevant business teams.
  • Observe duplication and silos (e.g., multiple services for “shares/stocks” with no coordination).
  • Use findings to diagnose Conway’s Law symptoms.

B) Simplified Core Domain Map Exercise (inspired by Nick Thune / OO design community)

• Steps:
  • Write everything that causes cognitive load onto stickers:
    • infrastructure, functions, microservices, support tasks.
  • Group stickers together:
    • reveal different perspectives and even different vocabulary usage.
  • Record:
    • action points / suggestions
    • problem areas (treated as most important notes).
  • Classify and define roadmap levels:
    • support level vs base level
    • prioritize return on investment.
  • Create/adjust:
    • C4 models to represent decisions/impact
    • ADRs when changes affect other teams.

C) Keeping C4 Documentation Accurate and Actionable

• Use IcePanel to manage C4 diagram sync:
  • update once → all diagrams stay consistent (avoid duplicate objects).
  • maintain up-to-date charts without manual reconciliation.
• Tie diagrams to real operational needs:
  • link C4 charts to incident management / support workflows.
  • responders follow scenario diagrams to identify impacted services even if service names are confusing.

D) Architectural Decision Governance at C2 Level

• Prefer C2 (container-level) diagrams:
  • show app/system interaction and ownership boundaries.
• When teams implement changes at C2:
  • update ADRs
  • ensure stakeholder communication stays aligned.

E) Team Restructuring Approach (Flow-Oriented Transformation)

• Overall approach: mostly bottom-up
  • Avoid “broken telephone” loss of intent that happens when decisions are purely top-down.
• Steps:
  • Identify key stakeholder challenges:
    • conduct one-on-one sessions with senior developers (not necessarily all, but majority)
    • compile feedback into a list of blockers
  • Hold feedback sessions quarterly to keep the roadmap current.
  • Introduce new conceptual structure:
    • chapters for new concepts (e.g., flow rate, command topology)
    • guilds to practice/align on terminology and practices.
  • Build a shared language across teams:
    • flow-oriented team vs subsystem complexity vs support teams.
  • Test restructured domains/subdomains with the business:
    • use success stories to secure broader support.
  • Allow flexibility:
    • compromise where domain ecosystems (e.g., SAP) don’t align cleanly.
    • treat transformation as reversible/adjustable when needed.

F) Cross-Domain Feature Implementation (Workgroups)

• Maintain:
  • a technical leadership group (biweekly + asynchronous).
• Use temporary workgroups for cross-cutting changes:
  • time-box: 6–8 weeks
  • include staff from multiple domains/streams
  • outcomes:
    • requirements + action plan
    • implementation without destroying existing team organization.

G) Agent Engineering Workshop & Agent Workflow Pipeline

• Run an “agent engineering workshop” to enable adoption across teams.
• Steps in agent workflow:
  • Analyst agent reads tickets (e.g., Jira via MCP tools)
  • Rubber duck agent challenges plan with trade-offs/pros-cons questions
  • Architect agent validates against ADRs and governance
  • Executor implements and tests
• Key technical point:
  • use “skills” + company rules so generated code matches internal standards (not generic output).

H) AI Adoption Principles (Anti-“AI for Everything”)

• “Slow down” if someone proposes AI immediately.
• Question:
  • Can you solve it without probabilistic systems?
• Apply layered risk/readiness framework:
  • customer-facing → slower, more guarded
  • internal apps → higher readiness
  • developer experience → highest readiness (still ends in deterministic systems)
• If probabilistic AI is used internally:
  • ensure safeguards and keep it close/controlled.

---

Sponsors / Tools Mentioned

• IcePanel (collaborative design/modeling tool)
  • mentions features: threads, diagram synchronization, IcePanel API/MCP server
• Mentions:
  • MCP (Model Context Protocol) integration with LLMs/agents
  • Jira (Atlassian)
  • Dependabot (deterministic dependency updates)

---

Speakers / Sources Featured

• Onur — Lead/Staff Engineer, Technical Lead at Jumbo Supermarkten (main guest)
• Luke — host/interviewer (Architect Podcast)
• Jacob (IcePanel) — representative from IcePanel (brief interruption/sponsor segment)
• Alberto Brandolini — referenced for “big picture event storming”
• Nick Thune — referenced for “core domain map” exercise
• Conway’s Law — referenced as the explanation for silo-driven duplication