Wie man robuste IT-Systeme schafft
Business Class
IT-Systeme sollen lange leben und sich durch hohe Qualität auszeichnen. Um beim Einkauf und der Entwicklung die richtigen Entscheidungen zu treffen, sind greifbare Kriterien hilfreich.
Nur selten existiert ein IT-System völlig isoliert. In der Regel muss es auf Daten und Funktionen anderer Rechenanlagen zugreifen. Bei der Neuentwicklung oder dem Einkauf einer Software wirft das die Frage auf, wie sie sich am besten in die bestehende Landschaft einfügen lässt.
Es gibt den Trend, Geschäftsanwendungen und die Datenhaltung in Microservice-Architekturen zu verteilen. Daher sollten Entwickler auf einfache Transportkanäle und intelligente Endpunkte setzen. Passen können hier leichtgewichtige Messaging-Systeme wie RabbitMQ oder Apache Kafka. Sie spielen in bestimmten Use Cases, etwa Big-Data-Analysen oder verteilten Transaktionen, ihre Stärken aus. Für das Zusammenführen beliebiger IT-Systeme sind sie ungeeignet, da sie nicht auf etablierten Standards fußen.
Um ein gutes Zusammenspiel der beteiligten Komponenten zu erreichen, empfehlen sich sprachenunabhängige und standardkonforme Anwendungen. Representational State Transfer (REST) APIs haben sich durchgesetzt, da sie via HTTP-Protokoll kommunizieren und auf anerkannten Webstandards basieren. REST ist keine Technik, sondern ein Architekturstil. Dennoch zeigen sich beim Umsetzen von REST-APIs große Unterschiede.
Mit dem Richardson Maturity Model lassen sich REST-APIs hinsichtlich ihrer Qualität bewerten (siehe ix.de/ix1811096). Es gibt vier Stufen von Level 0 bis Level 3. Je höher das Level, desto mehr erfüllt es die formale Definition des Architekturstils REST.
Nicht mit zu wenig zufrieden sein
APIs nach Level 0 nutzen nur einen Uniform Resource Identifier (URI) und verwenden lediglich eine HTTP-Funktion – in der Regel POST. HTTP dient als Kanal zum Datentransport. Bei einer API nach Level 1 gibt es mehrere Service-Endpunkte (URIs), über die sich verschiedene Ressourcen ansprechen lassen. Es wird aber weiterhin nur eine HTTP-Funktion benutzt.
In Level 2 verwenden APIs die gesamte Bandbreite der HTTP-Standardfunktionen wie GET, POST und PUT sowie deren standardisierte Semantik. Das erlaubt CRUD-Operationen (Create, Read, Update, Delete) auf den verschiedenen Ressourcen. Zusätzlich kommen weitere HTTP-Standards wie Statuscodes zum Einsatz (etwa 404 Not Found). Die API wird dadurch übersichtlicher. Deshalb ist für jede Entwicklung mindestens eine REST-API nach Level 2 erstrebenswert.
Level 3 kennt das Konzept Hypermedia, bei dem Dokumente Referenzen auf andere Dokumente enthalten. Die größte Verbreitung hat es in HTML-Seiten, die per Link auf andere Seiten verweisen. Da REST-APIs typischerweise JSON- oder XML-Dokumente liefern, muss der Entwickler spezifische Konzepte für Links umsetzen. Das Referenzieren von Ressourcen sollte unbedingt mit HTTP-basierten URIs erfolgen, damit man beim Verarbeiten im Client Standardmethoden verwenden kann.
Quellcode mit hoher Qualität nennt sich in Anlehnung an das gleichnamige Standardwerk auch Clean Code [1]. Ziel ist es, verständlichen und lesbaren Code zu schreiben, den jeder Entwickler verstehen kann. Das ist die Basis für kostengünstige und risikoarme Änderungen, Erweiterungen und gute Wartbarkeit.
Bei gekaufter Software lässt sich die Qualität in der Regel nicht direkt überprüfen, da die Hersteller den Code als ihr geistiges Eigentum schützen. Es gibt aber Unternehmen, die ihre Methodik offenlegen, sodass man eine Einschätzung zur zukünftigen Erweiterbarkeit und Wartbarkeit erhält.
Ein wenig Prinzipienreiterei muss sein
Für eine hohe Codequalität gibt es allgemeingültige Prinzipien, die für fast alle Programmiersprachen und Softwareprojekte gelten. Zu ihnen zählen folgende Beispiele: