IVS-Capibilities: Unterschied zwischen den Versionen
| Zeile 37: | Zeile 37: | ||
=== Die IVS-Pyramide als Visualisierungshilfe von Interoperabiölität === | === Die IVS-Pyramide als Visualisierungshilfe von Interoperabiölität === | ||
| − | + | Als geeignetes Metamodell und methodisches Hilfsmittel zur überschaubaren und nachvollziehbaren Darstellung und Beschreibung von IVS-Diensten wird dem IVS-Architekten gemäß XXX dei '''IVS-Pyramide''' vorgeschlagen. | |
| + | |||
| + | Im Folgenden Sie eignet sich auch | ||
| + | Als geeignetes Visualisierungsmodell für Interoperabilität im Sinne von IVS auf den Ebenen von IVS-Architektur eignet sich die IVS-Pyramide. Sie besteht insgesamt aus fünf Ebenen. Die Ebenen 2 bis 4 repräsentieren jeweils eine der TOGAF-Architekturdomänen. | ||
Version vom 24. August 2016, 06:36 Uhr
Inhaltsverzeichnis
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.
Übertragung des Capability-Konzepts auf IVS-Architektur
Einführung
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
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.
Die IVS-Pyramide als Visualisierungshilfe von Interoperabiölität
Als geeignetes Metamodell und methodisches Hilfsmittel zur überschaubaren und nachvollziehbaren Darstellung und Beschreibung von IVS-Diensten wird dem IVS-Architekten gemäß XXX dei IVS-Pyramide vorgeschlagen.
Im Folgenden Sie eignet sich auch Als geeignetes Visualisierungsmodell für Interoperabilität im Sinne von IVS auf den Ebenen von IVS-Architektur eignet sich die IVS-Pyramide. Sie besteht insgesamt aus fünf Ebenen. Die Ebenen 2 bis 4 repräsentieren jeweils eine der TOGAF-Architekturdomänen.
- Horizontale Interoperabilität
- Im IVS-Architekturkontext ist Interoperabilität Bestandteil von Verhalten innerhalb von Ebenen. Innerhalb einer Domäne (Zuständigkeitsbereich, Organisation) ist diese Interoperabilität nur insofern wichtig, dass es sich durch von außen beobachtbares Verhalten erschließt. Diesen Zusammenhang zeigt - mit den Darstellungsmitteln der IVS-Architekturpyramide dargestellt - nebenstehende Abbildung.
Beispiele für Bausteine für horizontale Interoperabilität sind:
- Daten- und Kommunikationsstandards (z.B. DATEX II)
- 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)
- Die horizontale übergreifende Interoperabilität muss einem Protokoll (Verhalten) folgen. Auszutauschende Information muss dabei semantiktreu gemäß der vereinbarten IVS-Informationsarchitektur benutzt werden.
- Vertikale Interoperabilität
Natürlich gibt es auch eine Interoperabilität in der Vertikalen. Diese dient zur Realisierung einer Funktionalität oder von Verhalten der jeweils darüber liegenden Ebene. Es liegt in der Natur der Sache, dass für jede spezifische IVS-Domäne bzw. jeden spezifischen IVS-Dienst fachbezogen ganz unterschiedliche vertikale Capabilitäts erforderlich sind. Vetikale kann man sie grundsätzlich in drei Gruppen klassifizieren:
- Prozess-Fähigkeiten
- Funktionale Fähigkeiten
- IT-Fähigkeiten
Beispiele für Bausteine für vertikale Interoperabilität sind:
- 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)
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.
Beispiel 1: Route planen
Wenn man eine möglichst effiziente Route planen möchte, braucht man die Fähigkeit, eine Route zu planen. Damit die Route möglichst effizient wird, sind z.B. aktuelle Verkehrsinformationen erforderlich.
1. Benötigte Top-Level-Fähigkeit "Route planen"
Dazu sind folgende Unter-Fähigkeiten erforderlich:
1.1 Position bestimmen
1.2 Ziel eingeben
1.3 Reisedauer berechnen
1.4 Verkehrsinformationen berücksichtigen
Die Fähigkeit 1.4 Verkehrsinformationen berücksichtigen benötigt wiederum weitere Unterfähigkeiten:
1.4.1 Verkehrsstörungen erfassen/erkennen
1.4.2 Informationen weitergeben
Jede Fähigkeit benötigt Menschen, IT und Prozesse. Z.B. ist GPS erforderlich, um die Position zu bestimmen. Ein Mensch muss das Ziel eingeben sowie eventuelle Verkehrsinformationen bereitstellen. Ein Prozess der Reiseplanung ist genau so notwendig wie ein Prozess zur Weitergabe und Verbreitung von Verkehrsinformationen.
IVS-Capabilities (siehe auch Capability-Template)
- Definition
- Mit Capability wird eine (Geschäfts-)Fähigkeit bezeichnet, die eine Organisation, Person oder System besitzt. Capabilities werden typischerweise mit allgemeinen bzw. übergeordneten Begriffen benannt und erfordern typischerweise eine Kombination von Menschen, Organisation, Prozessen und Technologie, um realisiert werden zu können
Capability-Template
Zur Erfassung von Capabilites wird folgendes Template vorgeschlagen:
Bezeichnung der Capability
- Ausführliche Beschreibung der Capability
- Profitierende Akteure
- Beteiligte Rollen
- Beteiligte Prozesse
- Beteiligte Anwendungssysteme
- Zugehörigkeit zu übergeordneten Capabilities
- Abhängigkeiten zu anderen Capabilities
- Version
- Erstellende Person
- Status
- Zu realisieren bis Datum
- Notwendige Zwischenschritte für die Entwicklung der Capability
Services (Profil)
Front-End-Services
Mit Front-End-Services sind solche Services gemeint, mit denen Akteure direkt interagieren. Z.B. Ein Service, um ein Reiseziel zu erfassen.
Back-End Services
Mit Back-End Services sind solche Services gemeint, die sich nur mit anderen Services austauschen, d.h. z.B. Verkehrsinformationen für die Routenplanung bereitstellen. Es wird grundsätzlich mehr Back-End als Front End Services geben.
Security
Konformität zum Legal Framework
Deployment und Roll-Out Roadmap
Für jeden Service soll eine zeitliche Planung beschrieben werden, wann welcher Entwicklungsschritt vollzogen sein soll.
