IVS-Capibilities: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
Zeile 56: Zeile 56:
 
*Übergreifend nutzbare IT-Services (z.B. der Deutsche National Access Point - MDM)
 
*Übergreifend nutzbare IT-Services (z.B. der Deutsche National Access Point - MDM)
 
*Architekturmuster (z.B. Service Orientierte Architektur, SOA)
 
*Architekturmuster (z.B. Service Orientierte Architektur, SOA)
*Web Services und industrielle Standards (z.B. WSDL, WMS, WFS, XML, WS-*).  
+
*Web Services und industrielle Standards (z.B. WSDL, WMS, WFS, XML, WS-*, RESt, JSON).  
 
*Geschäftsarchitekturmodelle aus IT-Service-Management-Frameworks (z.B. ITIL)
 
*Geschäftsarchitekturmodelle aus IT-Service-Management-Frameworks (z.B. ITIL)
 
*Nationale Richtlinien und Standards (z.B. Neuversion der MARZ)
 
*Nationale Richtlinien und Standards (z.B. Neuversion der MARZ)

Version vom 24. August 2016, 13:29 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ä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 letzlich 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.

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.

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 Ebenene 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ügungs 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üsstige Route zu einem Ziel anbietet, sondern dass er die Routenempfehlungen der Stadt einebzieht, 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 Alternativroutempfehlungender Stadt erweitern. Auf der anderen Seite muss er ein Datenmodell für FCD-Daten entwickeln, dass 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.