Katalog IVS-Architekturprinzipien: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
 
(3 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt)
Zeile 1: Zeile 1:
 +
 
{| class="wikitable"
 
{| class="wikitable"
−
! Prinzip!! Aussage !! Begründung !! Auswirkungen
 
−
 
 
|-
 
|-
−
|- style="vertical-align:top;"
+
! Prinzip
−
||Verbindlichkeit der Prinzipien
+
! Aussage
−
||These principles apply to all directorates within the company. Any team or individual is required to either comply with these principles or to explain why they can’t or won’t comply.  
+
! Begründung
−
||Compliance with these principles is the only way that a consistent and measurable level of ICT quality and service delivery can be provided to the business.
+
! Auswirkungen
−
||Wholesale divergence from the principles will increase the complexity of ICT service delivery to the business and potentially lead to higher total cost of ownership.  
+
|- style="vertical-align:top"
 +
| 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.
 +
|- style="vertical-align:top"
 +
| 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.
 +
|- style="vertical-align:top"
 +
| 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.
 +
|- style="vertical-align:top"
 +
| 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.
 +
|- style="vertical-align:top"
 +
| 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.
 +
|- style="vertical-align:top"
 +
| 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.
 +
|- style="vertical-align:top"
 +
| 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.
 +
|- style="vertical-align:top"
 +
| 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.
 +
|- style="vertical-align:top"
 +
| 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.
 +
|- 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ühzeitiges Involvieren von Anwendern minimiert das Risiko, eine für Anwender nicht oder nur schlecht brauchbare Anwendung zu erstellen.
 +
|- style="vertical-align:top"
 +
| 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.
 +
|}
  
−
|-
+
----
−
|- style="vertical-align:top;"
 
−
||Reuse before buy, before build
 
−
||Business applications, system components and data will be reused wherever possible, purchased as commodity solutions if necessary and only built if there is a unique requirement that cannot otherwise be fulfilled.
 
−
||Reuse will provide value for money by simplifying the ICT landscape, reducing data duplication and adopting common business processes.
 
−
||Funding of programmes and projects will need to cater for cross project delivery (shared services) to avoid unnecessary duplication of ICT services (silos).
 
−
To maximise value and reduce complexity requirements for shared services should be captured cross project.
 
−
 
 
−
|-
 
−
|- style="vertical-align:top;"
 
−
||Seek architecture approval
 
−
||All projects and programmes will be subject to architectural approval at key stages throughout the delivery lifecycle.
 
−
||To ensure that projects collectively move in the technology direction that is required by the Highways EA. 
 
−
To control and prevent divergence from strategic intent and to understand the trade-offs around any divergence.
 
−
||Projects must provide a clear business justification for changes to the architecture.
 
−
Changes to the architecture need to be formally managed so that divergence is controlled. 
 
−
Exceptions may be granted on the understanding that re-alignment is achieve at some future date through an approved plan of action.
 
−
Dispensations would normally be granted for a limited duration only.
 
−
 
 
−
|-
 
−
|- style="vertical-align:top;"
 
−
||Manage data as an asset
 
−
||Data will be managed to ensure its accuracy and quality to support informed business decisions.
 
−
||Information is the lifeblood of the company and data needs to be managed accordingly. Accurate, timely data is critical to deliver information and support informed business decisions.
 
−
||There must be an Information Asset Owner (IAO) that is responsible for assuring that information is properly managed.
 
−
All projects that handle a significant amount of data must have a data management plan and information asset register to describe the data used and the security classification of the data.
 
−
 
 
−
|-
 
−
|- style="vertical-align:top;"
 
−
||Ensure data is mastered and shared
 
−
||Everyone must work from the same data and know its source.
 
−
||Proliferation of structured data and unstructured data must be controlled to ensure accurate data is provided.
 
−
||Standard data models, data elements, and other metadata that defines the data needs to be developed and maintained. 
 
−
Technology solutions may necessitate technical copies of data. Any such technical requirement must have its design reviewed to ensure that the copies are synchronised with approved master sources of data. 
 
−
Technical copies of data must not be allowed as an alternative to system integration unless the copy of data can be synchronised with its recognised master.
 
−
 
 
−
|-
 
−
|- style="vertical-align:top;"
 
−
||Make data accessible
 
−
||Data must be easy to find and retrieve and present a single version of the truth.
 
−
||Data must come from a single authorised source that can be directly referenced.
 
−
||The way information is accessed and displayed must be sufficiently adaptable to meet a wide range of users and their corresponding methods of access.
 
−
 
 
−
|-
 
−
|- style="vertical-align:top;"
 
−
||Use existing services
 
−
||Don’t do everything yourself, consume and use existing Application Program Interfaces (APIs). The functionality needed could be provided by an existing service.
 
−
||Modern applications (digital services) are built on top of a wide range of APIs.  Eliminating the effort designing and implementing a duplicate service will reduce ICT project costs and shorten the time to deliver ICT projects.
 
−
||Projects and ICT service providers need to understand what services exists, are being built and planned so that they can plan and cost implementation activities accordingly.
 
−
A service catalogue needs to be developed and maintained as the source of this information.  This must be established for Future ICT bottom-up based on users’ needs to avoid defining services based on existing legacy IT services.
 
−
There must be a single service catalogue supporting ITSM and EA.  This needs to communicate a pipeline of services to clearly show those proposed, under development, in operation and being retired.
 
  
−
|-
 
−
|- style="vertical-align:top;"
 
−
||Build services not applications
 
−
||Applications will be built as a collection of services that expose an Application Program Interface (API) enabling them to be combined to deliver users what they need.
 
−
||This facilitates reuse, interoperability and the ability to scale by reducing tight dependencies between components.
 
−
||Cloud-services and COTS products are expected to have well-defined APIs.
 
−
An overlap of functionality can exist within multiple Cloud and COTS solutions. This must be managed to prevent unnecessary duplication of services.
 
−
Service Design will need to cover Supplier Management, Availability Management, Capacity Management, Information Security Management and Service Continuity Management.
 
−
 
−
|-
 
−
|- style="vertical-align:top;"
 
−
||User interfaces should be browser-based
 
−
||User interfaces shall be delivered as web-based HTTP applications using using HTML5, CSS and JavaScript.
 
−
||Ensures that applications are independent of underlying platforms and are easy to use. This enables accessibility across different devices and decreases maintenance and deployment effort.
 
−
||Applications are web-based and stateless as reasonably possible. 
 
−
Commercial Off-The-Shelf (COTS) solutions may limit choices.
 
−
Exceptions may arise for functions and services that are constrained by the selected platform, for example the roadside (cold and wet) technology.
 
−
 
−
|-
 
−
|- style="vertical-align:top;"
 
−
||Design applications to meet user needs
 
−
||User needs will be discovered from direct participation with users and evidence gathered on existing services usage.
 
−
||Understanding user needs and what functions and features are regularly used by them in existing services helps to prioritise and plan the delivery of new services and make changes to existing ones.
 
−
||A small team will be required consisting of stakeholders and technical staff. Expertise in User Experience (UX) consultancy will be required.
 
−
 
−
|-
 
−
|- style="vertical-align:top;"
 
−
||Pilot new applications and services
 
−
||Build a prototype, test it with users and learn from it.
 
−
||It is impossible to accurately predict everything upfront. A try before you buy approach validates investment plans, designs and technologies. Prototypes enable users to provide early feedback about the design of the solution.
 
−
||Projects must be open to investing and testing new products and services on a small scale in order to de-risk large scale delivery projects. Consultation with Service Management is necessary to aid transition planning for service operation.  This is only required for validated solutions that are being recommended for further development.
 
−
 
−
|-
 
−
|- style="vertical-align:top;"
 
−
||Use Open Standards and Open Source
 
−
||Open standards must be used in all solution designs to enable interoperability. 
 
−
Open source software must be compared and considered alongside commercial software when selecting technology solutions.
 
−
||Closed proprietary standards restrict reuse, reduce interoperability and can create vendor lock-in that leads to unforeseen financial costs.
 
−
Compliance with HM Government Open Standards Principles and GOV.UK Technology code of practice Point 5 and 6.
 
−
||Exit, rebid and rebuild costs must be taken into consideration during procurement decisions for best value for money comparisons, between open source and proprietary solutions.
 
−
Open Source is not necessarily free to use. Many independent software vendors and value added resellers use open source technology within proprietary for-profit services.  Other companies provide commercial service management wrappers around open source products.  Commercial software needs to be considered alongside open source equivalents from a total cost of ownership perspective.
 
−
 
−
|-
 
−
|- style="vertical-align:top;"
 
−
||Exploit the Cloud
 
−
||Solutions will be assessed to determine the benefits of migration to Cloud-based service models for infrastructure, platform and software.
 
−
||Assessment of architectures, workloads, finance, business risks, operations and security will determine if a solution can be re-hosted
 
−
(IaaS), rebuilt (PaaS), replaced (SaaS) or refactored as a hybrid solution.
 
−
||Not every ICT service will be appropriate for delivery via the cloud.  Evaluation criteria need to be created to provide the basis for an assessment model that can be used to justify architecture decisions.
 
−
Cloud Service Providers must evidence the ITSM best practices, security and data protection standards followed.
 
−
HE Service Management must include change management of SaaS based subscriptions to ensure that costs are controlled effectively. Disintermediation must be controlled. Cloud services must not be procured directly by business teams. This can unintentionally introduce unnecessary OPEX costs and inhibit reuse.
 
−
 
−
|-
 
−
|- style="vertical-align:top;"
 
−
||Manage technical debt and obsolesence
 
−
||The Future ICT for the company must make changes easier.  Any tactical decisions that introduce technical debt (quick but messy solutions) will only be endorsed if there is a recognised actionable plan to address both of them technically and financially. 
 
−
||Unaddressed technical debt increases the complexity and costs of maintaining ICT making it harder to upgrade software, transition services and deliver solutions that meet users’ needs.
 
−
||Reducing technical debt must become part of the companies culture so that the current accrued debt in the ICT estate can be addressed.
 
−
Dispensations for short term technical debt to meet tactical business imperatives can be granted.
 
−
Applications and services need to be designed and delivered to be as technology independent as possible.  An increased level of servicebased architecture will be required. See AP1. 
 
−
Delivery projects adopting an Agile delivery method will need to have an Architecture Owner to safeguard against adding new technical debt into the Future ICT estate.
 
−
Software and hardware ICT assets (non-Cloud) must be recorded and managed in a configuration management system.
 
−
 
−
|}
 
−
----
 
 
[[Hauptseite|<< Zurück zur Hauptseite]]
 
[[Hauptseite|<< Zurück zur Hauptseite]]

Aktuelle Version vom 10. Dezember 2017, 21:21 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ö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

Abgerufen von „http://wikiivs.albrechtconsult.com/index.php?title=Katalog_IVS-Architekturprinzipien&oldid=12526“