Föderale IT-Architekturrichtlinien | SR5: API-First Ansatz
Aktuelle Definition API-first: "Konkret bedeutet dies, dass zuerst die Schnittstellen spezifiziert, mit allen Beteiligten getestet und abgestimmt werden. Erst danach erfolgt die Umsetzung der konkreten IT-Lösungen."
Eine wasserfallartige Entwicklung (zunächst: Abstimmung der gesamten API, dann Implementierung) verhindert dabei einen iterativen Entwicklungsprozess. Das "first" in API-First bezieht sich typischwerise nicht auf den zeitlichen Aspekt, sondern auf die Priorisierung der API (schnittstellengetriebene Softwareentwicklung).
Formulierungsvorschlag:
SR5: API-First Ansatz | MUSS |
---|---|
Beschreibung | Bei der Entwicklung von neuen IT-Lösungen und Interoperabilitätskonzepten sind diese nach dem API-first Ansatz zu konzipieren. Konkret bedeutet dies, dass |
Begründung | Dies führt zu einer Vermeidung von Missverständnissen bzgl. des Funktionsumfangs und zur frühzeitigen Klärung von offenen fachlichen Fragen. Die öffentlich einsehbare Schnittstellenspezifikation ermöglicht ein einfaches Verständnis der Funktionalitäten des jeweiligen IT-Systems. Außerdem kann mit diesem Ansatz die Integration neuer Lösungen in bestehende Architekturen frühzeitig verprobt werden. |
Abhängigkeiten | Mit dem API-First Ansatz werden die Wiederverwendbarkeit von IT-Lösungen (SR2) und die Interoperabilität (SR9) gefördert. Ebenfalls ermöglicht es eine lose Kopplung/Modularität (SR10) und reduziert durch wohldefinierte Schnittstellen die Komplexität der Gesamtlösung (SR12). Schnittstellen eignen sich in besonderem Maße zur Standardisierung (SR1). |
Implikationen | Die Architekturrichtlinie fordert eine frühzeitige Festlegung der notwendigen Schnittstellen sowie deren Abstimmung mit allen Beteiligten. Die Schnittstellen müssen im fachlichen Kontext entlang eines Prozesses oder ggf. Sequenzdiagramms genau verortet werden können. Die im Kontext der OZG-Umsetzung erarbeitete Landkarte für Kommunikationsbeziehungen (Landkarte Standards und Schnittstellen) ist zu prüfen und zu ergänzen. Während der Umsetzung der Lösungen sollen frühzeitig auf Grundlage der Schnittstellen anzubindende Lösungen für eine Anbindung ertüchtigt werden. Es soll möglich sein, während der Umsetzung Änderungswünsche an die Schnittstellenspezifikation zu formulieren. Geplante und umgesetzte Schnittstellen werden an zentraler Stelle veröffentlicht und im Rahmen eines definierten Releasemanagements gemäß der Semantic-Versioning-Methodik versioniert. Alte Versionen werden in einer Übergangszeit unterstützt und dann abgeschaltet. Schnittstellen sind sicher zu gestalten und sollen - sofern sinnvoll - auch für externe Akteure (Wirtschaft etc.) verfügbar gemacht werden. Im OZG-Kontext können z.B. Online-Dienste ergänzend zu Formularen als API-Schnittstellen bereitgestellt werden. Externe Akteure können diese Schnittstellen bei der Entwicklung von integrierten Lösungen nutzen, um somit die Verbreitung der Verwaltungsleistungen und Nutzerakzeptanz zu erhöhen. |
Beispiele für die Anwendung | Definition von standardisierten Schnittstellen, um länderübergreifende Interoperabilität zu ermöglichen, z. B. im Kontext OZG-Einführung und Registermodernisierung. Einsatz z.B. von OpenAPI für eine konkrete und leicht verständliche Schnittstellenbeschreibung. Frühzeitige Festlegung der Schnittstellen („Schnittstellenverträge“) |
Bezug zu Zielen und Gesetzen | S3: Digitale Verwaltung (Grundprinzipen „Geschwindigkeit“, „Nutzerfreundlichkeit“, „Innovation und nachhaltige technische Qualität“), S4: Verwaltung als Plattform |
Nicht-normative Hinweise:
Edited by Marco Holz