Wo liegen die Herausforderungen bei Schnittstellenprojekten?

Wenn wir an die IT-Landschaft in einem großen Unternehmen denken, mit unterschiedlichen Systemen, dann kennen Sie das: Jedes System hat seine Berechtigung und seine besonderen Möglichkeiten, und dennoch benötigen die Systeme Teilmengen der Daten des jeweils anderen. Beispiele: Sie haben einen Karrierebereich auf Ihrer Webseite, wo Daten aus Ihrer HR-Datenbank dynamisch eingebunden werden sollen. Sie haben einen Online-Katalog, der Produktdaten aus Ihrem PIM (Product Information Management) und Ihrem MAM (Media Asset Management) konsumiert – also Systeme, die ineinandergreifen. Und ganz generell gilt: Wer seine Marketingprozesse digitalisieren möchte und dabei auf leistungsstarke Einzelsysteme setzt (Stichwort "Best of Breed"), kommt um Schnittstellenprojekte nicht herum. Diese Projekte sind jedoch nicht immer einfach.

Worauf man bei Schnittstellenprojekten achten sollte.

Auf den ersten Blick scheinen Schnittstellenprojekte simpel zu sein: Zwei Systeme tauschen Daten aus. Technologisch ist das selten ein Problem, wenn das Projektmanagement sauber brieft und die Entwickler die notwendigen Fähigkeiten mitbringen. Alles kein Problem. Aber selbst wenn dies der Fall ist, kommt es besonders auf die Vorarbeit an. Sonst kann es passieren, dass das Projekt irgendwo auf der Strecke bleibt. Ein Beispiel: Daten und Formate sind gut dokumentiert und auch verstanden worden. Die Ausgabe ist soweit klar, und man hat die Daten einmal eingelesen und sich angeschaut – es sah sogar gut aus. Der Go-Live ist schon in Sicht. Je näher dieser rückt, desto eher committet man sich auf den Termin – und plötzlich passt irgendwas nicht. Man merkt, dass die Importstrategie nicht fertig durchdacht ist, das System vielleicht nicht mit Delta-Updates umgehen kann, oder die Exportzeitpunkte nicht zur Datenpflege passen. Es zeigt sich also, dass die kritischen Aspekte am Anfang nicht klar waren.

Wie plane ich ein Schnittstellenprojekt?

Deadlines gibt es in jedem Projekt, und die Aufwände möchten Sie natürlich auch kennen. Für die Planung ist es besonders wichtig, den Fokus auf den kritischen Pfad zu legen. Auch wenn Sie agil arbeiten, laufen Sie bei solchen Projekten besonders Gefahr, sich zu verrennen, wenn die Richtung nicht von Anfang an klar ist. Deshalb: Nehmen Sie sich am Anfang genügend Zeit für die Konzeption. Das ist das Erste. Zweitens arbeiten häufig Menschen aus verschiedenen Organisationen zusammen. Diese haben oft zusätzliche Aufgaben und andere Prioritäten, was bedeutet, dass Kleinigkeiten oft länger dauern – nicht unbedingt im Aufwand, sondern in der Zeit. Und was den Aufwand betrifft: Dieser ist vor allem bei Abstimmung, Kommunikation und Testing höher als in anderen Projekten. Planen Sie also genügend Abstimmungstermine, Tests und Reviews ein, damit Ihnen nicht die Zeit davonläuft. Es dauert oft länger und ist aufwendiger als gedacht – das ist die Faustregel. Aber wenn es dann funktioniert, hat es sich gelohnt.

Warum bei Schnittstellenprojekten der Blick aufs Ganze lohnt!

Häufig haben Sie zu Beginn eines Schnittstellenprojekts oder Teilprojekts bereits eine gute Vorstellung davon, was die Schnittstelle leisten soll und wie alles ablaufen soll. Trotzdem lohnt es sich, das Ganze noch einmal in Ruhe als Gesamtbild zu betrachten – nach dem Grundsatz: „Um schnell voranzukommen, nehmen Sie sich Zeit.“

• Welche Systeme müssen überhaupt miteinander kommunizieren, und in welcher Reihenfolge?
• Wenn die Schnittstelle interaktiv ist, also Informationen hin- und herschickt, muss geklärt werden: Welche Informationen müssen genau wann fließen?
• Was sind die möglichen Fehlerfälle, und wie werden diese behandelt? Ist ein Fehler kritisch oder hinnehmbar?
• Kann ein Produkt ohne Bild online gehen, oder wie sieht es aus?
• Welche Restriktionen gibt es?

Das sind ja zunächst die Fragen, die sich mit dem „Big Picture“ beschäftigen. Also die drei wichtigsten Tipps: Kritische Aspekte früh identifizieren, gute Kommunikation zwischen den Beteiligten sicherstellen und jemanden ins Boot holen, der bereits Erfahrung mit einem solchen Projekt hat.

Warum Sie Ihre Inhalte kennen sollten.

Die Inhalte sind ja der eigentliche Grund für das Projekt. Sie wollen oder können die Inhalte nicht in mehreren Systemen pflegen, bzw. es macht Sinn, dass die Daten an einer Stelle entstehen und an einer anderen Stelle sichtbar werden. Je besser Sie die Inhalte und die beteiligten Systeme kennen, desto weniger Probleme bekommen Sie. Beispiele:

• Was ist der Trigger für eine Datenlieferung?
• Erfolgt diese täglich oder ereignisbasiert?
• Und was gilt als „Änderung“?
• Ist dies in beiden Systemen dasselbe?
• Kennen wir die Datenmengen?
• Gibt es Erfahrungen mit der Übertragungsrate?
• Welche Datenarten haben die jeweiligen Systeme noch, die perspektivisch interessant sein könnten? Man will sich ja die Türen offenhalten...
• Wenn Daten transformiert oder verändert werden sollen, wer übernimmt das?
• Und welches Sicherheitsniveau haben die Daten? Was kann im schlimmsten Fall passieren?

