IVS-Capibilities: Unterschied zwischen den Versionen
Zeile 20: | Zeile 20: | ||
Um diese Ziele zu erreichen, sind bestimmte Fähigkeiten erforderlich. | Um diese Ziele zu erreichen, sind bestimmte Fähigkeiten erforderlich. | ||
− | == Beispiel 1: Route planen == | + | === Beispiel 1: Route planen === |
[[Datei:Capas_Bsp.pdf]] | [[Datei:Capas_Bsp.pdf]] | ||
Zeile 40: | Zeile 40: | ||
Jede Fähigkeit benötigt Menschen, IT und Prozesse. | 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. | 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. | ||
+ | |||
+ | ===Capability-Template=== | ||
+ | Zur Erfassung von Capabilites wird folgendes Template vorgeschlagen: | ||
+ | |||
+ | Bezeichnung der Capability | ||
+ | Profitierende Akteure | ||
+ | Beteiligte Rollen | ||
+ | Beteiligte Prozesse | ||
+ | Beteiligte Anwendungssysteme | ||
+ | Zugehörigkeit zu übergeordneten Capabilities | ||
+ | Version | ||
+ | Erstellende Person | ||
+ | Status | ||
+ | Zu realisieren bis Datum | ||
+ | Notwendige Zwischenschritte für die Entwicklung der Capability | ||
+ | |||
+ | |||
+ | ==Capabilities auf IT-Seite == | ||
+ | Da Capabilities in der Regel auch eine IT-Komponente haben, wird hier der Zusammenhang zur IT dargestellt. | ||
+ | Man spricht hier entweder von IT-Capabilities oder lösungsorientiert von Services im Sinne einer SOA. 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. | ||
== Serviceangebot (Profil) == | == Serviceangebot (Profil) == | ||
=== Front-Services === | === Front-Services === | ||
+ | |||
=== Back-End Services === | === Back-End Services === | ||
+ | |||
=== Security === | === Security === | ||
+ | |||
=== Konformität zum Legal Framework === | === Konformität zum Legal Framework === | ||
+ | |||
=== Deployment und Roll-Out Roadmap === | === Deployment und Roll-Out Roadmap === | ||
+ | |||
==== Day 1 ==== | ==== Day 1 ==== | ||
==== Day 2 ==== | ==== Day 2 ==== | ||
=== Conformance Assessmant === | === Conformance Assessmant === | ||
+ | |||
+ | |||
=== Interoperabilität === | === 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-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. |
Version vom 20. März 2016, 16:30 Uhr
Inhaltsverzeichnis
Allgemeines zu Capabilities
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.
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)
Fähigkeiten lassen sich strukturieren. D.h. es gibt übergeordnete Fähigkeiten, die wiederum andere Fähigkeiten erfordern. Fähigkeiten sollten nicht redundant sein.
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.
Übertragung des Capability-Gedankens auf IVS
Zur Übertragung des Capability-Gedankens auf die IVS-Domäne stellen wir uns vor, Deutschland sei eine Unternehmung im Sinne von TOGAF.(siehe Organisation) Die Ziele, die Deutschland mit IVS verfolgt, sind beispielsweise die Ermöglichung einer effizienten Reise und effizienter Gütertransporte.(siehe IVS-Leitbild) Um diese Ziele zu erreichen, sind bestimmte Fähigkeiten erforderlich.
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.
Capability-Template
Zur Erfassung von Capabilites wird folgendes Template vorgeschlagen:
Bezeichnung der Capability Profitierende Akteure Beteiligte Rollen Beteiligte Prozesse Beteiligte Anwendungssysteme Zugehörigkeit zu übergeordneten Capabilities Version Erstellende Person Status Zu realisieren bis Datum Notwendige Zwischenschritte für die Entwicklung der Capability
Capabilities auf IT-Seite
Da Capabilities in der Regel auch eine IT-Komponente haben, wird hier der Zusammenhang zur IT dargestellt. Man spricht hier entweder von IT-Capabilities oder lösungsorientiert von Services im Sinne einer SOA. 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.
Serviceangebot (Profil)
Front-Services
Back-End Services
Security
Konformität zum Legal Framework
Deployment und Roll-Out Roadmap
Day 1
Day 2
Conformance Assessmant
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,
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)