IVS-Architekturprinzipien: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
Zeile 134: Zeile 134:
 
* Technologieunabängigkeit
 
* Technologieunabängigkeit
 
* Benutzerfreundlichkeit
 
* Benutzerfreundlichkeit
 +
 +
 +
* Template: Technologieunabhängigkeit
 +
 +
 +
[[Datei:Anwendungsprinzip_Template.JPG|thumb|centre|400px|Anwendungsprinzip]]
 +
  
 
Technologieprinzipien:
 
Technologieprinzipien:

Version vom 21. März 2016, 14:36 Uhr

IVS-Architektur

Grundsätzlich befasst sich ein IVS-Architekt mit der funktionalen, technischen, wirtschaftlichen sowie der gestalterischen Planung und Realisierung von IVS. Über das Wissen um Realisierung von IVS hinaus liegt seine Kernkompetenz vor allem in der Schaffung von IVS-Architektur. Dabei orientiert er sich an übergeordneten Leitbildern und Zielvorstellungen seiner „Bauherren“ oder entwickelt dazu eigene Vorstellungen.

Die IVS-Pyramide

Als geeignetes Metamodell und methodisches Hilfsmittel zur überschaubaren und nachvollziehbaren Darstellung und Beschreibung von IVS-Diensten wird dem IVS-Architekten vom Arbeitskreis "ITS Systemarchitekturen“ der Forschungsgesellschaft für Straßen- und Verkehrswesen (FGSV) die beschriebene und begründete „IVS-Pyramide“ vorgeschlagen.

Die IVS-Pyramide mit 5 Ebenen

Die IVS-Pyramide

  • besteht aus fünf Schichten, die zusammen den potentiell möglichen Betrachtungs- und Darstellungsbereich einer ÖV-IVS-Rahmenarchitektur aufspannen.
  • repräsentiert den strukturellen Aufbau von IVS-Diensten, um darüber die Eigenschaften von IVS besser identifizieren, einordnen und miteinander in Beziehung setzen zu können.
  • liefert für die Beschreibung von IVS die für Geschäftsmodelle notwendige Semantik.

Die IVS-Pyramide enthält folgende Schichten:

  • Leitbild:
    • Es beschreibt die Ziele der Realisierung und Vernetzung/Integration von einem oder mehreren IVS-Diensten, welche in Anwendungsprozessen, was im einfachsten Fall eine Privatperson mit ihrem Smartphone sein kann, genutzt werden.
  • Strategieebene:
    • Sie beschreibt die strategische Bedeutung von IVS (z. B. organisations- und grenzüberschreitender Mehrwert).
  • Prozessebene:
    • Sie beschreibt, welcher Akteur an der Mehrwertbildung mit Hilfe von IVS in welcher Rolle zu beteiligen ist, wie diese Beteiligten die strategische Bedeutung beurteilen und wie Beteiligung in den Geschäftsprozessen zu verankern ist. Zudem erläutert sie die Abhängigkeiten der beteiligten Akteure bzw. Rollen und wie daraus Nutzen/Mehrwert generiert wird.
  • Informationsebene:
    • Sie identifiziert und beschreibt, welche Informationen zur Mehrwertbildung beitragen und wie diese strukturiert sind.
  • IT-Dienste und Infrastrukturebene:
    • Sie beschreiben wie die Informationen generierbar sind und wie sie bereitgestellt werden.

Die IVS-Pyramide kann in allen Phasen einer inhaltlichen Auseinandersetzung auf alle relevanten Aspekte von IVS angewendet werden. Vor allem können Forderungen nach verändertem Rollenverständnis über die Anwendung der Pyramide identifiziert und konkretisiert werden. Auch wenn IVS-Dienste verteilt realisiert werden, kann die IVS-Pyramide stets den logischen Zusammenhang vermitteln.

Ebenen von IVS-Architektur

In „Methodische Empfehlungen zur Strukturierung einer IVS-Rahmenarchitektur für Deutschland“ der FGSV werden drei aufeinander aufbauende IVS-Architekturen unterschieden:

Datei:EbenenVonArchitektur.JPG
Ebenen von IVS-Architektur

Die IVS-Rahmenarchitektur

  • legt die Gestaltungsgrundsätze fest, nach denen der IVS-Architekt bei der Planung und Realisierung von IVS vorgehen soll. Eine IVS-Rahmenarchitektur wird nur dann wirklich erfolgreich sein, wenn sie den Konsens zwischen den Beteiligten repräsentiert.

