Katalog IVS-Architekturprinzipien

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
Prinzip Aussage Begründung Auswirkungen
Verbindlichkeit der Prinzipien Diese Architekturprinzipien sind verbindlich für alle öffentlichen Institutionen. Jedes Team und jede Einzelperson muss die Architekturprinzipien berücksichtigen oder erklären, warum diese nicht berücksichtigt werden können. Die Erfüllung der Architekturprinzipien ist der einzige Weg, einen konsistenten und messbaren Service bieten zu können. Umfassende Abweichung von den Architekturprinzipien erhöht die Komplexität der Services und führt zu potentiell höheren Gesamtkosten.
Wiederverwendung vor Kauf vor Erstellung Anwendungen, Systemkomponenten und Daten sollen wiederverwendet werden, wo immer möglich, gekauft als Standardlösung, wo nötig, und erstellt bzw. erzeugt werden nur dann, wenn es eindeutige Anforderungen gibt, die anderweitig nicht erfüllt werden können. Wiederverwendung bringt das beste Preis-Leistungsverhältnis durch Vereinfachung der IT-Landschaft, Reduzierung der Datenverdopplung und Übernahme bekannter Geschäftsprozesse. Die Finanzierung von Programmen und Projekten muss auf einer projektübergreifenden Planung basieren, um unnötige Duplizierung von IT-Lösungen zu vermeiden.
Daten wie Anlagegüter verwalten Daten werden so behandelt, dass ihre Korrektheit und Qualität zur Unterstützung von gut informierten Geschäftsentscheidungen optimiert werden. Daten und Informationen sind der Kern von Intelligenten Verkehrs-Systemen und müssen entsprechend behandelt werden. Alle Projekte, die eine signifikante Menge an Daten verwenden, müssen einen Datenkatalog führen, in dem die verwendeten Daten beschrieben werden.
Daten beherrschbar machen Die Mehrfachverwendung von Daten muss unterstützt werden. Der Wildwuchs an Datenmodellen soll verhindert werden. Standarddatenmodelle,- datenelemente und andere Metadaten müssen entwickelt und gepflegt werden, um einem Wildwuchs an Datenmodellen entgegen zu wirken.
Daten verfügbar machen Öffentliche Daten müssen leicht auffindbar sein. Daten, die öffentlichen Institutionen gehören, müssen verfügbar gemacht werden. Die Art und Weise, wie öffentliche Daten verfügbar gemacht werden, muss einheitlich und leicht zugänglich sein.
Bestehende Services verwenden Wo immer möglich, sollen bestehende Application Program Interfaces (APIs) verwendet werden. Gegebenenfalls können benötigte Funktionalitäten durch bestehende Services zur bereitgestellt werden Moderne Anwendungen werden auf Basis einer großen Menge an APIs realisiert. Die Wiederverwendung von Services reduziert die Projektkosten und die Realisierungszeit eines Projekts. Die Verantwortlichen für Projekte und Services müssen erfassen, welche Services existieren, gerade erstellt oder geplant werden, um Implementationskosten zu verringern. Ein Servicekatalog muss als Quelle für diese Informationen erstellt und gepflegt werden.
Bevorzugung einer serviceorientierten Architektur Anwendungen sollen durch Orchestrierung von Services, die über APIs ansprechbar sind, erstellt werden. Dieser Architekturstil ermöglicht Wiederverwendung und Interoperabilität von Services sowie erhöht die Skalierbarkeit durch lose Kopplung zwischen den Komponenten. Services müssen wohldefinierte APIs haben.
Benutzeroberflächen sollen browserbasiert realisiert werden. Benutzeroberflächen sollen webbasiert als responsive HTTP Anwendungen realisiert werden. Browserbasierte Oberflächen gewährleisten, dass Anwendungen plattformunabhängig und einfach zu benutzen sind. Es können verschiedene Geräte für die Benutzeroberflächen verwendet werden und die Pflege und Auslieferung der Anwendung werden wesentlich erleichtert. Anwendungen sind webbasiert und wenn möglich zustandslos. Beim Einsatz von Standardsoftware oder für Funktionen, deren Einsatz auf bestimmte Plattformen beschränkt ist, sind Ausnahmen erlaubt.
Anwenderforderungen schon beim Entwurf berücksichtigen Anwenderforderungen werden schon in der Entwurfsphase durch direkte Beteiligung von Anwendern festgestellt. Das Verständnis von Anwenderforderungen sowie von Funktionen und Features, die regelmäßig verwendet werden, hilft beim Entwurf von neuen und bei der Änderung von bestehender Software. Eine Gruppe bestehend aus Stakeholdern und Key-Usern wird in der Entwurfsphase benötigt, um Anwenderforderungen zu erfassen.
Prototypen für neue Applikationen und Services Prototypen erstellen und mit Anwendern testen und von ihnen lernen Es ist unmöglich alles vorauszusagen. Prototypen ermöglichen das frühzeitige Involvieren von Anwendern. Ein frühzeitiges Involvieren von Anwendern minimiert das Risiko, eine für Anwender nicht oder nur schlecht brauchbare Anwendung zu erstellen.
Offene Standards und Open Source verwenden Offene Standards müssen in allen Lösungen verwendet werden, um Interoperabilität zu erleichtern. Open Source Software soll verwendet werden, wenn sie einen vergleichbaren Funktionsumfang wie kommerzielle Software liefert. Proprietäre Standards verhindern die Wiederverwendung, reduzieren die Interoperabilität und können zu Vendor-Lock-In führen. Das beste Preis-Leistungsverhältnis bezogen auf die Gesamtkosten einer Software muss evaluiert werden, bevor die Entscheidung für kommerzielle oder Open Source Software getroffen wird.

<< Zurück zur Hauptseite