Sie sehen: Viele, viele Fragen. Aber jede Minute, die Sie im Vorfeld länger darüber sprechen, zahlt sich aus.

Die fünf Standardthemen bei Schnittstellenprojekten.

Fast egal, welche Art von Projekt oder Datenübertragung Sie haben, in Schnittstellenprojekten gibt es fünf Standardthemen, die immer wieder auftreten:

• Die Inhalte, über die wir bereits gesprochen haben.
• Das Format – idealerweise das native Format des liefernden oder empfangenden Systems.
• Das Intervall der Lieferung – brauche ich die Daten in Echtzeit, stündlich, täglich? Reicht ein Delta-Export, oder ist ein Vollexport nötig?
• Der Übertragungsweg – wie werden die Daten übertragen, wie wird die Übertragung abgesichert, wie wird überwacht, ob etwas schiefgegangen ist?
• Und schließlich die Verarbeitungsregeln: Daten zwischen zwei Systemen werden häufig transformiert. Wer übernimmt das, und wie werden die Daten später visualisiert?

Wie geht es mit dem Testing weiter?

Vielleicht ist in Ihrem Projekt bis zur Umsetzung und zum Testing alles super gelaufen. Die Schnittstelle ist implementiert, die Daten sind verstanden, und der erste Test sieht gut aus. Aber wenn Sie Ihr Testsystem immer wieder mit Daten bespielt haben, ist es jetzt sinnvoll, ein klares Vorgehen zu wählen: Entwicklung stoppen, keine Änderungen mehr an relevanten Parametern vornehmen, Testsystem zurücksetzen, Daten übertragen und testen. Wenn dann die Daten im richtigen Format vorliegen und übertragen wurden, greift die gleiche Checkliste wie oben: Sind die Inhalte wie erwartet übertragen? Ist der Übertragungsweg stabil? Haben Sie an einen Penetrationstest, also einen Sicherheitscheck, gedacht? Die gleichen Themen: Inhalte, Format, Übertragung, Verarbeitung.

Keine stabile Weiterentwicklung ohne Dokumentation!

Wer das agile Manifest kennt, kennt den Satz: „Funktionierender Code ist wichtiger als eine umfassende Dokumentation.“ Das stimmt auch. Aber man muss sich nicht zwischen funktionierendem Code und vollständiger Dokumentation entscheiden. Sobald es funktioniert und keine Änderungen mehr anstehen, dokumentieren Sie es so, dass es auch jemand anders versteht. Gerade in Schnittstellenprojekten ist dies die Basis für eine stabile Weiterentwicklung. Es bedeutet auch, dass man sich vom „Kopfmonopol“ befreit. Man bleibt handlungsfähig, auch wenn derjenige, der es umgesetzt hat, mal nicht da ist. Gut, oder? Es gibt viele Unternehmen, die das vorbildlich machen: API-Dokumentation über Swagger, Business-Logik-Dokumentation über ein Projekt-Space usw. So macht Dokumentation Spaß. Dokumentieren Sie keine offensichtlichen Dinge, und die Dokumentation muss auch kein Tagebuch sein. Wenn sie möglichst zentral und nicht verteilt ist – also nicht im Code, im Word-Dokument und im Chat-Programm –, macht das die Arbeit für alle einfacher. Dokumentieren Sie also zentral.

Wie sieht Ihr Zieldatenmodell aus?

In Schnittstellenprojekten, besonders in großen, gibt es ein Thema von besonderer Bedeutung gleich zu Beginn: Wie sieht das Ziel-Datenmodell aus? Es geht nicht darum, wie die Daten kommen, sondern wozu sie werden müssen. Wenn man das frühzeitig klar hat, kann man entsprechend entwickeln und gleichzeitig die Schnittstelle implementieren. Am Ende sorgt dann eine entsprechende Datentransformation dafür, dass die gelieferten Daten auch angenommen werden. Ein Beispiel: Wir automatisieren einen Katalog auf Basis von Daten, die wir per Schnittstelle erhalten. Anstatt auf das Schnittstellenprojekt zu warten und jede Verzögerung auf das Katalogprojekt zu übertragen, wäre der richtige Weg: Datenmodell definieren, auf Basis des Layouts inhaltlich prüfen, entsprechend programmieren, das Schnittstellenprojekt durchziehen und am Ende per Transformation die gelieferten Daten mit den geforderten abgleichen und verbinden.

Warum Schnittstellenprojekte leicht unterschätzt werden.

Noch einmal auf den Punkt gebracht: Was unterscheidet Schnittstellenprojekte von anderen Projekten, und wie setzt man sie erfolgreich um? Schnittstellenprojekte sind anders, weil es mehr Beteiligte und mehr Unbekannte gibt. Das ist der erste Punkt. Sie werden leicht unterschätzt und sind in vielen Projekten der Treiber von Aufwand und Kosten. Nehmen Sie sich am Anfang genügend Zeit, um die Landschaft, die Datenflüsse und die Daten selbst zu verstehen. Es lohnt sich, versprochen. Stellen Sie gleich zu Beginn die richtigen Fragen und holen Sie sich jemanden ins Boot, der sich speziell mit den Daten und Schnittstellenprojekten auskennt. Gehen Sie davon aus, dass Abstimmung und Testing aufwendiger sind als in anderen Projekten und dass es zu zeitlichen Verzögerungen zwischen den Arbeitspaketen kommt. Dokumentieren Sie nicht zu ausführlich, aber ausreichend. Und definieren Sie das Zieldatenmodell so früh wie möglich, um Abhängigkeiten zu reduzieren.