IVS-Capibilities

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen

Geschäftsfähigkeiten (Capabilities) in TOGAF

Capabilities: Einordnung

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. (Quelle: Bitkom, 2011 und TOGAF 9.1)

Nutzen und Vorteile

Capabilities (dt. Fähigkeiten) dienen in TOGAF zu Planungszwecken. Das Besondere an den Fähigkeiten ist zum einen Ihre Zeitstabilität, d.h. sie ändern sich sehr selten; zum zweiten werden sie gemeinsam mit der Fachseite erarbeitet und damit nicht von der IT diktiert; zum Dritten bilden sie eine Abstraktionsschicht zwischen IT und Geschäftsprozessen, auf deren Ebene sich gut planen lässt.

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

Top-Down-Vorgehen

Zunächst wird erfasst, welche Capabilities 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). 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 Architektur.

Capabilities und Requirements (Fähigkeiten und Anforderungen)

Sind Capabilities noch nicht vorhanden, so kann man die zukünftig zu entwickelnden Fähigkeiten im Sinne von Requirements verstehen. Dabei wird nicht betrachtet, wie diese später IT-seitig realisiert werden.

Capabilities auf IT-Seite

Da Capabilities in der Regel auch eine IT-Komponente haben, wird nun der Zusammenhang zur IT erklärt.

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.

Übertragung des Capability-Gedankens auf IVS

Vor dem Hintergrund dass die meisten IVS-Dienste nur über die Vernetzung und das Zusammenwirken verschiedener IVS-Akteure entstehen (siehe auch Wertschöpfungsketten und -netwzwerke) wird deutlich, welches Beziehungsgeflecht dafür erforderlich ist. „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 Wertschöpfungskette bzw. Wertschöpfungsnetzwerk darzustellen sind. Daraus muss hervorgehen, in welcher Beziehung beteiligte Akteure in ihren Rollen zusammenarbeiten und welche Fähigkieten Sie entwicklen müssen, um disem Anspruch genügen zu können.






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.

Interoperabilität

Im IVS-Kontext bedeutet Interoperabilität die Fähigkeit voneinander unabhängiger IVS-Akteure mit u.U. ganz heterogenen 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. Dazu sollen gesonderte Absprachen zwischen den Systemen nicht notwendig sein. 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 - folgende Abbildung,

Datei:IVS-Interoperabilität.png
Interoperabilität zwischen den Schichten der IVS-Architekturpyramide

Die horizontale übergreifende Interoperabilität muss einem Protokoll (Verhalten) folgen. Auszutauschende Information muss dabei semantiktreu gemäß der vereinbarten IVS-Informationsarchitektur benutzt werden.

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.

Beispiele für Bausteine für Interoperabilität sind:

  • 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)
  • Daten- und Kommunikationsstandards (z.B. DATEX II)
  • 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)

Beispiel 1: Route planen

Datei:Capas Bsp.pdf

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

<< Zurück zur Hauptseite













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.

Day 1

Day 2

Conformance Assessmant