Wie wirken sich SOA-Konzepte auf das Thema BI aus?
Diese Leserfrage an den Expertenrat ist auch Gegenstand verschiedener Konferenzen und White Papers. Vorweg gesagt, ist es meiner Ansicht nach noch nicht mit Sicherheit absehbar, welche Auswirkungen SOA auf BI wirklich haben wird. Der Grund dafür ist, dass die operativen System und die BI-Infrastrukturen in den meisten Unternehmen stark getrennt sind. Falls ein Unternehmen SOA als Grundlage für seine betrieblichen Informationssysteme verwendet, so hat dass vor allem Einfluss auf die Art und Weise, wie operative Systeme geplant, realisiert und betrieben werden.
Aufgrund des speziellen Charakters von BI-Anwendungen und -Architekturen, muss SOA zunächst in diesem Bereich konkrete und nützliche Ansätze liefern. Da ist es nicht genügend, wenn ETL-Hersteller wie beispielsweise Informatica ihre ausgeklügelte Ablaufsteuerung als SOA-Workflow bezeichnen (Informatica Presentation: Service Oriented Data Integration) oder IBM das Produkt DataStage (vormals Ascential) einfach in WebSphere DataStage umbenennt und als zentrale Komponente der IBM WebSphere Data Integration Suite bezeichnet. (ETL = Extraktion, Transformation und Laden von Daten).
Continue reading ‘SOA und die Folgen für BI’
Das Service Registry ist für die meisten SOA Suiten die Stelle, in der alle verfügbaren Services hinterlegt sein müssen um deren Nutzung zu ermöglichen. UDDI ist der Standard, auf dessen Basis die meisten Hersteller ihr Registry implementiert haben. In diesen Registries sind zu jedem Service alle technisch notwendigen Informationen enthalten. Was fehlt sind die fachlichen Informationen, die häufig nur unstrukturiert in Handbüchern, Word-Dateien oder in den Köpfen der Entwickler stecken. Bei jeder sich entwickelnden SOA ist dies kritisch. Wie sollen bereits verfügbare Services identifiziert, wie Wiederverwendung erreicht werden, wenn die Suche nach bereits verfügbaren Services nur zufällig funktioniert ?
Zur Verwaltung der fachlichen Servicespezifikationen bieten einige Hersteller sogenannte Repositories an, die aber wiederum nicht direkt mit den Registries verbunden sind. Setzt man auf diesen Weg entstehen “Drehstuhlschnittstellen”: Ein Mensch muß Repository und Registry synchron halten. Viel Information geht auf diese Weise verloren, Zuammenhänge bleiben unklar. Idealerweise wären Repository und Registry integriert. Damit könnte man sicherstellen, dass ein konsistenter Lifecyleprozess von Services unterstützt wird und auch das Identifizieren von Services keine Detektivarbeit ist. So wäre auch die Steuerung des Serviceportfolios um einiges leichter, was heute erfahrungsgemäß eher zeitraubend und aufwändig ist.
Ein solches “Registory” könnte mit Import-Schnittstellen zu UML und WSDL/XSD ausgestattet sein, um Tools des Model Driven Software Design (MDSD) direkt anzubinden. Das Serviceverzeichnis könnte nach vielerlei Gesichtspunkten durchsucht werden, technisch, fachlich, architektonisch. Man könnte sogar soweit gehen die Darstellung der Referenzarchitektur des Unternehmens direkt mit dem “Registory” zu verbinden, sodass selbst sehr abstrakte Modellierungen möglich wären. So wären auch endlich die Zuzsammenhänge über alle Architekturebenen hinweg auswertbar, womit ich mir noch eine ganze Menge anderer sinnvolle Dinge vorstellen kann:
- einfache Konfiguration von Business Activity Monitoring
- Echtzeit-Erfassung von Geschäftskennzahlen
- echtes automatisches Service Contract Management
- Abbildung von Prozessabhängigkeiten
- … und noch vieles mehr.
In unserem Unternehmen arbeiten wir gerade an der Realisierung eines “Registory”. In Eigenregie, weil bislang noch kein Hersteller etwas derartiges anzubieten hat. Noch nicht einmal als Whitepaper. Anstelle dessen wird unter der SOA-Fahne kräfitg an der Integration der Produkte der jüngsten Aquisen gebosselt und der Kunde sich selbst und nebulösen Ankündigungen überlassen. Ob wohl die Nachfrage vieler Kunden nach konsistenen Werkzeugen die Hersteller zum (Weiter-)denken bewegen kann? Warten wir’s ab und hoffen weiter …
In einem Fachartikel für die COMPUTERWOCHE hält Markus Goerg vom IT-Dienstleister Danet ein Plädoyer für Open-Source-SOA. Unternehmen hätten demnach drei Möglichkeiten, die für eine SOA benötigte Basisinfrastruktur zu etablieren: Selber bauen, die Entwicklungs- und Integrations-Suite von einem Hersteller kaufen oder aber ein Framework aus Open-Source-Bausteinen zusammenstellen.
Erstere Möglichkeit komme nur für die wenigsten Unternehmen in Frage, argumentiert Goerg. Aufbau und Pflege der Bausteine seien zu aufwändig; ein eigenes Framework rechne sich in der Regel nicht. Gegen eine kommerzielle Komplettlösung “von der Stange” sprächen gleich mehrere Gründe: Neben dem Kostenaspekt kritisiert er die Abhängigkeit vom Anbieter. Hinzu komme, dass die EAI oder neuerdings SOA/ESB genannten Pakete der Softwarehersteller oft hoffnungslos überfrachtet seien.
Bleibt Alternative drei: Open-Source-Software biete ausreichend Produkte, um einen SOA-Baukasten zusammenzustellen, erläutert Goerg und fügt noch ein weiteres Argument hinzu, dass den etablierten Softwareanbietern überhaupt nicht schmecken dürfte: Aus deren Sicht benötige eine SOA bestimmte Elemente, darunter der Enterprise Service Bus (ESB), Web-Services, eine UDDI-konforme Registry und eine Workflow-Engine. Keiner dieser Bausteine sei für eine SOA zwingend erforderlich, postuliert der Autor. Typische Probleme in einer SOA, beispielsweise im Bereich Web-Services-Kommunikation ließen sich mit quelloffenen- Systemen wie dem Web Service Invocation Framework (WSIF) der Apache Software Foundation mindestens ebenso gut lösen.
Ist eine quelloffene SOA-Infrastruktur also die bessere Alternative? Offen bleibt zumindest die Frage, woher die Unternehmen das nötige Fachwissen nehmen, um aus dem riesigen Open-Source-Angebot die passenden SOA-Bausteine auszuwählen und zusammenzusetzen. Systemintegratoren dürften sich über entsprechende Anfragen freuen.
Die Globalisierung der Märkte und immer ähnlichere Produkte zwingen Unternehmen zum Handeln. Erfolg hängt zunehmend vom richtigen Geschäftsmodell ab, Agilität und Innovationskraft zählen zu den Kernfähigkeiten eines Unternehmens. Vor diesem Hintergrund benötigt ein erfolgreiches Management eine leistungsfähige, flexible IT, die alle Geschäftssysteme miteinander verknüpft, auf der Basis von Serviceorientierung den rollenbasierten Zugriff auf sämtliche wichtigen Informationen bietet und die Produktivität von Führungskräften sowie Mitarbeitern durch flexible Geschäftsabläufe verbessert.
Viele Unternehmen haben mittlerweile erkannt, dass die Weiterentwicklung ihrer Waren, Produkte und Dienstleistung allein nicht mehr ausreicht, um im Wettbewerb zu bestehen. Was zählt, sind Geschwindigkeit und Wandlungsfähigkeit, denn nur wer sich schnell an veränderte Marktsituationen und Kundenansprüche anpassen kann, wird im Wettbewerb den entscheidenden Schritt voraus sein. Firmen wenden sich aus diesem Grund verstärkt der Innovation ihrer Prozesse und serviceorientierten Geschäftsmodellen zu.
Das richtige Geschäftsmodell finden Sie aber nur, wenn Sie Ihr Business genau kennen, neue Business-Chancen rechtzeitig erkennen und diese kreativ und innovativ umsetzen, um so dem Wettbewerb einen Tick voraus zu sein. Dazu ist es notwendig, zunächst die geschäftlichen Fähigkeiten eines Unternehmens (Business Capabilities) zu analysieren, um anhand der Ergebnisse Business und IT in Einklang zu bringen. Das bedingt eine Sicht auf das ganze Unternehmen, dessen „Key Performance Indicators“ (KPIs) und die Geschäftpartner. Auf Basis einer Business Capabililty Map lassen sich dann Handlungsoptionen in den Prozessen und in der Unternehmensarchitektur aufzeigen.
Daraus ergibt sich am Ende eine stabilere Sicht auf das Unternehmen als Ausgangspunkt für den Entwurf einer realitätsnäheren Unternehmensarchitektur. Sobald ein derartiges Konzept steht, kann die IT dazu übergehen, stabile Services mit Unterstützung der geeigneten Technologie umzusetzen.
Agilität, Transparenz, Wiederverwendbarkeit von Komponenten – das Interesse der IT Manager an Service-orientierten Architekturen (SOAs) wächst weiter. Ihre Hoffnung ist, durch SOA die gesamte IT weniger komplex und trotzdem flexibler gestalten zu können. Die Technologie nimmt jetzt Fahrt auf.
Noch befinden SOAs sich in vielen Organisationen in der Pilotphase. Im Augenblick werden Initiativen definiert und bereits stufenweise Implementierungen realisiert. Aber immer mehr Unternehmen beginnen ihre Applikationen über eine SOA abzubilden und zu verwalten. Für die Kunden ist es verlockend, einzelne Bausteine verschiedener Hersteller effizient und flexibel zu kombinieren und so beispielsweise Anwendungsmodule von SAP und Oracle in einem übergreifenden Geschäftsprozess zusammen zu nutzen. Sie können damit neue Applikationen aus lose gekoppelten Komponenten entwickeln und die IT bedarfsgerecht an die individuellen Geschäftsmodelle anpassen.
Der Wermutstropfen: Trotz steigender Nachfrage sind die wenigsten Softwarepakete derzeit SOA-kompatibel. Continue reading ‘SOA bringt traditionelle Softwarehersteller unter Druck’
Beiträge (Atom)
Letzte Kommentare
RSSMax J. Pucher - Chief Architect ISIS Papyrus
Max J. Pucher - Chief Architect ISIS Papyrus, Uwe Feddern, Falke [...]
Benjamin Hötzel
B. A. Schön, Jakob Freund