Das Konzept der serviceorientierten Architektur in der Bundesverwaltung unter besonderer Betrachtung der Plattformunabhängigkeit von Fachanwendungen

Transkript

1 Ministerialkongress 2006 Das Konzept der serviceorientierten Architektur in der Bundesverwaltung unter besonderer Betrachtung der Plattformunabhängigkeit von Fachanwendungen Hendrik Lühmann, Referent f. Softwarestrategie, OSS und offene Standards bei der KBSt im BMI Berlin, 08. September 2006

2 Was ist die KBSt? Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung Teil des Bundesministeriums des Innern zuständig für die gesamte Bundesverwaltung erarbeitet die IT-Strategie des Bundes Aufgaben, Profil und Arbeitsergebnisse unter

3 Agenda Einführung SOA und Plattformunabhängigkeit Zukünftiger IT-Einsatz und Plattformunabhängigkeit Abhängigkeit von IT-Komponenten Ebenen der Plattformunabhängigkeit Anwendungstypen und Plattformunabhängigkeit Architektur und Schnittstellendesign Strategisches Abhängigkeitsmanagement

5 Was ist Service-orientierte Architektur? Service Oriented Architecture can be defined as a software design & implementation methodology ("Architecture") of loosely coupled, coarse grained, reusable artifacts ( Services"), which can be integrated with each other, through a wide variety of platform independent service interfaces.

6 Service-orientierte Architektur (SOA) Begriffe im Zusammenhang mit Serviceorientierung Kostenvorteile Technologieunabhängigkeit Flexibilität Interoperabilität Geschäftsprozess- Modellierung Wiederverwendung Lose Kopplung...

7 Service-orientierte Architektur (SOA) Begriffe im Zusammenhang mit Serviceorientierung Kostenvorteile Technologieunabhängigkeit Flexibilität Interoperabilität Geschäftsprozess- Modellierung Wiederverwendung Lose Kopplung... Worum geht es eigentlich? Die Freiheit jederzeit unabhängig und flexibel die richtigen Entscheidungen treffen zu können Sich nicht abhängig zu machen und damit die eigene Entscheidungsfreiheit einzuschränken

8 Ziele des Vortrags Ein Bewusstsein für die Problematik Plattformunabhängigkeit schaffen Zeigen wie komplex und vielschichtig der Begriff Plattformunabhängigkeit sein kann An punktuellen Beispielen wichtige Aspekte aus dem Leitfaden Plattformunabhängige Fachanwendungen erläutern Zur Nutzung des Leitfadens animieren Zu einer Diskussion über Plattformunabhängigkeit anregen

9 Agenda Einführung Plattformunabhängigkeit und SOA Zukünftiger IT-Einsatz und Plattformunabhängigkeit Abhängigkeit Ebenen der Plattformunabhängigkeit Anwendungstypen und Technologie Architektur zwei Beispiele Strategisches Abhängigkeitsmanagement

10 JP1 Herausforderungen Betrieb von immer komplexeren IT-Infrastrukturen Neue Anforderungen bezüglich der Effizienz der IT Informationstechnische Vernetzung Entwicklung komplexer, prozessorientierter Dienstleistungsangebote Integration künftiger Angebote in bestehende Infrastrukturen Umgang mit teilweise hochgradigen Abhängigkeiten zwischen Anwendungen und Systemen

11 Folie 10 JP1 Folie Punkt Strategische Ziele und Plattformunabhängigkeit AGENDA Jan-Peter.Baas;

12 Strategische Zielsetzung Wirtschaftlichkeit: Ausreichendes Maß an Aufgabenerfüllung bei geringstmöglichem Mitteleinsatz Investitionssicherheit: Nachhaltigkeit des Mitteleinsatzes Wiederverwendbarkeit: Möglichkeit, Modelle, Verfahren, Systeme u.s.w. in unterschiedlichen Kontexten möglichst unverändert nutzen zu können Portabilität: Grad der Unabhängigkeit eines Computerprogramms, auf unterschiedlichen Ablaufumgebungen fehlerfrei zu laufen. Softwarevielfalt: Dauerhafte Verfügbarkeit alternativer Softwareprodukte am Markt für den gleichen Zweck Dies führt zur Forderung nach einer größtmöglichen Unabhängigkeit bzw. einer kontrollierten Abhängigkeit von Herstellern, Dienstanbietern und Technologien

13 Plattformunabhängigkeit innerhalb der IT-Strategie Strategische Ziele Wirtschaftlichkeit Investitionssicherheit Wiederverwendbarkeit Portabilität, Interoperabilität Unabhängigkeit Hersteller-/ Produkt unabhängigkeit Softwarevielfalt Ebenen von Abhängigkeiten Standard-SW Middleware Betriebssystem Hardware Plattformunabhängigkeit Integrationsarchitekturen Netzinfrastruktur Standards zur Reduktion von Abhängigkeiten XöV, Basiskomp. SOA, WS, BPEL Java,.Net, Unix, Linux, Windows Standard HW-Schnittst. Netzprotokolle, TCP/IP, Erreichte Ziele Wiederverwendbarkeit Interoperabilität Portabilität Investitionssicherheit

15 Abhängigkeit Plattformunabhängigkeit ist ein zentraler Aspekt, um Abhängigkeiten zu reduzieren und damit die eigene Entscheidungsfreiheit zu erhalten Abhängigkeiten können bei der strategischen Weiterentwicklung einer IT-Landschaft erhebliche Probleme bereiten.

16 Abhängigkeit Abhängigkeiten gibt es immer Abhängigkeiten gibt es auf verschiedensten Ebenen Abhängigkeiten können mit positiven Effekten verbunden sein Abhängigkeiten können akzeptabel sein Abhängigkeiten können notwendige Veränderungen behindern Abhängigkeiten können kritisch sein Die Konsequenzen aus Abhängigkeiten müssen klar sein Eine Definition für Plattformunabhängigkeit: Plattformunabhängigkeit ist gegeben, wenn die Entscheidung für oder gegen einzelne Abhängigkeiten im Bewusstsein der Konsequenzen getroffen wurden

17 Wirtschaftliche Plattformunabhängigkeit Plattformunabhängigkeit ja, aber nicht um jeden Preis: Es muss darauf geachtet werden, dass der Aufwand zur Sicherstellung der Plattformunabhängigkeit, nicht den Aufwand wesentlich übersteigt, der für den Austausch der Plattform als Ganzes notwendig ist.

18 Abhängigkeiten in einer IT-Infrastruktur Legende der Abhängigkeiten Standardanwendungen, wie z.b. Office-Produkte, Programme,... Fachanwendungen Know-how & Support Betriebssystem Dokumentenformate Schnittstellen Direkte Abhängigkeit Siloanwendungen Infrastrukturanwendungen, wie z.b. Datenbanken, Webserver, Middleware,... Hardware, wie z.b. Computer-System, Drucker,...

19 Beispiele für Abhängigkeiten Abhängigkeit von Hardware: Eine Software läuft nur unter einem Betriebssystem, das nur für eine bestimmte Hardware angeboten wird Abhängigkeit von Betriebssystemen Eine Fachanwendung ist zwingend an den Einsatz eines Betriebssystems gebunden Abhängigkeit von Infrastruktursoftware Eine Fachanwendung nutzt proprietäre Fähigkeiten eines Datenbank-Servers und ist damit abhängig von dieser Infrastruktursoftware Abhängigkeit von Standardsoftware Eine Fachanwendung nutzt für die Auswertung von Daten die Programmierschnittelle (API) eines Office-Pakets Abhängigkeit von technischem Know-how Eine Fachanwendung benötigt sehr spezielles und tiefes Knowhow. Daraus kann eine Abhängigkeit von Support- beziehungsweise Dienstleistungsverträgen entstehen

20 Abhängigkeit Ein konkretes Beispiel: Es werden neue Computer für Sachbearbeiter angeschafft. Vorhandene Fachanwendungen müssen auf diesen Computern weiterhin ohne Einschränkung laufen. Das gilt auch, wenn eine diese Fachanwendungen von spezieller Hardware abhängig ist, beispielsweise einem integrierten Kartenlesegerät zum Zugriffsschutz. Es besteht eine Plattformabhängigkeit von der Hardware, die die Entscheidungsfreiheit zur Wahl der neuen Computer einschränkt.

21 Plattformunabhängigkeit Die Definition von Wikipedia für Plattformunabhängigkeit: Plattformunabhängigkeit ist die Eigenschaft eines Programms, auf verschiedenen Computersystemen mit Unterschieden in Architektur, Prozessor, Betriebssystem etc. lauffähig zu sein.

23 Ebenen der Plattformunabhängigkeit Eine Definition von Plattformunabhängigkeit: Die Unabhängigkeit der Komponenten von den darunter liegenden Systemen und Umgebungen.

24 Beispiel hierarchisches Plattform-Modell Geschäftsprozess Service Service Service Service-Bus oder Broker Fähigkeit, einen Service durch unterschiedliche Anwendungen zu erbringen Anwendung Service Anwendung Runtime System Fähigkeit, eine Anwendung auf unterschiedl. Basis-Systemen ausführen zu lassen Basis-System Service Basis-System Hardware Abstraction Fähigkeit, vom HW-Refresh profitieren zu können HW Service HW

25 Beispiel: Geschäftsprozess Geschäftsprozesse sind eine zentrale Sicht einer modernen SOA Daher muss auch die Plattformunabhängigkeit aus dieser Sicht betrachtet werden Aus Sicht des Geschäftsprozesses kann die unter einem Service liegende Anwendung ausgetauscht werden, solange der zu erbringende Service soweit standardisiert ist, so dass er von einer anderen Anwendung übernommen werden kann. Die Implementierung eines Geschäftsprozesses wird als plattformunabhängig bezeichnet werden können, wenn alle (Software)Services dieses Geschäftsprozesses standardisiert sind, in mehreren Anwendungssystemen ausgeführt werden können und somit von einem Austausch dieser profitieren

26 Beispiel: Programmier- und Laufzeitumgebung Programmier- und Laufzeitumgebungen entkoppeln Fachanwendung vom darunter liegenden Basis-System Sie schaffen aber auch neue Plattformabhängigkeiten (nämlich von der Programmier- und Laufzeitumgebung) Der Einsatz von Standards mit breiter Unterstützung kann die Auswirkungen dieser Abhängigkeit minimieren Als Programmier- und Laufzeitumgebungen sollen nur Produkte eingesetzt werden, die soweit standardisiert sind, dass mindestens von einem zertifizierten Industrie-Standard gesprochen werden kann. Richtlinien zum Einsatz dieser Produkte und Technologien werden in SAGA veröffentlicht.

27 Definition Plattformunabhängigkeit für Fachanwendungen Plattformunabhängigkeit ist keine ja/nein Entscheidung: 1. Vollständige Plattformunabhängigkeit 2. Weitgehende Plattformunabhängigkeit 3. Eingeschränkte Plattformunabhängigkeit 4. Keine Plattformunabhängigkeit Eine vollständige Plattformunabhängigkeit liegt dann vor, wenn auf allen Ebenen des benutzten Schichtenmodells die Ebenen jeweils plattformunabhängig sind Eine Fachanwendung kann als weitgehend plattformunabhängig bezeichnet werden, wenn sie von dem Basis-System auf eine standardisierte Art und Weise entkoppelt ist, auf mehreren Basis-Systemen ausgeführt werden kann und somit von einem Austausch dieser profitiert. Eine Fachanwendung kann als eingeschränkt plattformunabhängig bezeichnet werden, wenn sie zwar vom zugehörigen Basis- System entkoppelt ist, jedoch das Basis-System aus unterschiedlichen Gründen nicht oder nur teilweise ausgetauscht werden kann. Dies ist z.b. der Fall, wenn die verwendete Programmier- und Laufzeitumgebung nur für ein Basis-System verfügbar ist. Eine Fachanwendung ist plattformabhängig, wenn sie nicht von dem darunter liegenden Basis-System entkoppelt ist und dadurch nicht unabhängig von seiner konkreten Ausprägung ausgeführt werden kann.

28 Zusammenfassung Die Plattformunabhängigkeit von Fachanwendungen lässt sich anhand eines Ebenenmodells in konkreten Ausprägungen formulieren, miteinander vergleichen und bewerten. Die Entkopplung von Ebenen durch die Verwendung standardisierter Schnittstellen eines Laufzeitsystems stellt den Maßstab der Plattformunabhängigkeit dar. Positive Kostenaspekte durch z.b. eine positive Abhängigkeit aufgrund einer tiefen Integration von Komponenten müssen dabei berücksichtigt werden. Eine Auswahl der zu erreichenden Plattformunabhängigkeit ist immer spezifisch für die jeweilige Umgebung und wird durch die Wirtschaftlichkeit bestimmt.

30 Anwendungstypen Es gibt eine Vielzahl von Anwendungstypen Für die Betrachtung der Plattformunabhängigkeit wird diese Vielfalt auf eine übersichtliche Menge reduziert Folgende Anwendungstypen werden unterschieden: Einzelplatzanwendungen Client/Server Fat-Client Client/Server Thin-Client Die folgende Definition der Anwendungstypen wird sehr eng und definiert, um Abgenzungsprobleme zu vermeiden In der Praxis ist der Übergang zwischen den Anwendungstypen häufig unscharf

31 Anwendungstyp Einzelplatz Die Anwendung bildet die gesamte zugrunde liegende Geschäftslogik ebenso wie die Präsentationsebene ab Die Datenhaltung erfolgt lokal Die Anwendung kann daher völlig autark von einem Netzwerk betrieben werden. Einzelplatzanwendungen können jedoch mit anderen Anwendungen oder Diensten kommunizieren. Verwendung in der Praxis: Fachanwendungen, die ihre Daten beispielsweise aus Sicherheitsgründen lokal ablegen oder isoliert lauffähig sein müssen

32 Anwendungstyp Client/Server Fat-Client Die Aufgaben einer Fachanwendung werden zwischen einem Dienstleister dem Server und einem Nutzer dem Client aufgeteilt Der Client übernimmt die Aufgaben der Präsentationsebene und auch Aufgaben der Geschäftslogik Daten werden auf Clientseite (zusätzlich zur Serverseite) fachlich und technisch überprüft Daten werden clientseitig zwischengespeichert z.b. um den Kommunikationsaufwand mit dem Server zu minimieren Der Server wird vor allem zur Datenspeicherung eingesetzt Verwendung in der Praxis: Client/Server-Anwendungen, die sich nicht auf eine kontinuierliche Kommunikationsverbindung zwischen Client und Server verlassen können

33 Anwendungstyp Client/Server Thin-Client Die Aufgaben einer Fachanwendung werden zwischen einem Dienstleister dem Server und einem Nutzer dem Client aufgeteilt Der Thin-Client dient als reine Präsentationsebene für die Ein- und Ausgabe der Daten Die Validierung der Daten erfolgt komplett auf dem Server Es werden weder Roh- noch Konfigurationsdaten auf Seite des Thin-Clients abgespeichert Verwendung in der Praxis: Fachanwendungen, die nur dazu dienen Daten zu erfassen, die auf einem zentralen Datenbankserver abgelegt werden

34 Abgrenzung zwischen den Anwendungstypen Client/Server-Anwendungen eignen sich optimal für Anwendungen, bei denen Daten zentral gespeichert, validiert und z.b. durch viele Benutzer an verschiedenen Lokationen verwendet werden. Thin-Clients können im Normalfall deutlicher leichter als Fat- Clients aktualisiert werden. Werden verschiedene einzelne Anwendungen unter einer gemeinsamen Oberfläche verbunden, eignet sich der Client/Server Ansatz gut. Meist wird die gemeinsame Oberfläche dabei als Thin-Client realisiert. Häufig spricht man in diesem Zusammenhang auch von Portalen.

35 Anwendungstypen und Plattformunabhängigkeit Einzelplatzanwendung Client/Server Fat-Client Client/Server Thin-Client Lokalität der Daten Technologieabhängigkeit Kommunikationsaufwand Interoperabilität Portabilität Legende: stark ausgeprägt schwach ausgeprägt

37 Beispiel: Abhängigkeit zwischen Daten Liegenschaftskarte Liegenschaftsbeschreibung Lage Eigentümer Bezeichnung Geometrie Flächeninhalt Abhängigkeit

38 Beispiel: Fachlich gleichwertige Funktionen Antragsverfahren Fischereischein Prüfung der Adressdaten Antragsverfahren Gaststättenerlaubnis Prüfung der Adressdaten gleichwertig

39 Beispiel: Schnittstellen nach außen Gemeinde Fachanwendung der Gemeinde Schnittstelle Landratsamt Fachanwendung des Landratsamts Schnittstelle Zugriff

40 Integration - Silo Bei Siloanwendungen steht jede Anwendung isoliert nebeneinander Eine Integration zwischen Anwendungen gibt es nicht Wird eine Funktionalität in zwei Anwendungen benötigt, muss sie zweimal implementiert werden Anwendung 1 Anwendung 2 Anwendung 3 Aus Sicht der Plattformunabhängigkeit sind Siloanwendungen (trotz ihrer erheblichen sonstigen Nachteile) optimal, da keine Abhängigkeiten zwischen den Anwendungen bestehen.

41 Integration - Stovepipe In der Praxis werden Integrationen häufig ad-hoc vorgenommen Meist werden zwei Anwendungen direkt verbunden Es entstehen Punkt-zu-Punkt-Integrationen Ein Geflecht vieler Punkt-zu-Punkt-Integrationen wird auch als Stovepipe-Architektur bezeichnet (jeder kommuniziert mit jedem) Anwendung 1 Anwendung 2 Anwendung 3 Anwendung 4 Anwendung 5 Anwendung 6 Anwendung 7 Anwendung 8 Anwendung 9 Anwendung 10 Stovepipe-Architekturen führen zu einer hohen Abhängigkeit und sind damit das Gegenteil von Silos

42 Beispiele für Architekturen Präsentationsschicht Verarbeitung Benutzereingaben Aufbereitung der Systemausgaben Logikschicht Steuerung der Anwendung Validierung und Aufbereitung der Daten Datenhaltungsschicht Verwaltung der Daten n-schichten Architektur Service suchen Service Consumer Broker Serviceinformationen Monolithen Komponentenbasierte Architekturen Service-orientierte Architektur Service registrieren Service Consumer Service aufrufen Service Consumer Provider

43 Architekturziele Folgende Ziele können Plattformunabhängigkeit unterstützen: - Skalierbarkeit - Erweiterbarkeit - Wartbarkeit - Wiederverwendbarkeit - Investitionssicherheit - Technologieunabhängigkeit - Interoperabilität - Portabilität Zwischen den einzelnen Zielen kann es Abhängigkeiten aber auch Konflikte geben

44 Offene Standards und Schnittstellen Offene, allgemein anerkannte Standards und Schnittstellen sind von zentraler Bedeutung für plattformunabhängige Fachanwendungen Daten und die Schnittstelle selbst müssen ausführlich und detailliert dokumentiert sein Schnittstellen von plattformunabhängigen Fachanwendungen sollten offenen Standards genügen.

45 Zusammenfassung Integration ist notwendig, deshalb kein Silo Möglichst keine Punkt-zu-Punkt-Integrationen Die Forderung nach Integration und Interoperabilität steht gegen die Forderung nach Unabhängigkeit. Dieser Konflikt lässt sich nicht auflösen, nur reduzieren. Das Schnittstellendesign muss möglichst zukunftssicher und flexibel gestaltet werden. Der Einsatz von proprietären Protokollen, die nur von exakt den an der Schnittstelle beteiligten Anwendungen verstanden werden, erschwert den Austausch einer der beiden Anwendungen. Stattdessen müssen zukunftssichere Protokolle basierend auf offenen Standards verwendet wurde.

47 Strategisches Abhängigkeitsmanagement Häufig ist man mit bestehenden Abhängigkeiten konfrontiert Die grüne Wiese gibt es in der Regel nicht Es gibt drei Gruppen von Beschränkungen bei der Gestaltung von Fachanwendungen sind: - Beschränkungen, die auf Vorgehensweisen oder früher getroffene Entscheidungen der Organisation zurückgehen, - Beschränkungen, die durch die existierende Anwendungslandschaft entstehen und - Beschränkungen durch den Markt für 'Commercial Off-The- Shelf'-Software (COTS).