Diese englischsprachige Folge des Videocasts software-architektur.tv widmet sich der Frage, warum das klassische Aufteilen zu großer Teams nicht immer der beste Weg ist – und welche Alternativen es gibt. In der live von der Konferenz „Agile meets Architecture“ gestreamten Episode spricht Eberhard Wolff mit Tsvetelina Plummer und Pricillia Gunawan über das Thema „Splitting without Splitting“.

Das Szenario kennen viele Entwicklungsteams: Die Gruppe ist zu groß geworden, Meetings ziehen sich, die Hälfte der Gespräche betrifft nicht mehr die eigene Arbeit, und das Sprint-Ziel lautet nur noch „alle Stories im Sprint abschließen“. Die Lehrbuchantwort auf diese Probleme und auch der Chatbot sind sich einig: Das Team muss aufgeteilt werden.

Statt diesem Standardrezept zu folgen, haben sich Tsvetelina Plummer und Pricillia Gunawan die Frage gestellt: „Was brauchen wir eigentlich, um gut zusammenzuarbeiten?“ Hintergrund sind ihre über vier Jahre gesammelten Erfahrungen mit mehreren großen Data-Science- und Engineering-Teams, die mit verschiedenen Varianten desselben Problems gerungen haben – und dabei bewusst auf ein Splitting nach Lehrbuch verzichtet haben.

Maßanzug statt Modell von der Stange

Statt auf dem einen richtigen Weg zu bestehen, zeigen Tsvetelina Plummer und Pricillia Gunawan im Gespräch mit Eberhard Wolff, wie gezieltes Zuhören und bewusstes Auswählen von Lösungen Effizienz und Freude an der Arbeit zurückbringen können. Dabei geht es konkret um folgende Ansätze:

• Verändern, wer im Team welche Aufgaben übernimmt.
• Teamgrenzen neu ziehen.
• Pragmatische Kombination mehrerer Organisationsmodelle wie LeSS, Team Topologies und Fluid Teams.

Die zentrale Botschaft: Statt einem perfekten Modell nachzujagen, sollten Teams etwas gestalten, das tatsächlich zur eigenen Kultur und zur spezifischen Problemdomäne passt. Tsvetelina Plummer und Pricillia Gunawan vergleichen das mit einem Maßanzug: Er müsse den Menschen passen, die ihn tragen, und nicht nur auf einem Cover gut aussehen.

Wer mehr zum Thema erfahren und Tsvetelina Plummer und Pricillia Gunawan live auf der Bühne erleben möchte, kann sich auch ihren Vortrag am 10. März auf der Konferenz Agile meets Architecture in Berlin ansehen. Eberhard Wolff bietet dafür einen speziellen Rabattcode für seine Zuschauerinnen und Zuschauer.

Livestream am 10. März

Die Folge wird am Dienstag, 10. März 2026, live ab 12 Uhr von der Konferenz Agile meets Architecture gestreamt. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, iX-Blogger und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren berichtet heise Developer über die Episoden.

(map)

Auf der neuen Website npmx.dev können Entwicklerinnen und Entwickler nach npm-Paketen suchen sowie deren Quellcode anzeigen lassen. Die Seite ähnelt damit npmjs.com, soll jedoch kein Ersatz dafür sein. Das Open-Source-Projekt npmx zielt auf Geschwindigkeit und ein modernes User-Interface. Erst im Januar dieses Jahres entstanden, befindet sich npmx noch im Alpha-Status.

Package-Suche mit Tastaturnavigation, Dark Mode und Security-Warnungen

Wie das npmx-Team betont, ist npmx weder ein Paketmanager noch eine Paket-Registry. Vielmehr soll es eine verbesserte User Experience im Umgang mit der npm Package Registry bieten. Die genauen Unterschiede im Vergleich mit npmjs.com sind im GitHub-Repo aufgeführt. Dank URL-Kompatibilität können Entwickler in URLs npmjs.com mit xnpmjs.com oder npmx.dev ersetzen.

npmx präsentiert sich im modernen Interface, das einen Dark Mode, Keyboard-Navigation und Quellcode-Ansicht mitsamt Syntax-Highlighting bietet. Zudem besteht eine Anbindung an alternative Registries wie JSR.

