IVS-Capibilities: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
 
(103 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äftsfähigkeiten)'''. Sie kennzeichen Eigenschaften eines Unternehmens, die unbedingt erforderlich sind, damit es seine strategischen Ziele erreichen kann.
 
  
−
Cabilities...
+
=== Capability-Definition ===
−
* sind die eigentlichen Bausteine für das Geschäfts eines Unternehmens
 
−
* repräsentieren stabile geschäftliche Funktionen
 
−
* sind einzigartig und unabhängig voneinander
 
−
* abstrahieren von der Organisation eines Unternehmens
 
−
* repräsentieren letzlich das Geschäftsinteresse 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 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. Dabei darf der Begriff Interoperabilität nicht auf IT-Aspekte reduziert werden.  
+
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.
  
−
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 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 innerhalb der Ebenen von 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.
  
−
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 ''' Schnittstellen-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 ==
−
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.  
+
 
 +
[[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:
  
−
Zunächst muss dann erfasst werden, welche Fähigkeiten eine Unternehmenung heute bereits besitzt (Ist). Anschließend wird von der Fachseite und der IT gemeinsam erarbeitet, welche Fähigkeiten zukünftig relevant sein werden (Soll), um den Interoperabilitätsanforderungen, die an die Rolle des IVS-Akteurs in der angestreben Wertschöpfungskette gestellt werden, erfüllen zu können. Die Erarbeitung des Soll wird Top-Down durchgeführt, d.h. ausgehend von den Zielen wird betrachtet, welche Fähigkeiten zur Erreichung der Ziele erforderlich sind. Daraus ergeben sich dann Lücken zwischen Ist und Soll. Zur Schließung der Lücken sind meistens mehrere Durchläufe notwendig, daraus ergeben sich die '''Capability Increments'''. Increments bezeichnen immer Zwischenstände. Zu jedem Capability Increment gibt es auch eine Zwischenversion der IVS-Architektur.  
+
Als '''Beispiel''' sei die Kooperation einer Stadt mit einem privaten Navigationsdienstleister im Rahmen einer '''Alternativroutensteuerung''' genannt. Die Kooperationsvereinbarung enthält u.a. folgendes:
  
−
Capabilities haben in der Regel auch eine IT-Komponente. Die IT-Dimension einer Capability wird meist als IT-Capability bezeichnet. Denkt man im Sinne einer Service-Orientierten Architektur (SOA), dann wird jede IT-Capability über SOA-Services realisiert. D.h. zu jeder Capability muss es schlussendlich einen oder mehrere Services auf IT-Seite geben.
+
*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 ==
  
−
+
<references />
−
=== Beispiel ===
 
−
: Um die Fähigkeit "Route planen" IT-seitig umzusetzen, wird ein Routenplanungsservice benötigt. Dieser kann z.B. die Form einer App auf einem Smartphone haben.
 
  
−
=== Ein IVS Beispiel-Szenario ===
+
----
−
Zur Übertragung des Capability-Gedankens auf die IVS-Domäne stellen wir uns ein Szenario aus dem IVS-Bereich vor: 
 
  
−
*Eine neu gegründete IVS-Servicegesellschaft beabsichtigt, einen Verkehrs- und Routeninformationsdienst speziell für den Straßengüterverkehr anzubieten.
+
[[Hauptseite|<< Zurück zur Hauptseite]]
−
*Disponenten und Lkw-Fahrern sollen ganz individuell in die Lage versetzt werden, Pre-Trip die günstiste Route für eine Tour zur Verteilung von Gütern zu planen und On-Trip aufrgrund von hochaktuellen Verkehrsinformationen anzupassen.
 
−
*Da die IVS-Servicegesellschaft nicht alleine - d.h mit eigenen Mitarbeitern, mit ihrer eigenen Organisation, mit ihren eigenen Prozessen und Technologien - in der Lage ist, einen solchen Informationsdienst für den Güterverkehr zu erbringen, beabsichtigt sie zum Aufbau der dazu erfoderlichen Wertschöpfungskette mit verschiedenen IVS-Akteuren zusammenzuarbeiten und die für die Wertschöpfungskette erforderlichen Leistungen "einzukaufen".
 
−
* Mit den dazu erforderlichen Verträgen mit verschiedenen IVS-Akteuren muss dann festgelegt werden, über welche Fähigkeiten (Capabilities) diese verfügen müssen, damit sie als Bestandteil der aufzubauenden Wertschöpfungskette die notwendigen Leistungen in der erforderlichen Qualiät erbringen können.
 
−
* Dabei ist für alle Ebenen der IVS-Pyramide zu klären, welche Capabilities erforderlich sind.
 

Aktuelle Version vom 9. Februar 2018, 16: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“