Katalog IVS-Architekturprinzipien: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Zeile 67: | Zeile 67: | ||
|- | |- | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
− | || | + | ||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ühzeitges Involvieren von Anwendern minimiert das Risiko, eine für Anwender nicht oder nur schlecht brauchbare Anwendung zu erstellen. |
|- | |- | ||
|- style="vertical-align:top;" | |- style="vertical-align:top;" | ||
− | || | + | ||Offene Standards und Open Source verwenden |
− | || | + | ||Ofene 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 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. | |
− | |||
− | |||
− | Open Source | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | || | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | | | ||
− | |- | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | Software | ||
|} | |} | ||
---- | ---- | ||
[[Hauptseite|<< Zurück zur Hauptseite]] | [[Hauptseite|<< Zurück zur Hauptseite]] |
Version vom 21. Juni 2016, 08:19 Uhr
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öhen die Komplexität der Services und führen 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 wird. | Daten und Informationen sind der Kern von Intelligenten Verkehrssystemen 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 | Stadarddatenmodelle,-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 und 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 wird wird 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 sind, 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 Stakeholder 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ühzeitges Involvieren von Anwendern minimiert das Risiko, eine für Anwender nicht oder nur schlecht brauchbare Anwendung zu erstellen. |
Offene Standards und Open Source verwenden | Ofene 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 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. |