Typischer Alltag im Projektgeschäft: Mühsam wurden die Anforderungen in Features und User Stories heruntergebrochen, die Aufgaben an alle Beteiligten verteilt. Von da an ist jeder erst einmal froh, dass das Projekt zum Laufen kommt. Mit mehr oder weniger großen Schwierigkeiten und neu-deutsch Herausforderungen wird nun Aufgabe für Aufgabe abgearbeitet.
Erst wenn der Integrationstest beginnt, kommt die Stunde der Wahrheit. Nun werden die Tücken der Schnittstellen und des übergreifenden Zusammenspiels zwischen Anwendungen und/oder Services offenbar. Ein ums andere Mal fällt auf, dass die Schnittstellen-Abstimmungen mehr auf Vermutungen und Annahmen basieren, denn auf konkreten, dokumentierten und vor allem aktuellen Vereinbarungen.
Klassische Probleme im ersten Integrationstest (oder schon im dazu benötigten Umgebungsaufbau) sind fehlende Anwendungen, unterschiedliche Versions-Stände, unabgestimmte technische Schnittstellen-Formate, mehrfach belegte oder interpretierte Felder innerhalb der Schnittstellen oder sogar generell fehlende Schnittstellen für Datenbereitstellungen. Die Liste kann bestimmt jeder unserer Leser für sich und in unterschiedlichsten Technologien weiterführen.
Was ist aber so schwer daran? Jetzt bitte nicht die allumfassende Ausrede “Komplexität” ins Feld führen. In der Regel ist es nämlich viel einfacher und heißt: Kontext begreifen und Strukturen einhalten.
Ist Struktur nicht das Gegenteil von Agilität? Nein, denn Agilität – oder meine Auffassung davon – heißt vorausschauende, achtsame Flexibilität! In einfachen Worten kann ich im agilen Umfeld mit Struktur auf vorhersehbare und auch unvorhersehbare Veränderungen reagieren. Im Falle der Schnittstellen erwarte ich ein Architekturbild mit dazugehörigen logischen und physischen Schnittstellen je Modul/Applikation/Service. Für jede Schnittstelle gibt es eine stets aktuelle Beschreibung zu Technologie, Inhalt, Sendefähigkeit (unidirektional vs. multidirektional) und Nutzung der Felder. Das Ganze ist im Idealfall abgestimmt als “Kontrakt” zwischen Sender und Empfänger. Vor allem muss es die Festlegung des Master-Systems geben und ein gemeinsames Verständnis der Nutzung der einzelnen Felder des Datentransfers. Es nutzt nichts, wenn z.B. ein Adresszusatz (zweites Feld für die Straße, “z. Hd. Herr Müller”) in der Logistik als Sortierkriterium für Großstücke zweckentfremdet wird.
Wenn abgestimmte und einheitliche Strukturen für alle Applikationen/Services/Module übergreifend vorhanden sind, kann man schnell, agil und vor allem in guter Qualität Anpassungen und Neuentwicklungen umsetzen. Dann kann einzeln entwickelt und getestet werden, und trotzdem wird im Zusammenspiel der Datenfluss sowohl fachlich als auch technisch “durchgehend erfolgreich” sein!
Christoph Lefkes