IVS-Capibilities: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
 
(78 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
−
== Geschäftsfähigkeiten (Capabilities) in TOGAF ==
 
  
−
===Definition===
+
== Geschäftsfähigkeiten (Capabilities) in TOGAF ==
−
Mit '''Capability''' wird in TOGAF eine '''Fähigkeit''' bezeichnet, die eine Organisation, Person oder ein System besitzt. Capabilities werden mit allgemeinen bzw. übergeordneten Begriffen benannt und erfordern typischerweise eine Kombination von Menschen, Organisation, Prozessen und Technologie, um realisiert werden zu können. (Quelle: Bitkom, 2011 und TOGAF 9.1)
 
  
−
Von strategischer Bedeutung für jedes Unternehmen sind sog. ''' Business Capabilities (Geschäfts-Fähigkeiten)'''. Sie kennzeichen Eigenschaften einer Institution/eines Unternehmens, die unbedingt erforderlich sind, damit es seine strategischen Ziele erreichen kann.
 
  
−
'''Cabilities...'''
+
=== Capability-Definition ===
−
* sind die eigentlichen Bausteine für das Geschäft (Business) einer Institution/eines Unternehmens
 
−
* repräsentieren stabile geschäftliche Funktionen
 
−
* sind einzigartig und unabhängig voneinander
 
−
* abstrahieren von der Organisation einer Institution/eines Unternehmens
 
−
* repräsentieren letzlich das Geschäftsinteresse einer Institution/eines Unternehmens
 
  
−
Das Besondere an Capabilities ist zum einen Ihre Zeitstabilität, d.h. sie ändern sich sehr selten bzw. nur dann, wenn sich die strategische Ausrichtung einer Institution/eines Unternehmen ändert. Zum zweiten werden sie von der Fachseite erarbeitet und nicht wie oftmals üblich, von der IT-Seite diktiert. Insofern bilden sie eine Abstraktionsschicht zwischen Geschäfts- und IT-Prozessen.
+
[[File:TMValueChainMitPyramiden.png|thumb|right|350px|IVS-Wertschöpfungskette für einen Verkehrsmanagement-Service]]
  
−
===Ausprägung===
+
Mit '''Capability''' wird in TOGAF eine '''Fähigkeit''' bezeichnet, die eine Organisation, Person oder ein System besitzt. Capabilities werden mit allgemeinen bzw. übergeordneten Begriffen benannt und sind typischerweise eine Kombination von Menschen, Organisation, Prozessen und Technologie, um realisiert werden zu können.<span><ref>TOGAF® Version 9.1: The Open Group. Online verfügbar unter http://pubs.opengroup.org/architecture/togaf9-doc/arch/, zuletzt geprüft am 02.11.2017.</ref></span>
−
Fähigkeiten lassen sich strukturieren. D.h. es gibt übergeordnete Fähigkeiten, die wiederum andere Fähigkeiten erfordern. Fähigkeiten sollten nicht redundant sein.
 
  
−
[[Datei:Capa_dimensions.png| center| left | 400px| Capabilities: Ausprägung]]
+
Von strategischer Bedeutung für jedes Unternehmen sind sog. '''Business Capabilities (Geschäfts-Fähigkeiten)'''. Sie kennzeichnen Eigenschaften einer Institution/eines Unternehmens, die unbedingt erforderlich sind, damit sie/es ihre/seine&nbsp;strategischen Ziele erreichen kann.
 +
 
 +
'''Capabilities&nbsp;...'''
 +
 
 +
*sind die eigentlichen Bausteine für das Geschäft (Business) einer Institution/eines Unternehmens.
 +
*repräsentieren stabile geschäftliche Funktionen.
 +
*sind einzigartig und unabhängig voneinander.
 +
*abstrahieren von der Organisation einer Institution/eines Unternehmens.
 +
*repräsentieren letztlich das Geschäftsinteresse einer Institution/eines Unternehmens.
 +
 
 +
Das Besondere an Capabilities ist zum einen ihre Zeitstabilität, d.h. sie ändern sich sehr selten bzw. nur dann, wenn sich die strategische Ausrichtung einer Institution/eines Unternehmens ändert. Zum zweiten werden sie von der Fachseite erarbeitet und nicht wie oftmals üblich, von der IT-Seite diktiert. Insofern bilden sie eine Abstraktionsschicht zwischen Geschäfts- und IT-Prozessen.
 +
 
 +
=== Capability-Dimensionen ===
 +
 
 +
Wie nachfolgende Abbildung symbolisieren soll, wirkt sich die Schaffung von Capabilities in der Regel auf alle Ebenen (der IVS-Pyramide) einer Institution/eines Unternehmens aus. Dies wird mit den '''Dimensionen einer Capability''' bezeichnet und ist oft mit schwierigen Eingriffen in bestehende Unternehmens-/Institutions-Strukturen und mit entsprechenden, für die Beteiligten, oft schmerzhaften Veränderungsprozessen verbunden. Vor diesem Hintergrund müssen Fähigkeiten in konkreten Dimensionen strukturiert werden. D.h. es gibt übergeordnete Fähigkeiten, die wiederum andere Fähigkeiten erfordern. Fähigkeiten sollten nicht redundant sein.
 +
 
 +
[[File:Capa dimensions.png|thumb|center|400px|Capabilities: Ausprägung]]
 +
 
 +
== Übertragung des Capability-Konzepts auf IVS-Architektur ==
  
−
== Übertragung des Capability-Konzepts auf IVS-Architektur ==
 
  
 
=== Einführung ===
 
=== Einführung ===
−
[[Datei:IVSWertschöpfungsnetzwerk_neu.png|thumb|right|150px|IVS-Wertschöpfungsnetzwerk]]
 
  
−
Vor dem Hintergrund dass die meisten IVS-Dienste nur über '''Kooperation''', d.h. die Vernetzung und das Zusammenwirken verschiedener IVS-Akteure, entstehen (siehe auch [[IVS-Rollenkonzept | IVS-Wertschöpfungs- und Rollenkonzept]]), stellt sich für jeden einzelnen IVS-Akteur die Frage, über welche Capabilities (Fähigkeiten) er verfügen oder welche er noch entwickeln muss, damit eine erfolgreiche Kooperation im Rahmen einer IVS-Wertschöpfungskette/eines IVS-Wertschöpfungsnetztwerks zustande kommt.  
+
[[File:IVSWertschöpfungsnetzwerk neu.png|thumb|right|150px|IVS-Wertschöpfungsnetzwerk]]
 +
 
 +
Im Sinne von IVS repräsentiert IVS-Capability einen Satz von Fähigkeiten, die ein IVS-Akteur als Bestandteil einer IVS-Prozesskette (IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk) mitbringen muss, damit am Ende der potentielle Nutzen des IVS-Dienstes verwirklicht werden kann.
 +
 
 +
Dabei werden Anforderungen der End-Nutzer an den Nutzen von IVS-Diensten immer umfangreicher und komplexer. Daraus resultiert, dass die meisten IVS-Dienste nur über '''Kooperation''', d.h. die Vernetzung und das Zusammenwirken verschiedener IVS-Akteure mit ganz spezifischen Fähigkeiten und Nutzenbeiträgen entstehen können (siehe auch [[IVS-Rollenkonzept|IVS-Wertschöpfungs- und Rollenkonzept]]). Vor diesem Hintergrund gewinnt „die Kooperation von IVS-Akteuren“ für IVS immer mehr an Bedeutung. Alle Lösungen im Bereich von IVS, d.h. technische Produkte oder Dienstangebote etc., müssen im Grundsatz dem Anspruch genügen, dass sie auch als Bestandteil einer Wertschöpfungskette bzw. eines Wertschöpfungsnetzwerks darstellbar sind. Daraus muss hervorgehen, in welcher Beziehung die beteiligten IVS-Akteure in ihren Rollen zusammenarbeiten und welche Fähigkeiten sie in welchen Dimensionen entwickeln müssen, um den von ihnen erwarteten Nutzen bzw. Mehrwert bei der Wertschöpfung generieren zu können.
 +
 
 +
Vor diesem Hintergrund muss sich jeder einzelne IVS-Akteur, der sich an einer IVS-Wertschöpfungskette/einem IVS-Wertschöpfungsnetzwerk beteiligen will, die Fragen stellen:
 +
 
 +
*über welche '''Capabilities (Fähigkeiten)''' er verfügen oder welche er noch entwickeln muss, damit eine erfolgreiche Kooperation und Wertschöpfung zustande kommen kann und
 +
*welche '''Capability-Dimensionen''' die Entwicklung der Capabilities auf Menschen, Organisation, Prozesse und Technologien seiner Institution/seines Unternehmens haben werden.
 +
 
 +
Ein Beispiel für das Segment "''IVS-Inhalteanbieter der IVS-Wertschöpfungskette für Zuständigkeitsübergreifendes Verkehrsmanagement"''&nbsp;zeigt folgende Tabelle:
 +
 
 +
{| class="wikitable" style="width: 1260px;"
 +
|+
 +
|+
 +
|-
 +
! colspan="2" style="width: 723.88px;" | IVS-Capability
 +
! colspan="3" style="width: 441.12px;" | Beteiligungen
 +
! rowspan="2" | Abhängigkeit von anderen IVS-Capabilities
 +
|-
 +
| style="text-align: center;" | '''Bezeichnung'''
 +
| style="width: 617.88px; text-align: center;" | '''Beschreibung'''
 +
| style="width: 1px; text-align: center;" | '''Beteiligte IVS-Rollen'''
 +
| style="text-align: center;" | '''Beteiligte IVS-Prozesse'''
 +
| style="text-align: center;" | '''Beteiligte IVS-Anwendungsprozesse'''
 +
|- style="vertical-align:top;"
 +
| '''Gewinnung von Planungsdaten'''
 +
| style="width: 617.88px;" | Durchgehende Planung und Versorgung von Versorgungsartefakten (digitale Straßenkarte, LCL-Liste, Versorgungslisten der Anlagen, etc.), die für zuständigkeitsübergreifendes&nbsp;Verkehrsmanagement erforderlich sind.
 +
| style="width: 1px;" |
 +
*Planungsverantwortliche der IVS-Akteure
 +
*Versorgungsverantwortliche der öffentlichen und privaten IVS-Akteure
 +
 
 +
| Planungs- und Versorgungsprozesse der öffentlichen und privaten IVS-Akteure
 +
| Planungs- und Versorgungsanwendungen wirken direkt auf eine Versorgungsdatenbank, in der mehrere (versionierte) Versorgungen gleichzeitig zur Verfügung gestellt werden. Dies erlaubt das Einspielen und systemweite Umschalten auf eine neue Versorgung im Onlinebetrieb.
 +
!
 +
|- style="vertical-align:top;"
 +
| '''Erfassung und Sammlung von Realzeit-Daten und -Informationen'''
 +
| style="width: 617.88px;" |
 +
Auf Basis verschiedener Sensortypen und Erfassungsmethoden werden Daten in Real-Zeit erfasst:
 +
 
 +
*Verkehrsstärke und -geschwindigkeit, Belegungsgrad
 +
*Trajektorien (Reisezeit je Reiseabschnitt
 +
*Floating-Car-Daten
 +
 
 +
| style="width: 1px;" | Datenerfassungssysteme der öffentlichen und privaten IVS-Akteure
 +
| Datenerfassungsprozesse der öffentlichen und privaten IVS-Akteure
 +
|
 +
|
 +
|- style="vertical-align:top;"
 +
| '''Erfassung von Ereignissen und Erkennung von Störungen'''
 +
| style="width: 617.88px;" |
 +
*Vorhersehbare Ereignisse (Baustellen, Veranstaltungen, Messen...)
 +
*Unvorhersehbare Störungen im Netz (Unfälle, Naturereignisse...)
 +
 
 +
| style="width: 1px;" |
 +
*<u>Ereignisse</u>: Baustellenmanagementsysteme, Redaktionsplätze, Ereigniskalender...
 +
*<u>Störungen</u>: Automatische Systeme zur Erkennung von Störungen, Polizei, Staumelder...  
 +
 
 +
|
 +
*Ereignis-Erfassungsprozesse
 +
*Störungs-Erkennungsprozesse
 +
 
 +
|
 +
*Manuelle Ereignis-Erfassung (Redaktionsplatz)
 +
*Automatische Ereignis-Erfassung (Event-Kalender)
 +
*Manuelle Störungs-Erfassung (Polizei, Staumelder)
 +
*Automatische Störungs-Erfassung (Incident-Detection-System)
 +
 
 +
| Erfassung und Sammlung von Echtzeit-Daten und -Informationen
 +
|}
 +
 
 +
=== Interoperabilität als Schlüsseldimension der Kooperationsfähigkeit ===
  
−
„Kooperation“ hat also für IVS eine sehr umfängliche Bedeutung. Vor diesem Hintergrund müssen alle Lösungen im Bereich IVS, d. h. technische Produkte oder Dienstangebote, im Grundsatz dem Anspruch genügen, dass sie auch als Bestandteil einer Wertschöpfungskette bzw. Wertschöpfungsnetzwerk darzustellen sind. Daraus muss hervorgehen, in welcher Beziehung die beteiligten IVS-Akteure in ihren Rollen zusammenarbeiten und welche Fähigkeiten sie entwicklen müssen, um den von ihnen erwarteten Nutzen bzw. Mehrwert generieren zu können.
+
[[File:IVS-Interoperabilität Horizontal.png|thumb|right|400px|Interoperabilität zwischen den Schichten der IVS-Architekturpyramide]]
  
−
=== Interoperabilität als Schlüsselbegriff ===
+
Einer der Schlüssel für erfolgreiche Kooperation ist die '''Interoperabilität der beteiligten IVS-Akteure''' einer IVS-Wertschöpfungskette/eines IVS-Wertschöpfungsnetzwerks. Im IVS-Kontext bedeutet Interoperabilität die Fähigkeit voneinander unabhängiger IVS-Akteure, mit u.U. ganz heterogenen Strategien, Geschäftsprozessen, Informationsstrukturen und IT-Systemen in IVS-Wertschöpfungsketten im Sinne der Informationslogistik, möglichst nahtlos zusammenzuarbeiten, um Informationen auf effiziente und verwertbare Art und Weise auszutauschen und sie am Ende dem Benutzer zur Verfügung zu stellen.
−
[[Datei: IVS-Interoperabilität_Horizontal.png | thumb| right | 400px| Interoperabilität zwischen den Schichten der IVS-Architekturpyramide ]]
 
  
−
Einer der Schlüssel für erfolgreiche Kooperation ist die '''Interoperabilität der beteiligten IVS-Akteure''' einer IVS-Werschöpfungskette/eines IVS-Wertschöpfungsnetzwerks. Im IVS-Kontext bedeutet Interoperabilität die Fähigkeit voneinander unabhängiger IVS-Akteure, mit u.U. ganz heterogenen Strategien, Geschäftsprozessen, Informationsstrukturen und IT-Systemen in IVS-Wertschöpfungsketten im Sinne der Informationslogistik möglichst nahtlos zusammenzuarbeiten, um Informationen auf effiziente und verwertbare Art und Weise auszutauschen und am Ende dem Benutzer zur Verfügung zu stellen.  
+
Hier setzt das Interesse des IVS-Architekten und der IVS-Architektur ein. Der Begriff Interoperabilität darf nicht auf IT-Aspekte reduziert werden. Für den erfolgreichen Aufbau von IVS-Wertschöpfung muss Interoperabilität für alle Beteiligten nachvollziehbar auf allen Ebenen von IVS-Architektur hergestellt werden und durch entsprechende Architektur-Bausteine repräsentiert werden.
  
−
Der Begriff Interoperabilität darf nicht auf IT-Aspekte reduziert werden. Für den erfolgreichen Aufbau von IVS-Wertschöpfung muss Interoperabilität auf allen Ebenen von IVS-Architektur hergestellt werden.
+
Als geeignetes Metamodell und methodisches Hilfsmittel zur überschaubaren und nachvollziehbaren Darstellung und Beschreibung von IVS-Diensten wird dem IVS-Architekten die [[IVS-Architekturprinzipien|'''IVS-Pyramide''']] vorgeschlagen. Im Kontext der Capability-Diskussion eignet sie sich besonders auch als Visualisierungsmodell für Interoperabilität auf allen Ebenen von IVS-Architektur.
  
−
Als geeignetes Metamodell und methodisches Hilfsmittel zur überschaubaren und nachvollziehbaren Darstellung und Beschreibung von IVS-Diensten wird dem  IVS-Architekten die [[IVS-Architekturprinzipien | '''IVS-Pyramide''']] vorgeschlagen. Im Kontext der Capability-Diskussion eignet sie sich besonders auch als Visualisierungsmodell für Interoperabilität auf allen Ebenen von IVS-Architektur.
 
  
 
=== Formen von Interoperabilität ===
 
=== Formen von Interoperabilität ===
  
−
Im IVS-Architekturkontext ist Interoperabilität Bestandteil von Verhalten auf den Ebenen von IVS-Architektur. Diesen Zusammenhang zeigt - mit den Darstellungsmitteln der IVS-Architekturpyramide dargestellt - nebenstehende Abbildung.
+
Im IVS-Architekturkontext ist Interoperabilität ein Bestandteil von Verhalten auf den Ebenen von IVS-Architektur. Diesen Zusammenhang zeigt - mit den Darstellungsmitteln der IVS-Architekturpyramide - die obere Abbildung.
  
−
Interoperabilität wird sichtbar an Schnittstellen. Generell müssen dabei zwei unterschiedliche Formen von Interoperabilität unterschieden werden:
+
Interoperabilität wird sichtbar an Schnittstellen. Generell müssen dabei zwei folgende Formen von Interoperabilität unterschieden werden:
  
−
* '''Kommunikative Interoperabilität''': Kommunikatives Verhalten an Schnittstellen  
+
*'''Kommunikative Interoperabilität''': Kommunikatives Verhalten an Schnittstellen  
−
* '''Verhaltens-Interoperabilität''': Funktionales Verhalten an Schnittstellen
+
*'''Verhaltens-Interoperabilität''': Funktionales Verhalten an Schnittstellen  
  
−
Die ''' Kommunikative Interoperabilität''' eines IVS-Akteurs wird sichtbar am '''kommunikativen Verhalten''' an den Schnittstellen, die er anderen IVS-Akteuren auf den verschiedenen Ebenen für die Kooperation anbietet. Hier kommen in der Regel nationale und zukünftig immer mehr europäische bzw. internationale IVS-Normen und -Standards für Kommunikation und Daten zum Einsatz (siehe auch [[TOGAF-Phase C | TOGAF Phase C – Informationssystem-Architektur ]])
+
Die '''kommunikative Interoperabilität''' eines IVS-Akteurs wird sichtbar am '''kommunikativen Verhalten''' an den Schnittstellen, die er anderen IVS-Akteuren auf den verschiedenen Ebenen für die Kooperation anbietet. Hier kommen in der Regel nationale und zukünftig immer mehr europäische bzw. internationale IVS-Normen und -Standards für Kommunikation und Daten zum Einsatz (siehe auch [[TOGAF-Phase_C|TOGAF Phase C – Informationssystem-Architektur ]])
  
−
Die ''' Verhaltens-Interoperabilität''' eines IVS-Akteurs wird sichbar am '''funktionalen Verhalten''' an den Schnittstellen die er anderen IVS-Akteuren auf den verschiedenen Ebenen für die Kooperation anbietet. Es liegt in der Natur der Sache, dass für jede spezifische IVS-Domäne bzw. jeden spezifischen IVS-Dienst fachbezogen ganz unterschiedliche Verhaltens-Interoperabilitäten erforderlich sind. Aber auch hier kommen mehr und mehr nationale und auch europäische IVS-Richtlinien und Spezifikationen zum Einsatz.  
+
Die '''Verhaltens-Interoperabilität''' eines IVS-Akteurs wird sichtbar am '''funktionalen Verhalten''' an den Schnittstellen, die er anderen IVS-Akteuren auf den verschiedenen Ebenen für die Kooperation anbietet. Es liegt in der Natur der Sache, dass für jede spezifische IVS-Domäne bzw. jeden spezifischen IVS-Dienst fachbezogen ganz unterschiedliche Verhaltens-Interoperabilitäten erforderlich sind. Aber auch hier kommen mehr und mehr nationale und auch europäische IVS-Richtlinien und Spezifikationen zum Einsatz.
  
 
Beispiele für funktionale Richtlinien und Spezifikationen im Sinne von IVS-Verhaltens-Interoperabilität:
 
Beispiele für funktionale Richtlinien und Spezifikationen im Sinne von IVS-Verhaltens-Interoperabilität:
−
*Technologiearchitekturen und Standards (z.B. ETSI-Standard)
+
 
−
*Europäische Implementierungsrichtlinien, z.B. EasyWay Deployment Guidelines  
+
*Technologiearchitekturen und Standards (z.B. ETSI-Standard)  
−
*Übergreifend nutzbare IT-Services (z.B. der Deutsche National Access Point - MDM)
+
*Europäische Implementierungsrichtlinien&nbsp;(z.B. EasyWay Deployment Guidelines)
−
*Architekturmuster (z.B. Service Orientierte Architektur, SOA)
+
*Übergreifend nutzbare IT-Services (z.B. der Deutsche National Access Point - MDM)  
−
*Web Services und industrielle Standards (z.B. WSDL, WMS, WFS, XML, WS-*).
+
*Architekturmuster (z.B. Service Orientierte Architektur, SOA)  
−
*Geschäftsarchitekturmodelle aus IT-Service-Management-Frameworks (z.B. ITIL)
+
*Web Services und industrielle Standards (z.B. WSDL, WMS, WFS, XML, REST, JSON, WS-*)  
 +
*Geschäftsarchitekturmodelle aus IT-Service-Management-Frameworks (z.B. ITIL)  
 
*Nationale Richtlinien und Standards (z.B. Neuversion der MARZ)
 
*Nationale Richtlinien und Standards (z.B. Neuversion der MARZ)
  
−
== Interoperabilität als Anforderung ==
+
== Interoperabilität als Anforderung - Beispiel ==
 +
 
 +
[[File:CapabilityAlsAnforderung.PNG|thumb|right|180px|Interoperabilität als Anforderung]]
 +
 
 +
Bei der Entwicklung von IVS-Diensten ist grundsätzlich nicht davon auszugehen, dass die beteiligten IVS-Akteure - auch wenn sie vom Grundsatz her schon über die in Rede stehende Capability verfügen - von Hause aus interoperabel sind. Sind die entsprechenden Capability-Dimensionen für Interoperabilität noch nicht vorhanden, so kann man die zukünftig zu entwickelnden Capability-Dimensionen im Sinne von Requirements verstehen. Wie nebenstehende Abbildung symbolisieren soll, können diese Anforderungen Auswirkungen auf allen Ebenen von IVS-Architektur, und zwar an Schnittstellen nach Außen aber auch innerhalb der Organisation haben:
  
 +
Als '''Beispiel''' sei die Kooperation einer Stadt mit einem privaten Navigationsdienstleister im Rahmen einer '''Alternativroutensteuerung''' genannt. Die Kooperationsvereinbarung enthält u.a. folgendes:
  
−
[[Datei: CapabilityAlsAnforderung.PNG | thumb | right | 180px | Interoperabilität als Anforderungen]]
+
*die Stadt verpflichtet sich zur kostenpflichtigen Abnahme von FCD-Daten, die der private Navigationsdienstleister zur Verfügung stellen kann.  
 +
*als Gegenleistung verpflichtet sich der private Navigationsdienstleister, sich bei seinen Routenempfehlungen "strategiekonform" zu verhalten, das heißt die '''Capability "Strategiekonformes Routen"''' zu entwickeln.
  
−
Bei der Entwicklung von IVS-Diensten ist grundsätzlich nicht davon auszugehen, dass die beteiligten IVS-Akteure von Hause aus interoperabel sind. Sind die entsprechenden Fähigkeiten für Interoperabilität noch nicht vorhanden, so kann man die zukünftig zu entwickelnden Fähigkeiten im Sinne von Requirements verstehen. Wie nebenstehende Abbildung symbolisieren soll, können diese Anforderungen Auswirkungen auf allen Ebenene von Architektur, und zwar an Schnittstellen nach Außen aber auch innerhalb der Organisation haben:
+
Mit dieser Vereinbarung sind u.a. folgende Anforderungen an das Verhalten des Navigationsdienstleisters verbunden ('''Capability-Dimensionen'''):
  
−
Als '''Beispiel''' sei die Kooperation einer Stadt mit einem privaten Navigationsdienstleister im Rahmen einer '''Alternativroutensteuerung''' genannt. Die Kooperationsvereinbarung enthält u.a. folgendes:
+
;Strategie-Ebene...
 +
:der Navigationsdienstleister muss seine Service-Strategie für seinen Kunden dahingehend anpassen, dass er seinen Kunden nicht grundsätzlich die individuell günstigste Route zu einem Ziel anbietet, sondern dass er die Routenempfehlungen der Stadt einbezieht, insbesondere Tempo-30-Zonen von der Routenempfehlung ausnimmt.
 +
;Geschäftsprozess-Ebene...
 +
:der Navigationsdienstleister muss seine Geschäftsprozesse auf die Kommunikation mit der Stadt hin ausbauen.
 +
;Informationsstrukturen-Ebene...
 +
:der Navigationsdienstleister muss seine Informationsstrukturen um das Datenmodell der Alternativroutenempfehlungen der Stadt erweitern. Auf der anderen Seite muss er ein Datenmodell für FCD-Daten entwickeln, das die Stadt verarbeiten kann.
 +
;IT-Dienstestrukturen-Ebene...
 +
:der Navigationsdienstleister muss neue IT-Dienste für den Austausch von Alternativrouten (Client-Service) und FCD-Daten (Server-Service) bereitstellen.  
 +
;IT-Infrastrukturen-Ebene...
 +
:der Navigationsdienstleister muss eine permanente Netzverbindung mit der Stadt herstellen.
 +
:  
 +
 
 +
== Literaturverzeichnis ==
 +
 
 +
<references />
  
−
* die Stadt verpflicht sich zur kostenpflichtigen Abnahme von FCD-Daten, die der private Navigationsdienstleister zur Verfügungs stellen kann. 
+
----
−
* als Gegenleistung verpflichtet sich der private Navigationsdienstleister, sich bei seinen Routenempfehlungen "stragiekonform" zu verhalten
 
  
−
Mit dieser Vereinbarung sind u.a. folgende Anforderungen and das Verhalten des Navigationsdiesntleisters verbunden:
+
[[Hauptseite|<< Zurück zur Hauptseite]]
−
;Strategie-Ebene: der Navigationsdienstleister muss seine Service-Strategie für seinen Kunden dahingehend anpassen, dass er seinen Kunden nicht grundsätzlich die individuell güsstige Route zu einem Ziel anbietet, sondern dass er die Routenempfehlungen der Stadt einebzieht, insbesondere Tempo 30 - Zonen von der Routenempfehlung ausnimmt.
 
−
;Geschäftsprozess-Ebene: der Navigationsdienstleister muss seine Geschäftsprozesse auf die Kommunikation mit der Stadt hin ausbauen.
 
−
;Informations-Ebene: der Navigationsdienstleister muss seine Informationstrukturen um das Datenmodell der Alternativroutempfehlungender Stadt erweitern. Auf der anderen Seite muss er ein Datenmodell für FCD-Daten entwickeln, dass die Stadt verarbeiten kann.
 
−
;Informations-Ebene: der Navigationsdienstleister muss neue IT-Dienste für den Austausch von Alternativrouten (Client-Service) und FCD-Daten (Server-Service) bereitstellen.
 
−
;Infrastruktur-Ebene: der Navigationsdienstleister muss eine permanente Netzverbindung mit der Stadt herstellen.
 

Aktuelle Version vom 9. Februar 2018, 15:23 Uhr

Geschäftsfähigkeiten (Capabilities) in TOGAF

Capability-Definition

IVS-Wertschöpfungskette für einen Verkehrsmanagement-Service

Mit Capability wird in TOGAF eine Fähigkeit bezeichnet, die eine Organisation, Person oder ein System besitzt. Capabilities werden mit allgemeinen bzw. übergeordneten Begriffen benannt und sind typischerweise eine Kombination von Menschen, Organisation, Prozessen und Technologie, um realisiert werden zu können.[1]

Von strategischer Bedeutung für jedes Unternehmen sind sog. Business Capabilities (Geschäfts-Fähigkeiten). Sie kennzeichnen Eigenschaften einer Institution/eines Unternehmens, die unbedingt erforderlich sind, damit sie/es ihre/seine strategischen Ziele erreichen kann.

Capabilities ...

  • sind die eigentlichen Bausteine für das Geschäft (Business) einer Institution/eines Unternehmens.
  • repräsentieren stabile geschäftliche Funktionen.
  • sind einzigartig und unabhängig voneinander.
  • abstrahieren von der Organisation einer Institution/eines Unternehmens.
  • repräsentieren letztlich das Geschäftsinteresse einer Institution/eines Unternehmens.

Das Besondere an Capabilities ist zum einen ihre Zeitstabilität, d.h. sie ändern sich sehr selten bzw. nur dann, wenn sich die strategische Ausrichtung einer Institution/eines Unternehmens ändert. Zum zweiten werden sie von der Fachseite erarbeitet und nicht wie oftmals üblich, von der IT-Seite diktiert. Insofern bilden sie eine Abstraktionsschicht zwischen Geschäfts- und IT-Prozessen.

Capability-Dimensionen

Wie nachfolgende Abbildung symbolisieren soll, wirkt sich die Schaffung von Capabilities in der Regel auf alle Ebenen (der IVS-Pyramide) einer Institution/eines Unternehmens aus. Dies wird mit den Dimensionen einer Capability bezeichnet und ist oft mit schwierigen Eingriffen in bestehende Unternehmens-/Institutions-Strukturen und mit entsprechenden, für die Beteiligten, oft schmerzhaften Veränderungsprozessen verbunden. Vor diesem Hintergrund müssen Fähigkeiten in konkreten Dimensionen strukturiert werden. D.h. es gibt übergeordnete Fähigkeiten, die wiederum andere Fähigkeiten erfordern. Fähigkeiten sollten nicht redundant sein.

Capabilities: Ausprägung

Übertragung des Capability-Konzepts auf IVS-Architektur

Einführung

IVS-Wertschöpfungsnetzwerk

Im Sinne von IVS repräsentiert IVS-Capability einen Satz von Fähigkeiten, die ein IVS-Akteur als Bestandteil einer IVS-Prozesskette (IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk) mitbringen muss, damit am Ende der potentielle Nutzen des IVS-Dienstes verwirklicht werden kann.

Dabei werden Anforderungen der End-Nutzer an den Nutzen von IVS-Diensten immer umfangreicher und komplexer. Daraus resultiert, dass die meisten IVS-Dienste nur über Kooperation, d.h. die Vernetzung und das Zusammenwirken verschiedener IVS-Akteure mit ganz spezifischen Fähigkeiten und Nutzenbeiträgen entstehen können (siehe auch IVS-Wertschöpfungs- und Rollenkonzept). Vor diesem Hintergrund gewinnt „die Kooperation von IVS-Akteuren“ für IVS immer mehr an Bedeutung. Alle Lösungen im Bereich von IVS, d.h. technische Produkte oder Dienstangebote etc., müssen im Grundsatz dem Anspruch genügen, dass sie auch als Bestandteil einer Wertschöpfungskette bzw. eines Wertschöpfungsnetzwerks darstellbar sind. Daraus muss hervorgehen, in welcher Beziehung die beteiligten IVS-Akteure in ihren Rollen zusammenarbeiten und welche Fähigkeiten sie in welchen Dimensionen entwickeln müssen, um den von ihnen erwarteten Nutzen bzw. Mehrwert bei der Wertschöpfung generieren zu können.

Vor diesem Hintergrund muss sich jeder einzelne IVS-Akteur, der sich an einer IVS-Wertschöpfungskette/einem IVS-Wertschöpfungsnetzwerk beteiligen will, die Fragen stellen:

  • über welche Capabilities (Fähigkeiten) er verfügen oder welche er noch entwickeln muss, damit eine erfolgreiche Kooperation und Wertschöpfung zustande kommen kann und
  • welche Capability-Dimensionen die Entwicklung der Capabilities auf Menschen, Organisation, Prozesse und Technologien seiner Institution/seines Unternehmens haben werden.

Ein Beispiel für das Segment "IVS-Inhalteanbieter der IVS-Wertschöpfungskette für Zuständigkeitsübergreifendes Verkehrsmanagement" zeigt folgende Tabelle:

IVS-Capability Beteiligungen Abhängigkeit von anderen IVS-Capabilities
Bezeichnung Beschreibung Beteiligte IVS-Rollen Beteiligte IVS-Prozesse Beteiligte IVS-Anwendungsprozesse
Gewinnung von Planungsdaten Durchgehende Planung und Versorgung von Versorgungsartefakten (digitale Straßenkarte, LCL-Liste, Versorgungslisten der Anlagen, etc.), die für zuständigkeitsübergreifendes Verkehrsmanagement erforderlich sind.
  • Planungsverantwortliche der IVS-Akteure
  • Versorgungsverantwortliche der öffentlichen und privaten IVS-Akteure
 Planungs- und Versorgungsprozesse der öffentlichen und privaten IVS-Akteure Planungs- und Versorgungsanwendungen wirken direkt auf eine Versorgungsdatenbank, in der mehrere (versionierte) Versorgungen gleichzeitig zur Verfügung gestellt werden. Dies erlaubt das Einspielen und systemweite Umschalten auf eine neue Versorgung im Onlinebetrieb.
Erfassung und Sammlung von Realzeit-Daten und -Informationen

Auf Basis verschiedener Sensortypen und Erfassungsmethoden werden Daten in Real-Zeit erfasst:

  • Verkehrsstärke und -geschwindigkeit, Belegungsgrad
  • Trajektorien (Reisezeit je Reiseabschnitt
  • Floating-Car-Daten
 Datenerfassungssysteme der öffentlichen und privaten IVS-Akteure Datenerfassungsprozesse der öffentlichen und privaten IVS-Akteure
Erfassung von Ereignissen und Erkennung von Störungen
  • Vorhersehbare Ereignisse (Baustellen, Veranstaltungen, Messen...)
  • Unvorhersehbare Störungen im Netz (Unfälle, Naturereignisse...)
  • Ereignisse: Baustellenmanagementsysteme, Redaktionsplätze, Ereigniskalender...
  • Störungen: Automatische Systeme zur Erkennung von Störungen, Polizei, Staumelder...
  • Ereignis-Erfassungsprozesse
  • Störungs-Erkennungsprozesse
  • Manuelle Ereignis-Erfassung (Redaktionsplatz)
  • Automatische Ereignis-Erfassung (Event-Kalender)
  • Manuelle Störungs-Erfassung (Polizei, Staumelder)
  • Automatische Störungs-Erfassung (Incident-Detection-System)
 Erfassung und Sammlung von Echtzeit-Daten und -Informationen

Interoperabilität als Schlüsseldimension der Kooperationsfähigkeit

Interoperabilität zwischen den Schichten der IVS-Architekturpyramide

Einer der Schlüssel für erfolgreiche Kooperation ist die Interoperabilität der beteiligten IVS-Akteure einer IVS-Wertschöpfungskette/eines IVS-Wertschöpfungsnetzwerks. Im IVS-Kontext bedeutet Interoperabilität die Fähigkeit voneinander unabhängiger IVS-Akteure, mit u.U. ganz heterogenen Strategien, Geschäftsprozessen, Informationsstrukturen und IT-Systemen in IVS-Wertschöpfungsketten im Sinne der Informationslogistik, möglichst nahtlos zusammenzuarbeiten, um Informationen auf effiziente und verwertbare Art und Weise auszutauschen und sie am Ende dem Benutzer zur Verfügung zu stellen.

Hier setzt das Interesse des IVS-Architekten und der IVS-Architektur ein. Der Begriff Interoperabilität darf nicht auf IT-Aspekte reduziert werden. Für den erfolgreichen Aufbau von IVS-Wertschöpfung muss Interoperabilität für alle Beteiligten nachvollziehbar auf allen Ebenen von IVS-Architektur hergestellt werden und durch entsprechende Architektur-Bausteine repräsentiert werden.

Als geeignetes Metamodell und methodisches Hilfsmittel zur überschaubaren und nachvollziehbaren Darstellung und Beschreibung von IVS-Diensten wird dem IVS-Architekten die IVS-Pyramide vorgeschlagen. Im Kontext der Capability-Diskussion eignet sie sich besonders auch als Visualisierungsmodell für Interoperabilität auf allen Ebenen von IVS-Architektur.


Formen von Interoperabilität

Im IVS-Architekturkontext ist Interoperabilität ein Bestandteil von Verhalten auf den Ebenen von IVS-Architektur. Diesen Zusammenhang zeigt - mit den Darstellungsmitteln der IVS-Architekturpyramide - die obere Abbildung.

Interoperabilität wird sichtbar an Schnittstellen. Generell müssen dabei zwei folgende Formen von Interoperabilität unterschieden werden:

  • Kommunikative Interoperabilität: Kommunikatives Verhalten an Schnittstellen
  • Verhaltens-Interoperabilität: Funktionales Verhalten an Schnittstellen

Die kommunikative Interoperabilität eines IVS-Akteurs wird sichtbar am kommunikativen Verhalten an den Schnittstellen, die er anderen IVS-Akteuren auf den verschiedenen Ebenen für die Kooperation anbietet. Hier kommen in der Regel nationale und zukünftig immer mehr europäische bzw. internationale IVS-Normen und -Standards für Kommunikation und Daten zum Einsatz (siehe auch TOGAF Phase C – Informationssystem-Architektur )

Die Verhaltens-Interoperabilität eines IVS-Akteurs wird sichtbar am funktionalen Verhalten an den Schnittstellen, die er anderen IVS-Akteuren auf den verschiedenen Ebenen für die Kooperation anbietet. Es liegt in der Natur der Sache, dass für jede spezifische IVS-Domäne bzw. jeden spezifischen IVS-Dienst fachbezogen ganz unterschiedliche Verhaltens-Interoperabilitäten erforderlich sind. Aber auch hier kommen mehr und mehr nationale und auch europäische IVS-Richtlinien und Spezifikationen zum Einsatz.

Beispiele für funktionale Richtlinien und Spezifikationen im Sinne von IVS-Verhaltens-Interoperabilität:

  • Technologiearchitekturen und Standards (z.B. ETSI-Standard)
  • Europäische Implementierungsrichtlinien (z.B. EasyWay Deployment Guidelines)
  • Übergreifend nutzbare IT-Services (z.B. der Deutsche National Access Point - MDM)
  • Architekturmuster (z.B. Service Orientierte Architektur, SOA)
  • Web Services und industrielle Standards (z.B. WSDL, WMS, WFS, XML, REST, JSON, WS-*)
  • Geschäftsarchitekturmodelle aus IT-Service-Management-Frameworks (z.B. ITIL)
  • Nationale Richtlinien und Standards (z.B. Neuversion der MARZ)

Interoperabilität als Anforderung - Beispiel

Interoperabilität als Anforderung

Bei der Entwicklung von IVS-Diensten ist grundsätzlich nicht davon auszugehen, dass die beteiligten IVS-Akteure - auch wenn sie vom Grundsatz her schon über die in Rede stehende Capability verfügen - von Hause aus interoperabel sind. Sind die entsprechenden Capability-Dimensionen für Interoperabilität noch nicht vorhanden, so kann man die zukünftig zu entwickelnden Capability-Dimensionen im Sinne von Requirements verstehen. Wie nebenstehende Abbildung symbolisieren soll, können diese Anforderungen Auswirkungen auf allen Ebenen von IVS-Architektur, und zwar an Schnittstellen nach Außen aber auch innerhalb der Organisation haben:

Als Beispiel sei die Kooperation einer Stadt mit einem privaten Navigationsdienstleister im Rahmen einer Alternativroutensteuerung genannt. Die Kooperationsvereinbarung enthält u.a. folgendes:

  • die Stadt verpflichtet sich zur kostenpflichtigen Abnahme von FCD-Daten, die der private Navigationsdienstleister zur Verfügung stellen kann.
  • als Gegenleistung verpflichtet sich der private Navigationsdienstleister, sich bei seinen Routenempfehlungen "strategiekonform" zu verhalten, das heißt die Capability "Strategiekonformes Routen" zu entwickeln.

Mit dieser Vereinbarung sind u.a. folgende Anforderungen an das Verhalten des Navigationsdienstleisters verbunden (Capability-Dimensionen):

Strategie-Ebene...
der Navigationsdienstleister muss seine Service-Strategie für seinen Kunden dahingehend anpassen, dass er seinen Kunden nicht grundsätzlich die individuell günstigste Route zu einem Ziel anbietet, sondern dass er die Routenempfehlungen der Stadt einbezieht, insbesondere Tempo-30-Zonen von der Routenempfehlung ausnimmt.
Geschäftsprozess-Ebene...
der Navigationsdienstleister muss seine Geschäftsprozesse auf die Kommunikation mit der Stadt hin ausbauen.
Informationsstrukturen-Ebene...
der Navigationsdienstleister muss seine Informationsstrukturen um das Datenmodell der Alternativroutenempfehlungen der Stadt erweitern. Auf der anderen Seite muss er ein Datenmodell für FCD-Daten entwickeln, das die Stadt verarbeiten kann.
IT-Dienstestrukturen-Ebene...
der Navigationsdienstleister muss neue IT-Dienste für den Austausch von Alternativrouten (Client-Service) und FCD-Daten (Server-Service) bereitstellen.
IT-Infrastrukturen-Ebene...
der Navigationsdienstleister muss eine permanente Netzverbindung mit der Stadt herstellen.

Literaturverzeichnis

  1. ↑ TOGAF® Version 9.1: The Open Group. Online verfügbar unter http://pubs.opengroup.org/architecture/togaf9-doc/arch/, zuletzt geprüft am 02.11.2017.

<< Zurück zur Hauptseite

Abgerufen von „http://wikiivs.albrechtconsult.com/index.php?title=IVS-Capibilities&oldid=13296“