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, die eine Anwendungslandschaft nach den IsyFact-Standards umsetzt, wird im Folgenden als IsyFact-Systemlandschaft bezeichnet. Eine solche IsyFact-Systemlandschaft beinhaltet alle IT-Systeme als technische Umsetzung der Anwendungen der Anwendungslandschaft sowie technische Systeme zur Unterstützung (z.B. Datenbanken oder Web-Server).
2. Strukturierung der Systemlandschaft
Wichtige Grundlagen für die Software-Referenzarchitektur sind die Schnittstellen und Aufruf-Beziehungen der IT-Systeme untereinander. Aufruf-Beziehungen werden stets unterschieden in interne Aufrufe, in welchen ein IT-System einer Systemlandschaft mit einem anderen IT-System derselben Systemlandschaft kommuniziert, und externe Aufrufe, in welchen ein IT-System der Systemlandschaft mit einem Anwender oder einem IT-System außerhalb dieser Systemlandschaft kommuniziert. Interne und externe Aufrufe unterscheiden sich sowohl in ihrer Authentifizierung und Autorisierung als auch (bei automatisierten Schnittstellen) in der verwendeten Technologie.
2.1. Geschäftsanwendungen
Geschäftsanwendungen implementieren allgemein die Geschäftsprozesse einer Domäne. Geschäftsanwendungen können monolithisch strukturiert sein und alle Schichten der Softwarearchitektur umfassen, von der Benutzeroberfläche über Prozesse und Geschäftslogik bis hin zur Datenspeicherung. Sie können aber auch jeweils nur Teile davon implementieren, sodass z.B. eine Geschäftsanwendung eine GUI bereitstellt, eine weitere die Geschäftslogik implementiert und eine dritte schließlich die Persistierung der Daten realisiert. In diesem Fall würde die Gesamtfunktionalität durch das Zusammenwirken der drei Geschäftsanwendungen erbracht.
Die Geschäftsanwendungen einer Systemlandschaft können sich intern gegenseitig über ihre Services aufrufen. In einem konkreten Anwendungskontext einer Systemlandschaft wird man in der Regel die Arten von Geschäftsanwendungen noch genauer definieren und dabei auch die möglichen Aufrufbeziehungen zwischen ihnen geeignet einschränken.
Für die Kommunikation mit externen Systemen muss eine Geschäftsanwendung ein Service-Gateway verwenden, egal in welche Richtung die Kommunikation verläuft.
Geschäftsanwendungen, die eine Benutzeroberfläche bereitstellen, dürfen aus Sicherheitsgründen nicht direkt vom Benutzer aufgerufen werden, sondern werden in das Portal der Systemlandschaft eingebunden.
2.2. Querschnittsanwendungen
Querschnittsanwendungen bieten Geschäftsanwendungen querschnittlich genutzte Funktionalitäten an, etwa für die Bereitstellung von Schlüsseldaten. Querschnittsanwendungen können eine eigene Datenhaltung besitzen.
Querschnittsanwendungen werden nur von internen Benutzern oder anderen IT-Systemen derselben Systemlandschaft aufgerufen. Sie rufen selbst nur andere Querschnittsanwendungen auf. Eine Ausnahme bilden Querschnittsanwendungen in Form eines Gateways, wie z.B. ein zentrales Mail-Gateway für den Versand von E-Mails an externe Empfänger.
2.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 Application-Server der Geschäftsanwendungen weiterleitet.
-
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.
2.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.
3. 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.
4. 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.
5. 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.