Eine IVS-Referenzarchitektur

  • konkretisiert die von der IVSRahmenarchitektur vorgegebenen Konzepte für den Gestaltungsraum einer spezifischen IVS-Domäne. Die Zahl der IVS-Referenzarchitekturen ist also nicht begrenzt. Mit dem Begriff der Domäne lassen sich Bereiche abgrenzen, in denen Wissen über einen Betrachtungsgegenstand angewandt wird. Typische Domänen im ÖV sind Verkehrsräume, Organisationsformen, Systemwelten, etc. Eine IVSReferenzarchitektur ist auch die Grundlage zur Spezifikation und Entwicklung der Architekturen realer Systeme und spezifischer Produkte für spezielle IVS-Anwendungsdomänen. Der Nutzen einer Referenzarchitektur ist dann am größten, wenn sie von einer „größeren“ Gemeinschaft akzeptiert und quasi als Standard eingesetzt und genutzt wird.

Die Architektur realer IVS-Systeme

  • ist die tatsächliche Umsetzung einer IVS-Referenzarchitektur bis zur letzten Detaillierungsebene in einem konkreten Anwendungsfall. Konzeptmerkmale (semantische Merkmale) werden auf konkrete Architekturen abgebildet (Konzept Instanziierung).

Abbildung der Ebenen der IVS-Pyramide auf die Archtekturdomänen vvon TOGAF

Um die Diskussion um Begriffe und ihre Semantik von Anfang an im Projekt objektiver und effektiver zu gestalten und auf die übergeordnete Zielsetzung der Schaffung einer IVS-Rahmenarchitektur auszurichten, bietet die Standardisierungsinitiative TOGAF das Metamodell der in Schichten angeordneten Architekturdomänen an, mit dem Ziel unter dem Schlagwort Unternehmensarchitektur, das komplexe Verhalten von Unternehmen auf der Grundlage vereinbarter (standardisierter) Grundkonzepte (sogenannte Basisarchitekturen) zukünftig gleichartig beschreiben zu können. Hier schließt sich auch der Kreis zu der aktuellen Vorstellung von IVS-Architektur,der von der IVS-Pyramide als hierarchisches Ordnungsprinzip geprägt ist, das auf die Schichten des TOGAF-Schichtenmodells abgebildet werden kann.

Abildung der Ebenen der IVS-Pyramide auf die Archtekturdomänen von TOGAF

Natürlich muss klar sein, dass von Los 1 nur die wichtigsten Ebenen/Unterebenen und deren Bereiche adressiert werden können und müssen, eben diejenigen, die für IVS-Funktionalität und IVS-Verhalten bedeutsam sind (Qualität vor Quantität). Bildhaft gesprochen geht es darum, für IVS solche Teilbereiche in den TOGAF-Ebenen zu identifizieren, die geeignet sind, allgemeine Gestaltungsziele für IVS-Architekturen (Referenzarchitekturen, Reale Systeme) den allgemeinen TOGAF-Zielen unterzuordnen. IVS-Ziele sind in diesem Sinne spezieller als TOGAF-Ziele. Konformität wäre z.B. gegeben, wenn Merkmale eines IVS-Ziels auch als Merkmale eines TOGAF-Ziels feststellbar sind.

TOGAF steht insgesamt für eine semantische Struktur, die TOGAF-relevante Konzepte in Beziehung bringt und damit eine Grundordnung für übergreifendes Gestalten von TOGAF-Domänen vermittelt. Durch Gestalten sollen Formen von Zusammenarbeit von IVS-Akteuren in globalisierenden Zusammenhängen verbessert oder gar erst ermöglicht werden. Effizienz und Effektivität sind dabei wesentliche Qualitätsmerkmale in der Ausrichtung gestalterischer Entscheidungen.

