API First: Auch im Systems Engineering?

Viele Konzepte aus der Softwareentwicklung tauchen oft zeitversetzt im Systems Engineering auf. Zum Beispiel haben Softwareentwickler schon lange sauber versioniert (CVS, Subversion, git), während dies in der Produktentwicklung noch lange nicht überall der Fall ist. Oder Konzepte wie Test-First und Behavior-Driven Development, welche zwar im Systems Engineering prinzipiell anwendbar und sinnvoll sind, dort aber heutzutage noch kaum zu finden sind.

Heute geht es um API First, einen Ansatz. Hier steht die API, die Schnittstelle im Mittelpunkt. API First ist in der Softwareentwicklung noch nicht wirklich weit verbreitet. Trotzdem lohnt es sich jetzt schon genauer hinzuschauen und die Anwendbarkeit im Systems Engineering zu untersuchen.

API First bedeutet Schnittstellen als Elemente erster Klasse

Programmierschnittstellen (Application Programming Interface, API) gibt es ja schon lange. Diese ermöglichen modulare Software. In manchen Situationen werden diese auch sehr sorgfältig definiert. Das ist besonders dann der Fall, wenn die Schnittstelle öffentlich ist. Der Architekt hat normalerweise die Aufgabe, sich auch um die Schnittstellen eines Systems zu handeln. Doch leider „wachsen“ APIs allzu oft und werden nicht vernünftig dokumentiert und getestet, was zu Problemen und Frustrationen führen kann.

Die Idee hinter API First bedeutet, dass Schnittstellen die selbe Aufmerksamkeit bekommen wie der Code: Entwickler dürfen nicht einfach drauf losprogrammieren, sondern müssen die API sauber planen, warten und testen.

Weiterhin definieren Entwickler oder Architekt die Schnittstellen frühzeitig. In der testgetriebenen Entwicklung ist dies sogar notwendig. Schließlich kann ein Test nur dann formuliert werden, wenn die Schnittstelle bekannt ist, auch wenn die Implementierung fehlt.

Ebenso wichtig ist der Aspekt der Verifizierung, möglichst kombiniert mit Automatisierung. Hier finden wir Design by Contract, ein Ansatz, bei dem das Verhalten der Schnittstelle mit einer formalen Beschreibung spezifiziert wird. Bspw. könnten wir damit festhalten, dass eine Funktion zur Berechnung keine Negativen Zahlen verarbeitet, auch wenn der Datentyp des Parameters negative Zahlen zulässt.

3 Prinzipien von API First

Die folgenden drei Prinzipien sind die Basis für API First Softwareentwicklung:

1. Die API ist die erste Benutzeroberfläche (UI), die entwickelt wird. Hier gehen wir davon aus, dass eine für den Menschen konzipierte Benutzeroberfläche ebenfalls auf der API aufsetzt. Daher wird der erste „Kunde“ einer API der Entwickler der Benutzeroberfläche (UI) sein. Das entkoppelt die UI von der Anwendung. Das bedeutet zum Beispiel, dass eine Anwendung problemlos mehrere Benutzeroberflächen (und maschinelle Nutzer) haben kann, die alle mit der selben API bedient werden. Sobald die API eine neue Funktion sichtbar macht, ist diese (bei einer guten Architektur) auch in allen UIs vorhanden. Auch ohne Benutzeroberfläche können Menschen mit der API interagieren, zum Beispiel mit Oberflächen wie Swagger.
2. Die Implementierung kann sich jederzeit ändern, ohne dass sich die API ändert. Dieses Konzept kennen wir schon aus dem Systems Engineering, zum Beispiel durch Black-Box-Spezifikationen. Hier ist es wichtig, dass die Entwickler keine Implementierungsdetails die Schnittstellengrenzen überqueren. Dieses Konzept erleichtert auch ungemein den Einsatz von Mocking zum Testen.
3. Die API ist verständlich dokumentiert, oder selbstbeschreibend. Die API muss für die Konsumenten der API verständlich sein, auch wenn diese nicht an der Erstellung der API beteiligt waren. Dazu gehören zum Beispiel sprechende Bezeichner bei Parametern und den Namen der Funktionen. Wie schon oben erwähnt, kann dies auch über maschinenlesbare Verträge verfeinert werden. Oberflächen wie Swagger machen diese Informationen sichtbar und leiten die Entwickler, welche die API verwerten wollen.

Vorteile

Dieser Entwicklungsansatz macht es wesentlich leichter, Komponenten auszutauschen und die Anwendung schnell weiterzuentwickeln, ohne dass andere Teams davon beeinflusst werden (solange sich die API nur langsam oder gar nicht verändert). Teams können damit gut parallel arbeiten. Ebenso können wir damit die Komplexität in den Griff bekommen, denn diese kann sich hinter der Schnittstelle verstecken. All dies senkt Kosten und erhöht die Geschwindigkeit der Entwicklung.

Interfaces First im Systems Engineering

Die hier beschriebenen Konzepte lassen sich ebenso im Systems Engineering anwenden. Die große Herausforderung ist, dass bei Schnittstellen im SE nicht die selbe Homogenität besteht wie in der Softwareentwicklung. Bezüglich Software gibt es oft nur eine Schnittstellentechnologie, während wir im SE mit Schnittstellen für Daten, Kräfte, Medien und vielem mehr umgehen müssen. Die SysML versucht mit formal spezifizierten Blöcken und Ports diese Herausforderung zu meistern. Dazu muss eine Organisation aber erst einmal die Hürde nehmen, zumindest auf Architekturebene SysML einzuführen.

Es gibt eine Reihe von Alternativen zu SysML, hier sollten wir uns auf keinen Fall auf eine Sprache/Notation festlegen. Denn die eigentliche Herausforderung ist die Denkweise, also ein Interface-First-Mindset im Team zu realisieren.

Photo by James Lewis on Unsplash