Auf Basis der OSV-Datenbank spielt npmx Warnungen vor Vulnerabilities in npm-Paketen aus. Darüber hinaus zeigt npmx Package-Details wie READMEs, Dependencies und Metadaten an, ebenso wie wöchentliche Download-Statistiken, Deprecation-Hinweise und die vollständige Installationsgröße mitsamt transitiver Dependencies.

User-Profile mit ihren öffentlichen Packages lassen sich via /~username ausgeben, Unternehmensseiten via /@orgname.

Grundstein erst vor sechs Wochen gelegt

Die Idee für npmx entstammt dem Leiter des Nuxt-Core-Teams, Daniel Roe. Er tätigte am 22. Januar 2026 den ersten Commit, und auf Bluesky entstand am nächsten Tag auf seine Frage hin eine rege Diskussion darüber, welche Punkte an npmjs.com frustrierend sind. Schon innerhalb der ersten 16 Tage erzielte das neue Projekt 1500 GitHub-Sterne. Es beteiligten sich 105 Personen an dessen Entwicklung.

Inzwischen konnte das Open-Source-Projekt Vercel, VoidZero, vlt, Netlify und Bluesky als Sponsoren gewinnen. Als OSS-Partner sind zahlreiche Projekte mit an Bord, darunter Vue.js, Nuxt, Storybook, Vite und JSR.

Weitere Informationen liefern der npmx.dev-Blog und das npmx-Repository auf GitHub.

(mai)

Der API-Werkzeughersteller Postman hat eine grundlegend überarbeitete Version seiner Entwicklungsplattform vorgestellt. Das Update macht die Anwendung vollständig Git-nativ und führt mit dem Agent Mode sowie einem zentralen API Catalog neue Funktionen ein, die auf die Zusammenarbeit mit autonomen KI-Agenten abzielen.

Laut der Ankündigung im Postman-Blog werden APIs immer stärker zur kritischen Schnittstelle zwischen Agenten und der realen Welt. Der zentrale Gedanke dabei: Im Unterschied zum bisher deterministischen Ansatz treffen KI-Agenten zur Laufzeit probabilistische Entscheidungen darüber, welche APIs sie aufrufen, wann und in welcher Reihenfolge. Fehlerhafte oder unzuverlässige Schnittstellen könnten sich in agentengesteuerten Systemen schnell kaskadierend auswirken. Die Neuerungen in Postman sollen Entwicklerteams daher auf die zunehmend agentengetriebene Softwareentwicklung vorbereiten.

Git-native Architektur und neues Collection-Format

Der wohl tiefgreifendste Umbau betrifft die Arbeitsweise mit Versionskontrolle. Die neue Postman-Version ist laut Hersteller von Grund auf Git-nativ aufgebaut. Entwicklerinnen und Entwickler sollen in Postman auf demselben Branch arbeiten können, auf dem sie auch Code schreiben – parallel zu ihrer IDE. Die Git-native Architektur ermögliche zudem Offline-Arbeit.

Ein wesentliches Detail für den Entwickleralltag: Postman führt das neue Collection-3.0-Format ein, das YAML-Dateien statt JSON-Blobs verwendet. Collections werden dabei in einzelne YAML-Dateien aufgeteilt. Die Dateien sollen damit nicht nur für KI-Agenten lesbar und schreibbar werden, sondern sich auch einfacher vergleichen und durch Menschen überprüfen lassen. Sämtliche Postman-Assets – darunter Specs, Flows und lokale Mock-Server – werden zusammen mit dem Code versioniert.

Neu sind außerdem codebasierte lokale Mock-Server, die API-Server simulieren und sowohl lokal als auch in der CI-Pipeline laufen können. Postman verspricht sich davon mehr Flexibilität als von rein statischem Mocking: Mock-Server sollen somit stärker ins Zentrum der Entwicklung rücken, etwa beim Entwurf neuer APIs oder beim Stubbing von Abhängigkeiten.

Multi-Protokoll-Support in einer Collection

