> Fallstudie II

Linkname=APIClient

Best Practice
Schnittstellen an das Business erfolgreich übergeben

„Während die Business Fachbereiche neue Applikationen zumindest punktuell prüfen, ist die Abnahme der API’s eine Herausforderung für alle Seiten.“

Heutzutage wird erwartet, dass ein Modul bzw. dessen Logik nicht nur über seine eigene Oberfläche (User Interface) bedient werden kann. Dabei ist es egal, ob es sich um ein Auftragsmodul oder eine andere Funktion handelt.

Statt dessen muss z.B. ein Auftrag mit derselben Logik auch über einen externen Zugang (Schnittstelle, Microservice, bzw. „API“) angelegt werden können. Sonst kann er nicht von einer weiteren Applikation (Call Center, Amazon, ...) gleichermaßen konsistent bearbeitet werden.

Warum übernehmen Business Fachbereiche keine API’s?

Wenn die Business Fachbereiche die Verantwortung für API’s übernehmen sollen, dann müssen die API’s zumindest gut zu verstehen sein. Das gilt besonders dann, wenn es sich um eine größere Anzahl handelt, wie es heute üblich ist.

Aber leider richten sich die meisten Dokumentationen an die Entwicklung. Und viele Frontendtools wie z.B. Boomerang, SOAP UI, Postman, Swagger kommen für die Fachbereiche gar nicht erst in Betracht. Deren Bedienung verlangt eine gewisse technische Auseinandersetzung und bezieht sich eher auf einzelne Abfragen, als auf die Geschäftsprozesse in ihrem Ablauf.

Lösung

In meinem letzten Projekt haben wir diese Lücke mit einem API DemoClient speziell für die Business Bereiche geschlossen. Damit können viele Schnittstellen (i.d.R. REST Services) des Unternehmens hintereinander online demonstriert und ausprobiert werden – quasi als eine kombinierte „API Live Demo und Dokumentation“:

• Als HTML-Anwendung ist keine Installation beim User erforderlich. Die visuelle Gestaltung der Oberfläche gibt einen schnellen Überblick über alle Services in der Prozessfolge, ohne dass der Benutzer sie vorab kennen müsste.

• Hinweise zu neuen Services, zu Änderungen oder zur Bedienung können direkt in die Oberfläche eingearbeitet und aktualisiert werden.

• Die IT wird entlastet, weil weniger Dokumentation notwendig ist, und weil sich die Fachbereiche viele Fragen durch Ausprobieren selbst beantworten können. Das Gleiche gilt für die unterschiedlichen Konsumenten der Services, die sich vor einer Implementierung einen Überblick über die Funktionalitäten verschaffen.

• Um einen Prozess (z.B. eine Kunden- und Vertragsanlage) durchzuführen oder um ihn zu wiederholen, können die Eingabedaten gespeichert und mit neuen IDs genutzt werden.

• Prägnante Namen der Eingabefälle, z.B. „Inländischer Kunde“, „Ausländischer Kunde“, „Sondervertragskunde“, „Abovertrag“ usw. zeigen sofort, worum es in der jeweiligen Demo geht.

• Der Export der Demodaten als JSON kann direkt in ein JiraTicket eingefügt werden, um Anforderungen und Abnahmen ohne viel Aufwand zu dokumentieren.

• Da die Oberfläche keine Validierungen der Services vorwegnehmen oder hinzufügen darf, können die Fachbereiche einfach und genau sehen, welche Rückmeldungen implementiert wurden.

• Trotzdem ist es möglich, die Eingabedaten, Nummernkreise oder Instanzen durch den Testclient einzuschränken, um z.B. die Abstimmung von Datenübernahmen nicht zu gefährden oder um Eingaben verschiedener User zu unterscheiden.

Der API DemoClient hat die detaillierten Tests natürlich nicht ersetzt. Sie wurden weiterhin durch ausgebildete Testteams anhand der definierten Coding-Richtlinien über automatische Testsuiten und Unit-Tests durchgeführt.

Aber die Übertragung der Verantwortung auf die Fachbereiche wurde ungemein erleichtert - nicht nur bei der Abnahme, sondern auch bei der Formulierung von Änderungswünschen. Die Produkt Owner wurden wieder zu Bauherren, die die Sicht auf das Haus im Ganzen bekommen.

Ich stelle Euch gerne vor, wie ein API DemoClient verhältnismäßig schnell realisiert werden kann.