IVS als Ganzes ist bisher „unscharf“ definiert. Es müssen also Wege für Interpretationen gefunden werden, auf denen für Dritte nachvollziehbar dargestellt werden kann, wie eine allgemeine TOGAF-Sicht auf TOGAF-Konzepte auf IVS-Konzepte abgebildet oder damit in Beziehung gebracht werden können. Dazu muss umgekehrt auch dargelegt werden, dass die gemeinhin spezielleren IVS-Konzepte eine TOGAF-Relevanz in sich tragen. Mit anderen Worten, es muss verifizierbar werden, dass der IVS-Gestaltungsfokus dem TOGAF-Gestaltungszweck entspricht. Für die sprachliche Ausstattung der Bestandteile der Terminologie und ihre Darstellung sollte man sich auf die Verwendung von – möglichst schon existierenden und bewährten – Standards und den dort angebotenen Konzepten einigen. Nur damit können subjektive Sachverhalte zumindest in der Darstellung objektiviert werden. In der folgenden Liste sind einige Standards aufgeführt, die für die anstehenden „High Level“-Betrachtungen im Projekt TOGAF Version 9.1, 2011 hinaus sehr nützlich sein könnten und deren Verwendung zur Diskussion gestellt werden sollte:

  • Business Motivation Model (BMM) Specification; OMG dtc/07-08-03
  • Business Process Definition Meta Model; Volume 1: Common Infrastructure Version 1.0; OMG Document: formal/2008-11-03; http://www.omg.org/spec/BPDM/20080501
  • Business Process Model and Notation (BPMN) OMG Document: formal/2009-01-03;
  • Unified Modeling Language (UML); OMG-Spezifikation: http://www.omg.org/spec/UML/
  • Bon; Service Strategie basierend auf ITIL v3- Eine Management Guide; Van Haaren Publishing, 2008
  • MDA Guide Version 1.0.1; OMG Document: omg/2003-06-
  • Information Technology – Open Distributed Processing – Reference Model: Overview ; International Standard ISO/IEC 10746-1:1998(E)
  • Meta Object Facility (MOF); OMG Spezifikation: http://www.omg.org/mof/
  • Semantics of Business Vocabulary and Business Rules (SBVR), v 1.0; OMG Document: formal/2008-01-02; http://www.omg.org/spec/SBVR/1.0/PDF/
  • Service oriented architecture Modeling Language (SoaML) – Specification for the UML Profile and Metamodel for Services (UPMS); Revised Submission; OMG document: ad/2008-08-04
  • Reference Architecture for Service Oriented Architecture Version 1.0; Public Review Draft 1, 23 April 2008; OASIS Open; http://www.oasis-open.org
  • Reference Model for Service Oriented Architecture 1.0; Committee Specification 1, 19 July 2006; OASIS Open; http://www.oasis-open.org
  • Software & Systems Process Engineering Meta Model Specification v.2 (SPEM); OMG Dokument:formal/2008-04-01; http://www.omg.org/spec/SPEM/20070801

Für allgemeine Ziele und Wünsche eignen sich BMM und SBVR. Für die allgemeine Auseinandersetzung mit Prozessen wird der Standard SPEM empfohlen. Welche Standards neben TOGAF selbst sinnvollerweise zusätzlich eingesetzt werden sollen, muss zu Beginn des Projekts vereinbart werden.

Architekturprinzipien

Prinzipien

Prinzipien stellen Grundsätze dar, die nicht nur dauerhaft gelten, sondern auch selten geändert werden sollten. Sie beschreiben die Art und Weise, wie die Organisation ihre Aufgaben zu erfüllen hat. Prinzipien können für verschiedene Ebenen entwickelt und definiert werden.

Architekturprinzipien

Architekturprinzipien stellen verbindliche Grundsätze und auch Orientierungshilfen zur Erstellung einer Architektur dar. Zusätzlich können Architekturprinzipien in folgende Untergruppen aufgeteilt werden:

  • Geschäftsprinzip
  • Daten-/Informationsprinzip
  • Anwendungsprinzip
  • Technologieprinzip

Template

Folgendes Template wird vorgeschlagen, um Prinzipien zu beschreiben:


Datei:Prinzip Template.JPG
Template


Beispiele

Architekturprinzipien:

  • Serviceorientierung (SOA)

Geschäftsprinzipien:

  • Vorrang der Prinzipien in der gesamten Organisation
  • Nutzen für die Organisation maximieren
  • Konformität mit dem Gesetz
  • IT-Verantwortlichkeit
  • geistiges Eigentum schützen


  • Template: Vorrang der Prinzipien in der gesamten Organisation


Datei:Geschäftsprinzip Template.JPG
Geschäftsprinzip


Daten-/Informationsprinzipien:

  • Datensicherheit
  • Zugänglichkeit der Daten
  • Verbreitung der Daten
  • allg. verbreitetes Vokabular und Definitionen


  • Template: Datensicherheit


Datei:Daten-Informationsprinzip Template.JPG
Daten-/Informationsprinzip


Anwendungsprinzipien:

  • Technologieunabängigkeit
  • Benutzerfreundlichkeit


  • Template: Technologieunabhängigkeit


Datei:Anwendungsprinzip Template.JPG
Anwendungsprinzip


Technologieprinzipien:

  • Interoperabilität
  • Kontrolle der verschiedenen Technologien
  • reaktionsfähiges Change-Management
  • bedarfsgerechte Änderungen


Strategie-Ebene

zur Ergänzung der IVS-Richtlinie 2010/40/EU des Europäischen Parlaments und des Rates in Bezug auf die Bereitstellung von Informationsdiensten für sichere Parkplätze für Lastkraftwagen und andere gewerbliche Fahrzeuge]

Geschäftsprozess-Ebene

  • Service-Orientierung
  • Datenaustasuch über den National Access Point MDM

Informationsarchitekur-Ebene

  • Offene Schnittstellen
  • Nutzung und Anwendung internationaler Standards für den Datenaustausch
Abgerufen von „http://wikiivs.albrechtconsult.com/index.php?title=IVS-Architekturprinzipien&oldid=1545“