IVS-Capibilities: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
Zeile 63: Zeile 63:
  
  
[[Datei: CapabilityAlsAnforderung.PNG | Thumb | Right | 300px | Interoperabilität als Anforderungen auf allen Ebenen von IVS-Architektur ]]
+
[[Datei: CapabilityAlsAnforderung.PNG | thumb | right | 300px | 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.  
 
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.  

Version vom 24. August 2016, 10:21 Uhr

Geschäftsfähigkeiten (Capabilities) in TOGAF

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

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

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.

Capabilities: Ausprägung

Übertragung des Capability-Konzepts auf IVS-Architektur

Einführung

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

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

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. Dabei darf der Begriff Interoperabilität 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 Visualisierungsmodell für Interoperabilität auf allen Ebenen von IVS-Architektur.

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.

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 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 – 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-*).
  • 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.

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.

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.



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