Moderne Softwaresysteme nutzen selten nur ein einziges Protokoll, doch die meisten Werkzeuge behandeln jedes Protokoll separat. Postman erlaubt es Teams nun, HTTP, GraphQL, gRPC, MCP, MQTT, WebSockets und KI-Requests in derselben Collection zu organisieren. Automatisierung und Validierung über HTTP, GraphQL und gRPC hinweg sollen im Collection Runner möglich sein, weitere Protokolle sollen folgen. Laut Postman ergibt sich daraus ein systemweites Testen, das das tatsächliche End-to-End-Verhalten von Systemen abbilden soll – ohne den Koordinationsaufwand, der entsteht, wenn jede Komponente in einem anderen Tool validiert wird.

Überarbeitete CLI schließt Lücke zwischen Lokal und CI

Die Postman-CLI soll künftig dieselben Collections, Tests und Mocks sowohl lokal als auch in CI-Pipelines ausführen können, ohne dass Workflows für jede Umgebung neu konfiguriert werden müssen. Das soll CI-spezifische Fehler – etwa, dass Lücken in der Testabdeckung erst nach einem Commit sichtbar werden – reduzieren und Workflows vereinheitlichen.

Agent Mode: KI als aktiver Entwicklungspartner

Unter dem Namen „Agent Mode“ steht ab sofort eine KI-Funktion bereit, die über Postman und angebundene Repositories hinweg arbeiten soll. Der Agent Mode kann laut Ankündigung bestehende Collections, Tests und Mocks bearbeiten, aktualisieren und neue erstellen, die den Standards der jeweiligen Organisation folgen. Entwickler können die KI per Konversation nutzen, ihr komplette Workflows übertragen oder sie direkt auf der Codebasis arbeiten lassen – etwa um Fehler zu beheben, Server-Stubs zu generieren oder Client-Code zu erzeugen. Postman-Assets sollen sich auch komplett neu erstellen lassen, indem die KI auf vorhandenen Code verwiesen wird.

Ergänzend dazu soll die KI-gestützte Testgenerierung automatisch Contract-, Last-, Unit-, Integrations- und End-to-End-Tests für APIs anlegen. Bei fehlgeschlagenen Tests unter anderem im Collection Runner soll der Agent Mode die Ursache diagnostizieren und direkt in den Ergebnissen einen Fix vorschlagen können – sodass Entwickler Requests, Variablen und Environments nicht mehr aufwendig einzeln inspizieren müssen.

Neuer API-Katalog als zentrale Steuerungsebene

Eines der größten Probleme in Entwicklungsorganisationen: Es gibt keinen einzigen Ort, der grundlegende Fragen zu den eigenen APIs beantwortet – welche APIs existieren, ob sie getestet sind, ob sie den internen Standards entsprechen und wie sie in Produktion performen. Diese Informationen verteilen sich laut Postman über Git-Repos, CI-Dashboards, APM-Tools, Wikis und informelles Teamwissen.

Der neue API-Katalog soll als operative Schicht für das API-Portfolio-Management dienen und als „System of Record“ fungieren, das aktuell bleibt, weil es direkt mit den Orten verbunden ist, an denen APIs gebaut, getestet und betrieben werden. Teams sollen ihre gesamte API-Landschaft unabhängig von der darunterliegenden Infrastruktur und über alle Umgebungen hinweg einsehen können.

Der Katalog integriert API-Governance, sodass zentrale Teams Designregeln durchsetzen können, und bietet Analytics zur Messung der API-Gesundheit. Per Agent Mode sollen Nutzer den Katalog in natürlicher Sprache abfragen können – etwa: „Welche APIs in Produktion haben keine OpenAPI-Spec?“ oder „Welche Endpoints haben eine P95-Latenz über 500 ms im Staging?“ Der Agent Mode hat laut Postman Zugriff auf das vollständige Datenmodell des Katalogs und kann Governance-, Test- und Laufzeitdaten in einer einzelnen Abfrage verknüpfen.

Private API Network und neues UI

Weitere Neuerungen in Postman betreffen unter anderem das Private API Network, das auf Publisher- und Consumer-Seite aktualisiert wurde. Änderungen aus Git synchronisieren sich nun automatisch über die Postman-CLI mit dem Netzwerk. Das ebenfalls überarbeitete UI bietet nun eine einheitliche Workbench, in der Collections, Environments, Specs, Flows und lokale Mock-Server gemeinsam organisiert werden können.

Die Release Notes zu Version 12 (aktuell ist 12.0.3) listen alle konkreten Änderungen im Detail auf.

(map)