Verschwendung vermeiden - Wie Consumer-Driven Contracts helfen

Consumer-Driven Contracts (CDCs) hat euch meine Kollegin Antoniya bereits in diesem Blog vorgestellt. Ich möchte kurz darstellen, warum CDCs helfen, Entwicklungsprozesse lean zu gestalten.

Als lean, im Sinne von Lean Production, bezeichnen wir einen Herstellungsprozess, der auf die Vermeidung von Verschwendung ausgerichtet ist. In heutigen IT-Organisationen trifft das auf die Entwicklung von Schnittstellen in aller Regel nicht zu. Warum eigentlich?

Betrachten wir doch einmal drei Arten von Verschwendung, die üblicherweise in Prozessen der Schnittstellenentwicklung auftreten.

Überproduktion

Oft werden Schnittstellen vom Provider vorgegeben, also von dem Team spezifiziert, das einen Service implementiert, der diese Schnittstelle anbietet. Die Umsetzung gestaltet sich dabei so, dass das Provider-Team versucht, die Anforderungen von zwei oder drei Consumern zu verstehen und dann die Schnittstelle implementiert. Später kommen weitere Consumer dazu, gelegentlich mit Änderungswünschen. Da entsteht schnell der Wunsch, den Anforderungen aller zukünftigen Consumer durch einen eleganten und generalisierten Entwurf der Schnittstelle schon zuvorzukommen: „Ja, das was ihr braucht können wir alles.“

Aber: welche Teile einer Schnittstelle werden denn jetzt wirklich gebraucht? Und wissen wir, welcher Consumer welchen Teil der Schnittstelle benutzt? Wie viele unbenutzte Schnittstellenelemente pflegen wir da eigentlich?

Nicht unmittelbar benötigte Funktionalität ist die erste Art von Verschwendung.

Defekte

Die meisten Defekte bei der Entwicklung von Schnittstellen sind auf Missverständnisse zwischen den beteiligten Entwicklungsteams zurückzuführen. Wie sollten nochmal die Zeitstempel serialisiert werden? Waren die Höhenangaben jetzt in Meter oder Zentimeter? Kann diese Aufzählung wirklich nur die drei spezifizierten Werte enthalten?

Wie erkennen wir überhaupt, dass wir auf Basis falscher Annahmen entwickeln?

Oft verlassen wir uns dafür auf eine separate Testumgebung für Integrationstests. Fällt hier ein Problem mit der Schnittstelle auf, ist es natürlich schon etwas spät. Das Ausrollen in die Produktivumgebung verzögert sich, bis der Fehler behoben ist. Im schlimmsten Fall kommt es jetzt auch noch zu Vorwürfen zwischen den Teams. Und: Eine Testumgebung muss aufgesetzt, gewartet und mit Testdaten versehen werden – ein erheblicher Aufwand.

Was wenn wir Missverständnisse bereits viel früher entdecken können, bevor sie sich als Fehler in einer teuren Testumgebung manifestieren?

Unnötige Meetings

Schnittstellen, wenn sie erst einmal in Verwendung sind, müssen auch weiterentwickelt werden. Natürlich müssen Änderungen zwischen den verantwortlichen Teams koordiniert werden, sonst treten vermehrt Fehler bei der Integration auf.

Im schlimmsten Fall bedeutet das, dass das für den Provider verantwortliche Team jedes Consumer-Team informieren und auf deren Rückmeldung warten muss. Oh je, kennen wir überhaupt noch alle unsere Consumer? Wer ist da in der Zwischenzeit dazugekommen? Wer ist der Ansprechpartner?

Unnötige Funktionalität und übermäßig generalisierte Schnittstellen verschärfen diese Problematik noch zusätzlich, weil es während den Absprachen zu Verständnisproblemen kommt.

Häufig machen wir das Problem vermeintlich beherrschbar, in dem wir eine Schnittstelle als ganzes mit einer Versionsnummer versehen. Müssen wir inkompatible Änderungen durchführen, führen wir einfach eine neue Version ein. Dann bitten wir alle Consumer, auf die neue Version zu wechseln. Jetzt pflegen wir auf absehbare Zeit zwei Versionen, manchmal auch drei oder vier.

Aber: Was wenn wir mit einer minimalen Anzahl an Absprachen Änderungen durchführen könnten? Was wenn wir als Provider feststellen könnten, ob eine Änderung überhaupt ein Problem darstellt, ohne auch nur mit einem Consumer-Team zu reden?

Verschwendung eliminieren – mit CDCs!

Consumer-Driven Contracts helfen uns, diese drei Arten von Verschwendung, also Überproduktion, Defekte und unnötige Meetings, zu vermeiden.

Überproduktion verhindern wir, weil CDCs minimal sind. Weil ein CDC aus der Summe der Erwartungen aller Consumer besteht, enthält er kein Schnittstellenelement, das aktuell nicht von mindestens einem Consumer benötigt wird.

Defekte reduzieren wir ohne eine aufwändige separate Testumgebung, weil jeder Consumer explizit seine Erwartungen an die Schnittstelle spezifiziert. Durch die formale Art der Spezifikation können Consumer und Provider mit automatischen Tests die Einhaltung ihres Contracts verifizieren. Diese Tests können von beiden Seiten unabhängig voneinander während des Continuous-Integration-Builds ausgeführt werden.

Unnötige Meetings eliminieren wir, weil wir einfach die Provider-seitigen Tests ausführen können, um von einer angedachten inkompatiblen Änderung betroffene Consumer zu identifizieren. Absprachen für eine kompatible Weiterentwicklung müssen wir dann nur mit den betroffenen Consumern durchführen. Und: im besten Fall ist kein Consumer betroffen und wir können die nicht mehr benötigten Teile der Schnittstelle ohne ein einziges Meeting entfernen.

Consumer-Driven Contracts helfen also dabei, häufig gar nicht wahrgenommene oder als unvermeidlich angesehene Verschwendung zu identifizieren. Falls ihr euer System mit mehreren Teams entwickelt, was hindert euch daran, CDCs einzuführen?