IVS-Capibilities
Inhaltsverzeichnis
Geschäftsfähigkeiten (Capabilities) in TOGAF
Capability-Definition
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. (Quelle: Bitkom, 2011 und TOGAF 9.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.
Cabilities...
- 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 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.
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.
Übertragung des Capability-Konzepts auf IVS-Architektur
Einführung
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-Inhaltsanbieter 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. |
|
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:
|
Datenerfassungssysteme der öffentlichen und privaten IVS-Akteure | Datenerfassungsprozesse der öffentlichen und privaten IVS-Akteure | ||||||||
| Erfassung von Ereignissen und Erkennung von Störungen |
|
|
|
|
|||||||
Interoperabilität als Schlüsseldimension der Kooperationsfähigkeit
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
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 verpflicht 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 "stragiekonform" zu verhalten, das heißt die Capabilty "Stragiekonformes Routen" zu entwickeln.
Mit dieser Vereinbarung sind u.a. folgende Anforderungen an das Verhalten des Navigationsdienstleisters verbunden (Capability-Diemsionen):
- 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.
- Informations-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.
- 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.
