IVS-Capibilities

Geschäftsfähigkeiten (Capabilities) in TOGAF

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 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...

• 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.

Wie nebenstehende Abbildung symbolisieren soll, wirkt sich sie Schaffung von Capabilities sich 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 of schmerzhaften Veränderungsprozessen verbunden.

Ausprägung

Fähigkeiten lassen sich strukturieren. 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

IVS-Wertschöpfungsnetzwerk

Die Anforderungen der End-Nutzer an IVS-Dienste werden immer umfangreicher und komplexer. Darus tresultiert, 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 Bedeutung alle Lösungen im Bereich 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. Wertschöpfungsnetzwerk darstellbar sind. Daraus muss hervorgehen, in welcher Beziehung die beteiligten IVS-Akteure in ihren Rollen zusammenarbeiten und welche Fähigkeiten sie in welchen Dimensionen entwicklen 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/eines IVS-Wertschöpfungsnetzwerks beteiligen will, die Frage 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
• welche Dimensionen die Entwicklung der Capabilities auf Menschen, Organisation, Prozesse und Technologien seiner Institution/seines Unternehmens haben werden.

Interoperabilität als Schlüsselbegriff

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.

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-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 Bestandteil von Verhalten auf den Ebenen von IVS-Architektur. Diesen Zusammenhang zeigt - mit den Darstellungsmitteln der IVS-Architekturpyramide dargestellt - nebenstehende Abbildung.

Interoperabilität wird sichtbar an Schnittstellen. Generell müssen dabei zwei unterschiedliche 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 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.

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, WS-*, REST, JSON).
• Geschäftsarchitekturmodelle aus IT-Service-Management-Frameworks (z.B. ITIL)
• Nationale Richtlinien und Standards (z.B. Neuversion der MARZ)

Interoperabilität als Anforderung

Interoperabilität als Anforderungen

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 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

Mit dieser Vereinbarung sind u.a. folgende Anforderungen and das Verhalten des Navigationsdiesntleisters verbunden:

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 Informationstrukturen 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.