Früh handeln
- Written by 139
- font size decrease font size increase font size
Das SOA-Projekt-Team. Auf der organisatorischen Seite sollte ein SOA-Bibliothekar das Projekt unterstützen. Dieser Mitarbeiter kennt, verwaltet und kommuniziert alle Details zu den vorhandenen Systemen und Services. Gleichzeitig erhöht er durch sein Engagement die Sichtbarkeit der SOA-Projekte im eigenen Haus. Des weiteren hilft er bei der Definition eines Regelwerks: Die Regeln beschreiben beispielsweise, wie das Projektteam neue Services entwickelt. ähnlich wie in einem Content-Management-System wird festgehalten, wer welche Aufgaben hat, wer Dienste testet und freigibt, und wer Systembetreiber über Neuigkeiten und änderungen an genutzten Diensten informiert.
SOA-Lifecycle und technische Mitarbeiter. Services und zugehörige Artefakte folgen einem spezifischen SOA-Service-Lebenszyklus. Zu Beginn steht die Analyse und Optimierung von Geschäftsprozessen. Anschließend erfolgt das Service-Design, bei dem die Definition und die Implementierung der Schnittstelle stattfindet. Am Design einer Service-Schnittstelle beteiligen sich typischerweise folgende Mitarbeiter: ein Verantwortlicher aus der Fachabteilung, dem der Service fachlich zugeordnet ist. Außerdem ein Software-Architekt, der das fachliche Design verantwortet und damit die Integrierbarkeit in die Service-Landschaft sicherstellt. Weiterhin sind die technisch orientierten Rollen Service-Designer und Service-Entwickler zu besetzen, die den Entwurf und die Implementierung der Dienste übernehmen. Abläufe wie der hier beschriebene Design-Prozess stellen die kontinuierliche Evolution der gesamten SOA sicher.
Registries und Repositories. In der Praxis stellen Facharchitekten, Service-Designer und Entwickler immer wieder während der Entwurfs- und Implementierungsphase dieselben Fragen, wie etwa die nach existierenden Diensten und deren Schnittstellen, zugehörigen Geschäftsprozessen oder verantwortlichen Organisationseinheiten. Besonders wichtig für diese Rollen sind die Beziehungen zwischen Services und beteiligten Artefakten wie Service-Schnittstellen, Anforderungs-, Architektur- und Testdokumentation sowie den Service-Policies und SLAs.
Um alle Details einer SOA an zentraler Stelle abzubilden, stellen SOA Registries und Repositories die benötigten Management-Werkzeuge bereit. Deren Funktionsumfang geht über ein klassisches UDDI-Verzeichnis weit hinaus: Während einfache Service Registries nicht viel mehr als Schnittstellenbeschreibungen von Diensten speichern, erlauben Repositories die Verwaltung einer Vielzahl weiterer Service-Informationen. Ein Repository erfasst sämtliche SOA-Komponenten, speichert Prozesse, Regeln, Service-Level-Agreements, Verfügbarkeiten, Zugriffsrechte und weitere Details der Infrastruktur.
Abrechenbarkeit von Services. Entwurf und Implementierung stellen jedoch nur einen Teil einer SOA dar. Ist ein Service in den produktiven Betrieb übergegangen, benötigen Betreiber, Facharchitekten und Manager Informationen zur effektiven Nutzung einzelner Services. Voraussetzung hierfür ist, dass ein Monitoring von Service-Aufrufen zur Laufzeit erfolgt. Dann lassen sich auch Nutzungs- und Zugriffsmuster auf Dienste sowie die Einhaltung von SLAs feststellen. Ein Gradmesser für die erreichte Wiederverwendung eines Services ist die Häufigkeit der Nutzung. Damit verbunden ist eine mögliche Verrechnung (Provisioning) von Services. Nicht oder nur wenig genutzte Dienste sind damit ebenfalls rasch identifizierbar und können von den Verantwortlichen aus dem Produktivbetrieb entfernt werden. Die meistgenutzten Dienste lassen sich dann als Best-Practice-Lösung unternehmensweit einsetzen.
Zudem erlauben SOA Registries und Repositories die effiziente Integration bestehender Metadaten, Policies und Dokumente aus heterogenen IT-Landschaften in eine SOA. Sie unterstützen also insbesondere die SOA-typische Kombination der \"Top-Down\