Schnittstellenprojekte mit 2 wichtigen Fragen zielsicherer realisieren

Schnittstellenprojekte sind irgendwie doof! Warum?

Schnittstellenprojekte scheinen meist recht simpel zu sein. Es gibt selten eine GUI und erste wichtige Fragen wie existiert eine WSDL/XSD bzw. ein Standard sind schnell geklärt. Frameworks zum Umgang mit Protokollen wie HTTP und FTP sowie mit Formaten wie XML, SOAP, JSON & Co. gibt es zudem zumindest im Java Ökosystem wie Sand  am Meer.

Also wo liegt das Problem? Lesen – Konvertieren – Schreiben – fertig! Sozusagen eine Fingerübung für einen Java Entwickler! Doch so einfach ist es dann oft doch nicht.

Werkzeuge sind nicht das Problem!

Technologisch betrachtet sind Schnittstellenprojekte heutzutage wirklich nicht das Problem. Beispielsweise lassen sich mit dem Enterprise Application Integration Framework  Spring Integration sehr schnell Integrationsflüsse mit unterschiedlichsten Formaten / Protokollen realisieren. Wer es noch moderner möchte, kann gleich auf Spring Cloud Data Flow setzen. Warum können diese Projekte dann immer noch so zäh sein und die Terminplanung dermaßen sprengen?

Stolpersteine & Engpässe identifizieren

Eben weil diese Projekte vermeintlich simpel sind, ist die Versuchung ziemlich groß, die Analyse in der Angebots- bzw. Planungsphase zu schnell abzuwickeln. Doch wer hier die kritischen Aspekte des Projekts identifiziert und diese explizit macht, hat das Projekt besser im Griff und erfährt weniger böse Überraschungen.

Doch wie identifiziert und dokumentiert man diese Stolpersteine & Engpässe?  Hierfür möchte ich Dir zwei Fragen an die Hand geben, die du dir in jedem Projekt stellen solltest.

Alle Daten da?

Ich habe es einige Male erlebt, dass es bei der Implementierung von Schnittstellen zu Verzögerungen und Stress kam, weil schlichtweg nicht geprüft wurde, ob die Daten, die von A nach B übertragen werden sollen, im richtigen Format vorliegen oder zum Übertragungszeitpunkt überhaupt vorhanden sind.

Beispiel für Schnittstellen-Zuordnung mit einfacher Symbolik
Beispiel für Schnittstellen-Zuordnung mit einfacher Symbolik

Um solche Überraschungen zu vermeiden, ist es ratsam, schon während der Analysephase, mit Hilfe einer Matrix die Daten der Quelle den Daten des Ziels zuzuordnen. So können Lücken identifiziert und darüber hinaus Transformationen, die auf Grund unterschiedlicher Datentypen oder Strukturen notwendig sind, dokumentiert werden.

Durch eine einfache Symbolik (? offene Fragen, X geprüft und ok) und dem Einsatz von bedingten Formatierungen ist es möglich, den Fokus auf die Aufwandstreiber zu legen und  Projekte zielsicherer zu planen und zu steuern!

Beispiel für Schnittstellen-Zuordnung inklusive Notiz
Beispiel für Schnittstellen-Zuordnung mit einfacher Symbolik inklusive Notiz

Funktioniert auch alles auf dem Zielsystem?

Die Schnittstelle läuft und das auch noch eine Woche vor Go Live! Tschakka! Zwar nur auf dem Entwickler-Laptop und ohne SSL aber das ist doch nur noch ne Kleinigkeit. Ich bin so gut wie fertig Chef!

Kommt Dir das bekannt vor? Mir auf jeden Fall! Ich selbst unterlag einige Male diesem Trugschluss und habe diese Aussage auch schon häufiger gehört! Doch dann rückte der Go Live Termin immer näher und es wurde leider doch sehr stressig. Ja und nicht immer konnte der Termin gehalten werden!  So ein Mist!

Ein kleines Deployment Diagram, das aufzeigt, wie die Kommunikation der Systeme abläuft (HTTP, RMI), welche Netzwerk-Ports benötigt werden und ob eine verschlüsselte Kommunikation zum Einsatz kommt (HTTPS, SSL), schafft sehr schnell Klarheit für alle Beteiligten. Doch sollte dann auch in einer damit vergleichbaren Umgebung getestet werden.

„Deploy early and often“ sollte die Devise lauten! Das bedeutet nicht zwingend, dass die gesamte Netzwerktopologie nachgebaut werden muss aber wenn SSL zum Einsatz kommt, sollte dies zumindest in regelmäßigen Abständen auch bei Entwicklertests der Fall sein.