Ingo spricht beim TechRiders Festival in Köln 2026-06-17 - 18. Mit Code ARCH-TECHRIDER-2026 ist die Teilnahme kostenlos für End-Benutzer/ „Anwender:innen“.
Lars spricht beim iSAQB Software Architecture Forum. Mit dem Code SATV15SAF gibt es 15% Rabatt.
]]>We clarify the differences between LLMs, Generative AI, and other AI methods — and where each actually creates value. From there, the focus shifts to architecture: how to safely integrate probabilistic AI into systems that require reliability, precision, and control.
Finally, we generalize these lessons beyond industry, showing how choosing the right tool for the right problem leads to better outcomes in any domain.
Nikita will talk at the TechRiders Summit in Cologne. Register for FREE with the rebate code ARCH-TECHRIDER-2026 .
What interested them most about this book was the section “Constructive Anarchism: Alternative Communities and Programs”. This covers the how of anarchist organization.
They will share some of the most interesting insights from their perspective as a student of socio-technical organization design. Sometimes they’ll add some commentary. And of course the question is how it relates to software engineering.
Den vollmundigen Versprechen mancher Anbieter und Influencer für generative KI steht die praktische Realität gegenüber, dass die Beschränkungen von LLMs zu vielen Problemen führen, ganz besonders beim Softwareengineering. Die Analyse großer Softwarearchitekturen und Codebasen durch LLMs scheitert unter anderem an dem beschränkten Kontextfenster der Foundation-Modelle. Das gilt im Umkehrschluss auch für deren Generierung. Wie sich diese Problematik zumindest teilweise umgehen lässt, möchte der Sprecher anhand geeigneter Techniken zeigen.
In dieser Episode schauen wir uns die Independent Service Heuristics (ISH) aus dem Team-Topologies-Umfeld an. Sie liefern einfache, aber wirkungsvolle Fragen, um zu beurteilen, ob ein „Ding“ als eigenständiger Service funktionieren kann.
Wir diskutieren, wie diese Heuristiken helfen, Domänengrenzen greifbarer zu machen, warum sie besonders gut mit Business-Expert:innen funktionieren und wo ihre Grenzen liegen. Ein pragmatischer Ansatz für alle, die bessere Services schneiden wollen – ohne sich in Abstraktionen zu verlieren.
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.
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.
]]>