This episode was streamed live from Agile meets Architecture conference.

In this episode, we discuss the multi-year journey of Circle K’s eMobility organization as it scales to support growth from Norway to European and global markets.

The eMobility organization began as a small team focused on validating the electric vehicle (EV) charging business in Norway. However, due to its success, it quickly had to shift from “validating to scaling” and expand to various countries and multiple products in an industry that is still in development.

Throughout the episode, Eduardo and Guro will share valuable “mistakes”, lessons learned, experiments, methods, and practices we have employed during this journey. We will particularly emphasize the importance of breaking down functional silos within the organization as a means to support sustainable scaling. Initially, we focused on overcoming the Product and Technology silos. Still, in time, we went further to develop truly cross-functional value streams, also involving and continuously engaging with marketing, sales, operations, and other disciplines, with the goal of defining the best ways to support the activities necessary for rapid and sustainable business growth.

Eduardo and Guro have employed various ideas and techniques, including Domain-driven Design, Team Topologies, Wardley Mapping, and others. However, you will see that there are no silver bullets. The secret is embracing this as a continuous improvement process, involving people with knowledge and expertise, maximizing learning, and empowering value streams and their teams to drive the necessary design and decision-making with a clear long-term vision.

• Architecture Modernization Enabling Team

• Independent Service Heuristics (ISH)

  • https://github.com/TeamTopologies/Independent-Service-Heuristics

  • https://teamtopologies.com/news-blogs-newsletters/2024/8/7/newsletter-ish-enhancing-modularity-and-autonomy

• Core Domain Charts

• Susanne Kaiser: Architecture for Flow

This episode was streamed live from Agile meets Architecture conference.

We all know it - our team has become too big, meetings take too long, half of the conversations don’t apply to our work, and the sprint goal is now “finish all stories in the sprint”! The classic textbook and the chatbot are certain: The team should be split!

And this is indeed the optimal solution. But real life isn’t a textbook, and our resources aren’t infinite. What if instead of slicing to be a-two-pizza-team, we asked the question: “What do we actually need to work well together?”

After over 4 years working with several large data science and engineering teams that wrestled with multiple variations of the same problem, we’ve resisted the urge to split by the book.

Instead of insisting on the one right way, we want to show you how tuning in, listening, and deliberately choosing the solution, can bring back the fun, ease and coveted efficiency we all are after.

That could mean: changing who does what in the team, redrawing team boundaries, or combining pragmatic approaches of multiple organizational design systems like LeSS, Team Topologies, and Fluid Teams.

The trick is to stop chasing the perfect model and start designing something that actually fits both the team’s culture and unique problem domain. Think of it like tailoring a suit: it has to fit the people wearing it, not just look good on a cover.

Der Informatik-Pionier Peter Naur formulierte 1985 in seinem Aufsatz “Programming as Theory Building” die These, dass Programmieren im Kern bedeutet, eine Theorie zu entwickeln – ein tiefes Verständnis eines Problems und seiner Lösung.

Diese Perspektive erklärt, warum Änderungen an bestehenden Systemen so schwierig sind, wie Legacy-Software entsteht und weshalb iterative Softwareentwicklung so wirkungsvoll sein kann.

In dieser Episode diskutiert Eberhard Naurs Überlegungen und setzt sie in Beziehung zu aktuellen Herausforderungen der Softwareentwicklung – etwa zur verbreiteten Vorstellung im Kontext generativer KI, Programmieren bestehe primär lediglich im Erzeugen von Code.

Links

• Programming as Theory Building

• Prof. Christiane Floyd zu “menschenzentrierter Software-Entwicklung”

• KI = Bullshit

• Software-Entwicklung = Lernen?

In dieser Episode spricht Lucas Dohmen mit Eberhard Wolff darüber, wie man Anwendungen aus dem Cloud-Angebot großer Hyperscalers wegmigriert. Er berichtet dabei aus der Praxis: Gemeinsam mit dem Team von fejo.dk, einem der meistgenutzten Portale für Ferienhäuser in Dänemark, hat er die Anwendung von Amazon Web Services (AWS) in die Hetzner Cloud umgezogen. Lucas erläutert, wie sie dabei vorgegangen sind, welche Vorteile es gibt, welche Herausforderungen sie lösen mussten und wie ein solcher Weg typischerweise aussieht.

Links

• Hyperscaler-Exit bei SWAGLab

• Frage zu Hetzner bei Mastodon

• Frage zu lokalen Points of Presence bei Mastodon

• Serverless Architektur mit Sascha Möllering

• LinkedIn Frage zu Kamal

Software architecture and organizational design are deeply interconnected. Conway’s Law captures this relationship, while the Inverse Conway Maneuver uses it to shape architecture through team structures. Team Topologies adds a practical model for designing effective team interactions and boundaries. This talk explores how organizational decisions directly influence architectural outcomes — and why integrating Team Topologies into your architectural strategy is probably critical. You’ll learn how purposeful team design can reduce cognitive load, improve system modularity, and create architectures that evolve more sustainably.

This episode is supported by Agile meets Architecture.

Soziotechnische Architektur Reviews mit Jonas Clusen und Hansjörg Gude In dieser Episode von Software-Architektur im Stream spricht Hansjörg Gude mit Eberhard Wolff über soziotechnische Architektur Reviews (STAR). Der Ansatz erweitert klassische Reviews um die organisatorische Perspektive. Das Ergebnis des Reviews zeigt, wie Teams, Kommunikation und Strukturen die Architektur beeinflussen. Gemeinsam diskutieren wir, wie STAR hilft, technische und soziale Spannungsfelder zu erkennen und daraus konkrete, wirksame Verbesserungen für Systeme und Organisationen abzuleiten - und wie durch den Ansatz Organisationen auch schon nachweisbar verbessert worden sind.

• STAR-Reviews

• Virtueller Kaffee mit Hansjörg, Jonas oder Eberhard

Dokumentation hat bei vielen keinen guten Ruf: zu aufwändig, zu trocken, zu weit weg vom eigentlichen Entwickeln. Häufig entsteht sie losgelöst vom Entwicklungsprozess, wird einmal geschrieben und danach kaum noch gelesen oder gepflegt. Statt ein lebendiger Teil des Produkts zu sein, veraltet sie stillschweigend.

Im agilen Manifest heißt es: “Funktionierende Software mehr als umfassende Dokumentation”. Diese Aussage wird oft als Aufruf verstanden, Dokumentation zu vernachlässigen oder ganz wegzulassen. Doch war das wirklich die Intention? Oder geht es vielmehr um eine neue Art von Dokumentation – zur richtigen Zeit, mit dem richtigen Fokus?

In diesem Stream geht es darum, wie Dokumentation im agilen Umfeld sinnvoll funktionieren kann: leichtgewichtig statt schwerfällig, integriert statt nachgelagert, hilfreich statt Pflichtübung. Es geht um Praxis, Haltung und konkrete Ansätze, um Teams durch Doku zu unterstützen, statt sie auszubremsen.

Persistenz ist kein Detail, sondern prägt die gesamte Architektur. In dieser Episode diskutieren wir den klassischen Mismatch zwischen objekt-orientierter Domänenlogik und relationalen Datenbanken, die Rolle von O/R-Mappern und die Bedeutung u.a. von Aggregates und Domain-driven Design.

Wir vergleichen relationale und NoSQL-Ansätze wie Dokumenten-Datenbanken und zeigen, warum unterschiedliche Persistenztechnologien zu unterschiedliche Architekturen führt.

• Folgen zu Konsistenz

• Taktisches Domain-driven Design

• Catalog of Patterns of Enterprise Application Architecture