Software-technische Referenzarchitektur
Die software-technische Referenzarchitektur beschreibt, wie die in der fachlichen Referenzarchitektur definierten Anwendungen software-technisch in Form von IT-Systemen umgesetzt werden.
Eine zentrale Eigenschaft der software-technischen Referenzarchitektur ist, dass sie nicht zwischen Anwendungstypen unterscheidet. Die software-technische Umsetzung von Anwendungen ist ungeachtet ihrer Fachlichkeit gleich. Die software-technische Referenzarchitektur definiert hierzu das IT-System als Oberbegriff und beschreibt die Umsetzung einer Anwendung mittels einer Menge von IT-Systemen, die jedes für sich eine bestimmte Ausprägung besitzen. Diese Ausprägung ist technisch motiviert und umfasst aktuell Backends, Frontends, Batches und Gateways.
1. Definition der Systemlandschaft
Der Begriff der Anwendungslandschaft ist fachlich motiviert. Die technische Entsprechung hierfür ist der Begriff der Systemlandschaft. Eine Systemlandschaft beinhaltet alle IT-Systeme als technische Umsetzung der Anwendungen der Anwendungslandschaft sowie technische Systeme zur Unterstützung (unter anderem Datenbanken oder Web-Server).
1.1. Geschäftsanwendungen
Geschäftsanwendungen implementieren allgemein die Geschäftsprozesse einer Domäne. Sie werden im Rahmen des Systementwurfs in folgende IT-Systeme zerlegt: Backends, Frontends, Batches und Gateways.
Backends von Geschäftsanwendungen implementieren den Großteil der die Geschäftslogik und die Datenhaltung. Sie stellen die Geschäftslogik über Services zur Verfügung. Backends rufen selbst Services anderer Backends auf. Die aufgerufenen Backends können zur selben Geschäftsanwendung gehören, zu einer anderen Geschäftsanwendung, oder zu einer Querschnittsanwendung.
Batches von Geschäftsanwendungen implementieren die Geschäftslogik für zeitgesteuerte Aufgaben oder Massenoperationen. Sie rufen in der Regel Services von Backends derselben Geschäftsanwendung auf. Es kann aber auch sein, dass sie Services von Backends einer anderen Geschäftsanwendung oder einer Querschnittsanwendung benötigen.
Gateways von Geschäftsanwendungen implementieren die Kommunikation mit externen Systemen. Sie sind im API-Gateway zusammengefasst.
Frontends von Geschäftsanwendungen implementieren die grafische Benutzeroberfläche (GUI). Sie rufen über die Gateways der Geschäftsanwendung Services der Backends derselben Geschäftsanwendung auf.
Geschäftsanwendungen, die eine grafische Benutzeroberfläche bereitstellen, dürfen aus Sicherheitsgründen nicht direkt vom Benutzer aufgerufen werden, sondern werden in das Portal der Systemlandschaft eingebunden.
1.2. Querschnittsanwendungen
Querschnittsanwendungen bieten von den Geschäftsanwendungen gemeinschaftlich genutzte Funktionalitäten an, etwa für die Bereitstellung von Schlüsseldaten. Querschnittsanwendungen können eine eigene Datenhaltung besitzen.
Sie sind strukturell gleich aufgebaut wie Geschäftsanwendungen, d.h. sie bestehen aus Backends, Batches, Gateways und Frontends. Allerdings werden Querschnittsanwendungen nur von internen Benutzern oder anderen IT-Systemen derselben Systemlandschaft aufgerufen. Sie rufen selbst nur andere Querschnittsanwendungen auf.
Eine Ausnahme bilden Querschnittsanwendungen, die vorrangig aus Gateways bestehen. Diese bilden eine bestimmte Kommunikationsbeziehung zwischen externen Systemen und der Systemlandschaft ab, wie z.B. ein zentrales Mail-Gateway für den Versand von E-Mails an externe Empfänger.
1.3. Portal
Die Referenzarchitektur sieht keinen Portal-Server im klassischen Sinne vor. Es gibt weder einen systemübergreifenden Rahmen noch eine systemübergreifende Navigation.
Das Portal im Sinne der Referenzarchitektur besteht aus:
-
einem Web-Server-Cluster, der Aufrufe entgegennimmt und an die Geschäftsanwendungen weiterleitet, sowie
-
einer zentralen Startseite, welche den eingeloggten Benutzern die Geschäftsanwendungen der Anwendungslandschaft, für welche sie berechtigt sind, präsentiert.
Der Zweck eines Portals ist die gemeinsame Authentifizierung und Autorisierung für alle Geschäftsanwendungen und die Indirektion des Zugriffs von Nutzern auf die Geschäftsanwendungen.
1.4. API-Gateway
Das API-Gateway ist der zentrale Zugangspunkt zum Aufruf von Services von IT-Systemen einer Systemlandschaft von außen, sowie zum Aufruf von Services von externen Systemen von innerhalb der Systemlandschaft. Es stellt eine klare technische Grenze zur Systemlandschaft dar, indem es die internen Systeme von externen Systemen entkoppelt. Es überbrückt dabei Schnittstellentechnologien und nimmt querschnittliche Aufgaben wahr, insbesondere in den Bereichen Authentifizierung, Autorisierung, Monitoring und Protokollierung.
Durch diese zentrale Rolle übernimmt das API-Gateway eine Vielzahl querschnittlicher technischer und sicherheitsrelevanter Aufgaben, die in der folgenden Übersicht zusammengefasst sind:
-
einheitliche Sicherheitskontrollen über alle APIs (Token-Validierung, Zugriffsschutz via IAM),
-
zentrales Routing zur Entkopplung von Frontends und Backends (Backend-Änderungen erfordern keine Anpassungen an SPAs),
-
konsistente technische Standards für alle Services (CORS, TLS, Protokolle, Header),
-
zentrale Durchsetzung von Rate Limiting, Timeouts und Circuit Breaking zum Schutz der Backends,
-
vereinheitlichtes Monitoring, Logging und Tracing für vollständige Transparenz der Anfragen,
-
Unterstützung kontrollierter Deployment-Strategien wie API-Versionierung, Canary-Releases und Blue-Green-Deployments,
-
Vermeidung redundanter Security- und Infrastruktur-Implementierungen in einzelnen Services,
-
klare und konsistente Exposition interner und externer APIs.
Die software-technische Referenzarchitektur beschreibt im Weiteren den Aufbau des API-Gateways.
2. Servicekommunikation
Services sind ein wesentlicher Bestandteil jeder Systemlandschaft. Die software-technische Referenzarchitektur definiert HTTP als grundsätzliches Übertragungsprotokoll und weitere Vorgaben für Services zu den Themen:
-
Kommunikation mit Systemen innerhalb und außerhalb der Systemlandschaft,
-
Übertragung von Metadaten und Nutzdaten,
-
Versionierung von Services.
3. Prinzipien der Sicherheitsarchitektur
Die IsyFact-Referenzarchitektur beinhaltet auch Vorgaben für die Sicherheitsarchitektur einer Systemlandschaft, die auch über den Menüeintrag "Sicherheit" zu erreichen ist.
4. Verwendung von Produkten
Bei der Umsetzung einer Architektur für eine Anwendung oder eine Anwendungslandschaft können an vielen Stellen fertige Produkte Dritter eingesetzt werden. Das beschleunigt die Entwicklung und reduziert die Kosten.
Bei der Produktentscheidung sind zwei Seiten zu berücksichtigen: Auf der einen Seite bietet die Konzentration auf projektübergreifend einheitliche Produkte die Möglichkeit, die Fähigkeiten der Mitarbeiter zu bündeln und diese übergreifend einzusetzen. Auf der anderen Seite besteht die Gefahr, durch einen zu engen Fokus die Möglichkeiten eines Projekts zu sehr zu beschränken. Eine Lösung kann dann auch Gefahr laufen, zu allgemein zu werden, was letztlich die Komplexität steigert und größeren Aufwand verursacht.
Die für die Umsetzung der Architektur verwendeten Produkte lassen sich in die Kategorien Basistechnologien, Systemsoftware und Bibliotheken für die Anwendungsentwicklung unterteilen.
Basistechnologien: Basistechnologien legen grundlegende technische Entscheidungen fest, wie z.B. die Programmiersprache und die verwendete Web-Technologie.
Systemsoftware: Die Systemsoftware legt die technische Ablaufumgebung für die Software fest und bietet grundlegende Services für eine IsyFact-Systemlandschaft an. Hierzu gehören z.B. das Betriebssystem, der Web-Server, der Application-Server, das IAM-System und die Datenbank.
Bibliotheken für die Anwendungsentwicklung: Die Anwendungsentwicklung wird durch den Einsatz von Frameworks und entsprechenden Bibliotheken vereinfacht und beschleunigt. Die IsyFact verwendet insbesondere Spring, Hibernate und Angular.
Eine detaillierte Liste der verbindlichen und empfohlenen Produkte ist im Produktkatalog zu finden.