Ein Großteil der Kernanwendungen in Unternehmen und öffentlichen Verwaltungen basiert noch immer auf Programmiersprachen wie Cobol, PL/1 oder Assembler. Die Wartung dieser oft mehr als 20 Jahre alten Legacy-Systeme ist aufwändig und teuer, schlimmer noch: Anpassungen geraten zu komplexen Projekten und halten mit den immer häufiger wechselnden Anforderungen der Fachabteilungen nicht mehr Schritt. Das Konzept Service-orientierter Architekturen (SOA) verspricht einen Ausweg aus dem Dilemma.
Zur Beantwortung der Frage, ob SOAs den Königsweg aus der Legacy-Falle darstellen, muß man sich zunächst einmal darüber im Klaren sein, was Legacy eigentlich ist. Tatsächlich wird ja jede neue Software im Augenblick ihrer Indienststellung zu Legacy. Dieser Terminus ist also zu Unrecht mit einem negativen Beigeschmack behaftet – handelt es sich doch tatsächlich zumeist um bewährte Softwaresysteme, die ihre Aufgaben in der Regel gut erfüllen.
Was sich geändert hat sind die Anforderungen, die an die bestehenden Systeme gerichtet sind. Erweiterte Funktionalität, Unterstützung neuer Oberflächen – vor allem aber eine stärkere Vernetzung der Anwendungen mit Drittsystemen, womöglich jenseits der Unternehmensgrenzen, sind neue Requirements. Die Frage ist nun: Wie kann hier Serviceorientierung helfen?
Bei der Bewältigung der technischen Integrationsaufgabe können SOA-Produkte wie etwa ein Enterprise Service Bus (ESB) sicherlich Hilfe leisten. Die Unterschiede zu herkömmlichen EAI-Produkten sind jedoch nicht groß. Einen deutlicheren Fortschritt bringt hier die mit der SOA-Einführung einhergehende Standardisierung und bessere Dokumentation der Schnittstellen und Services.
Die eigentlichen Neuerungen von SOAs liegen jedoch auf der Anwendungsebene: Serviceorientierung in der IT bedeutet Prozeßorientierung auf der Fachseite. Hier müssen SOAs ihre Investitionskosten wieder einspielen. Dies ist nur mit auf Flexibilität zugeschnittenen Services möglich – andernfalls schnappt die Legacy-Falle auch mit SOAs wieder zu.
SOA – Königsweg aus der Legacy-Falle ? – Diese Fragestellung ist eindeutig zu trivial. Hat etwa Herr Klinsmann einen Königsweg aus dem „Rumpelfußball“ gefunden? Die Antwort lautet wohl „Ja und Nein“: Halbfinale erreicht, Weltmeistertitel leider verpasst. Wir lieben jetzt alle diese Nationalmannschaft. Leidenschaft, Risikofreude und auch Enthusiasmus sind Attribute, die diese Mannschaft prägen. Warum sollen diese Attribute nicht in hochkomplexe Aufgabenstellungen der Informationstechnologie transformiert werden können?
Wir bei Audi haben uns ein sehr anspruchsvolles Volumenwachstum vorgenommen. Diese Wachstumsziele reflektieren sich natürlich auch in unseren zukünftigen IT Landscapes und unserem dazugehörigem IT-Projektportfolio. Unsere IT-Strategiepläne reichen bis in das Jahr 2015. Und hier spielen zukünftig Service-orientiere Architekturen (SOA) eine große Rolle. Ich sehe dramatische Chancen für unser Business, dieses geplante Wachstum in neuen, innovativen (SOA)- Lösungen abbilden und managen zu können. Wir müssen unsere Lösungen viel schneller den Fachbereichen zur Verfügung stellen können. Man kann nicht mehr monatelang ins Trainingslager gehen und Lastenheft- und Pflichtenheft-Diskussionen führen, wenn sich an anderer Stelle die Zeit nicht mehr hereinholen lässt.
Eine der (SOA)- Chancen liegt eben in der Wiederverwendbarkeit und der Qualität von entwickelten Services. Mit einem gemeinsamen SOA-Verständnis im Unternehmen, in den Fachbereichen und in den IT-Abteilungen, werden sich Wege aus der Legacy-Falle finden lassen.
Service-orientierte Architekturen (SOA) beschreiben, wie das Unternehmen eine Middleware nutzen kann, um lose gekoppelte, verteilte Services zu erreichen. Diese sogenannten Services zeichnen sich aus Sicht einer SOA unter anderem dadurch aus, dass sie grob-granularer als Komponentenschnittstellen sind, sowie stärker hinsichtlich ihrer Geschäftsrelevanz strukturiert sind als Komponenten.
Die hier genannten Eigenschaften können auch mit komponenten-orientierten Architekturen wie CORBA oder DCOM erreicht werden, denn das Konzept der „Serviceorientierung“ ist im Bereich dieser Middleware-Systeme entstanden. Die Ziele von SOA gehen jedoch weiter und ermöglichen neben der Orchestrierung von Services auch die Einbindung bestehender Systeme. Erreicht wird die Umsetzung des SOA-Konzepts durch Maßnahmen wie Standardisierung und die Nutzung von unterstützenden Komponenten. Zum Beispiel stellen Web Services eine mögliche – standardisierte – Realisierung einer SOA dar.
Eine zentrale Weiterentwicklung des Konzepts aus technischer Sicht ist eine Architektur-Struktur, die als Enterprise Service Bus (ESB) bezeichnet wird, und nicht nur eine Laufzeitumgebung für Services bereitstellt, sondern auch der Integration unternehmensweiter Informationssysteme dient. Diese Einbindung bestehender „Altsysteme“ ist nötig, damit diese an systemübergreifenden Geschäftsprozessen teilnehmen können, um die Ziele einer SOA wie „verbesserte Geschäftsagilität“ zu erreichen. Berücksichtigt man weiterhin, dass hier auch ein Paradigmenwechsel für die Unternehmensorganisation vorliegt, so werden SOA-Projekte in den nächsten Jahren eher die Regel als die Ausnahme sein.
Es klingt wirklich verlockend und erfolgversprechend: die Ablösung von Applikationen, die in die Jahre ge-kommen sind – und eine stetige Quelle von ungeplanten Folgekosten sind – durch neue Standardapplikationen, die nach dem SOA-Ansatz konzeptioniert sind, in Angriff zu nehmen. Viele Anbieter erklären, dass in der Um-stellung auf SOA-basierende und sowohl modular als auch adaptiv aufgebaute Geschäftsprozess-Plattformen (Business Process Platforms (BPP)) die ideale Lösung zur Flucht aus der „Legacy-Falle“ zu sehen ist.
Allerdings soll bei aller (Hersteller-) Euphorie berücksichtigt werden, dass nur sehr wenige der angebotenen Produkte eine hinreichende Vollständigkeit in Bezug auf die funktionalen und technologischen Anforderungen einer BPP/SOA-Vision besitzen. Ferner ist der Übergang von Legacy-Systemen zu Service-orientierten Ge-schäftsprozess-Plattformen keineswegs so unkompliziert, wie beispielsweise die Einführung der ERP-Systeme der ersten Generation, sondern definitiv mit einem Paradigmenwechsel verbunden. Trotzdem gibt es technolo-gisch und betriebswirtschaftlich gesehen keine Alternative, wenn die Ablösung von Legacy-Systemen auf der Basis eines perfekten Business/IT-Alignments und im Bestreben nach einer Professionalisierung der IT stattfin-den soll. Nachhaltigen Erfolg werden sicher nur diejenigen Unternehmen haben, die diese Herausforderung auf der Basis eines ganzheitlichen Architektur- und Serviceverständnisses annehmen.
Der SOA Blueprint sieht die Integration bestehender Systeme explizit vor. Legacy-Software wird durch Service-Interfaces gekappselt, um einzelne funktionale Blöcke als Dienst auf hoher Ebene wieder zu verwenden. Im Unterschied zu den Ansätzen der objektorientierten Programmierung und der Komponententechnik erfolgt die Wiederverwendung auf eine sehr viel pragmatischere Art und Weise. So kann ein Hostsystem mit einfachen Services ausgestattet werden, die keine Änderung des Legacy-Systems erfordern. Der Service selbst muss nicht einmal auf dem Host-System ablaufen, er kann über bestehende Schnittstellen (zum Beispiel FTP) interagieren. Dieser Ansatz wiederspricht selbstverständlich dem Bedürfnis vieler Hersteller, Bridges oder EAI Infrastruktur zu verkaufen oder ein Host-System in verschiedene Komponenten aufzubrechen. Voraussetzung ist jedoch eine funktionale Schneidung des bestehenden Systems, die sehr nahe an der bestehenden Struktur dieses Systems erfolgt.
SOA ist die ideale Re-Engineering Zielplattform
Soll ein Legacy-System abgelöst werden, so ist SOA gradezu als Zielplattform für das Re-Engineering prädestiniert. Die einzelnen funktionalen Blöcke des Legacy-Systems werden als Services abgebildet. Die Aufrufsequenzen, wie sie nutzende Systeme oder Batch-Prozesse ausführen, werden als Business-Prozesse modelliert und sind dank BPEL automatisch ausführbar. Aufrufe von Subprogrammen können als Business Rules modelliert werden. Damit wird ein Legacy System in Teilsysteme aufgeteilt. Diese Teilsysteme können entweder als neue Services realisiert oder aber direkt weiterverwendet werden.
SOA ist technisch prinzipiell nichts Neues, sondern vereinfacht und standardisiert Konzepte wie den „Software-Bus“ der 80er und Client-Server Architekturen der 90er. Ein zusätzlicher Mehrwert ist die Zusammenführung moderner Java- und Web-Technologien mit klassischen Host-Architekturen. Dies alleine wäre zwar eine sehr hilfreiche Weiterentwicklung, würde aber den Wirbel nicht wert sein, der um SOA stattfindet. Erst die Modularisierung der Anwendungslandschaft, das Begreifen von Abläufen als Prozesse und die darauf fußende fachliche Modellierung von Services machen SOA wirklich interessant. Dadurch können – nicht nur theoretisch – Funktionen wieder verwendet werden und helfen so der IT und dem Business.
Die meisten Anbieter konzentrieren sich aber hauptsächlich auf die technischen Aspekte von SOA und lassen Unternehmen hinsichtlich der fachlichen Methodik meist mit Allgemeinplätzen auf sich gestellt. Insbesondere bei der konkreten Nutzenbetrachtung, zum Beispiel auf Basis eines realen Business Cases sind die von den meisten Anbietern geweckten Erwartungen nur schwer substantiierbar. Das Know-how über die betrieblichen Prozesse und deren Abbildung in Applikationen muss also in der IT vorhanden sein, käuflich ist dies nur – wenn überhaupt – selten und teuer. Ohne dieses Wissen wird der Umstieg auf SOA zur reinen Technik-Übung und die versprochenen Vorteile nur ansatzweise realisiert.
Einleitend muss ich, aus vielen persönlichen Erfahrungen schmerzhaft gelernt, sagen, dass wenn jemand mit Königswegen, Patentrezepten oder Ähnlichem aufwartet, höchstes Misstrauen angebracht ist .Um die Aussage nun in diesem Kontext zu bewerten, müssen wir zunächst einige Gedanken an die Gründe für das Zuschnappen der Legacy-Falle verschwenden. Dies hat überhaupt nichts mit den genannten Programmiersprachen zu tun sondern lediglich mit mangelnder Disziplin in Bezug auf alles was wir seit langem über Software-Engineering wissen. Schlecht dokumentierter Spaghetti-Code, der die Ursache für die genannten Probleme darstellt, entsteht nicht durch die Verwendung einer bestimmten Programmiersprache sondern durch schlechtes Programmieren und fehlende Qualitätskontrolle bezogen auf Regeln (heute auch gerne Governance genannt) die ja meist durchaus existieren.
Der Service-orientierte Ansatz baut in den meisten Bereichen auf bewährten Software-Engineering-Regeln auf und stellt keine neuen revolutionären Konzepte bereit. Allein durch SOA wird also die Falle weder verlassen, noch zukünftig entschärft werden können!
Trotzdem glaube ich, dass der Service-orientierte Ansatz einen wertvollen Beitrag zum zukünftigen Vermeiden des Legacy-Dilemmas leisten kann, denn er führt, ausgelöst durch den Zwang, künftige System leichter veränderbar zu bauen, hoffentlich zu einem tiefgreifenden Umdenken bei der Konzeption und Implementierung von Software-Lösungen. Oberste Voraussetzung ist dabei dann aber ganz klar, dass ein Unternehmen ein für sich relevantes Regelwerk rund um eine SOA festlegt und die Einhaltung ganz konsequent erzwingt.
Eine realistische Einschätzung der Möglichkeiten von SOA als Königsweg aus der „Legacy-Falle“ setzt voraus, den rein technischen Blick auf SOA um die zugrunde liegende Geschäftslogik zu erweitern. SOA ist eine mächtige Architektur – reicht alleine jedoch nicht aus. Es gab zu viele Konzepte ähnlicher Argumentation, die alle an dem gleichen Punkt scheiterten: Der Geschäftssemantik. Nur wenn im Rahmen der SOA sichergestellt ist, dass die betriebswirtschaftlich notwendige Geschäftssemantik ausreichend Berücksichtigung findet, wird man den Versprechungen der SOA Protagonisten gerecht. SOA muss als Enterprise SOA, sprich Architektur mit der unabdingbar verknüpften Geschäftslogik, gesehen und verstanden werden. Das heißt, die ersten Gedanken liegen bei den Unternehmensanforderungen der Legacy-Anwendung sowie den dahinter liegenden Prozessen und Daten. Dieses Wissen führt in die Diskussion der benötigten Services und deren Granularität und Wiederverwendungsgrad. Der Gedanke, dass man diese Diskussion einheitlich in einer Service-orientierten Geschäftsprozessplattform führt, stellt meines Erachtens einen möglichen „Königsweg“ dar. Alles andere ist zu kurz gedacht und wird nicht den erhofften Mehrwert liefern.
Wie unsere Erfahrungen im Rahmen von Projekten im SOA-Umfeld haben gezeigt haben, ist die Migration von monolithischen Legacy-Systemen hin zu einer Service-orientierten Architektur (SOA) kein Selbstläufer. Die immer wieder von den SOA-Protagonisten genannten Vorteile, beispielsweise Wiederverwendung von Services, kürzere Time-to-Market, Kostensenkungen und Investitionsschutz, können nur dann auch tatsächlich realisiert werden, wenn Governance-Aspekte für SOA-basierende Geschäftsprozesse berücksichtigt werden.
Governance zielt hierbei zum einen auf Managementfunktionalität, die die Dienstgüte (Quality of Service, QoS) der beteiligten Services steuert. Unter Dienstgüte werden hierbei die nicht-funktionalen Service-Eigenschaften, wie zum Beispiel Verfügbarkeit, Antwortzeit und Fehlerrate, verstanden. Diese können zwischen Service Provider und Service Consumer in einem Service Level Agreement (SLA) verbindlich festgelegt werden. Zum anderen ist im Rahmen einer Corporate Governance sicherzustellen, dass die SOA-basierenden Geschäftsprozesse konform mit Unternehmensstrategie, Geschäftsmodell und rechtlichen Rahmenbedingungen sind.
Ein weiterer entscheidender Faktor bei der Ablösung von proprietären Legacy-Anwendungen ist der Erfolg diverser Standardisierungsbemühungen von Technologien im SOA-Umfeld, wie zum Beispiel der Web-Service-Technologie.
SOA wird von der Deutschen Post seit 1999 als zentrales Architekturparadigma genutzt. Zielsetzung war und ist die verbesserte Integration von Business und IT. Die Post nutzt SOA dabei als Managementwerkzeug, um statische Verflechtungen von Prozessen und IT auf wirkungsvolle Weise aufzulösen.
Ein gezieltes Service-Portfoliomanagement ist dabei ein Schlüsselfaktor. Es sorgt für Integration, die bereits auf der fachlichen und semantischen Ebene beginnt. Dieses Business-getriebene Vorgehen bereitet den Boden für eine weitere technische Integration der Anwendungslandschaften durch SOA.
Legacy-Anwendungen, aber auch moderne Applikationen können so erfolgreich durch SOA integriert werden. Die technische Integration ist indes Folge, nicht der Ausgangspunkt, einer fachlich getriebenen SOA-Strategie. Und genau hier liegt der Unter-schied von SOA zu vermeintlichen ‚Silver Bullets’ der Vergangenheit.
Die Reduzierung von SOA auf einen – technisch motivierten – Königsweg zur Legacy-Integration zäumt das Pferd von hinten auf. Denn eine SOA lässt sich nicht kaufen, sondern verlangt nachhaltiges Management. Zudem bleibt auch mit SOA die Komplexität moderner Anwendungslandschaften weiterhin vorhanden – wenn auch mit steigender Beherrschbarkeit.
Serviceorientierung steht bei IT-Vorständen und CIOs derzeit hoch im Kurs – und das aus gutem Grund. So besteht bei traditionellen, monolithischen Anwendungen das Problem, dass jede Änderung eines Prozesses ein mehr oder weniger aufwändiges Redesign des Gesamtsystems erfordert. Einer der wichtigsten Treiber für SOA-Projekte ist die Verkürzung der Time-to-Market, die wiederum zu einer schnelleren Time-to-Value beiträgt. So prognostizieren namhafte Analysten, dass Wettbewerbsfähigkeit der Unternehmen künftig über Reaktionsfähigkeit entschieden wird. Somit rückt folgende Frage immer mehr in den Mittelpunkt: „Wie schnell ist Ihr Unternehmen in der Lage seine innovativen Ideen in marktreife Produkte oder Sevices umzusetzen?”
Serviceorientierte Architekturen vereinfachen organisatorische Veränderungen, indem sie Funktionen kapseln und in lose gekoppelte Einheiten zur Verfügung stellen. Auf diese Art und Weise können auch Legacy Anwendungen modernisiert oder teilweise sukzessive ersetzt werden und erhöhen somit die Reaktionsfähigkeit der Unternehmen. Die Grundidee, diverse Unternehmensfunktionen zu ordnen und sie als unabhängige Dienste intern sowie extern zur Verfügung zu stellen, setzt voraus, dass Anwendungen servicefähig sind. Legacy-Anwendungen erfüllen diese Eigenschaft in der Regel nicht, somit müssen die Systeme zunächst unter dem Serviceaspekt aufbereitet werden und anschließend SOA-gerecht integriert werden.
Service Orientierte Architekturen sind im Moment vor allem für Hersteller Königswege aus den unterschiedlichsten Motivationen. Für IBM ist es die Bindekraft und das einheitliche Leitbild, das bisher e-Business eingenommen hat. Für SAP ist es der Weg aus der eigenen Vergangenheit, die entwicklungstechnisch nur noch schwer zu beherrschen war. Für Oracle und andere Technologie-Zukäufer ist es die Chance, alle Teillösungen unter ein einheitliches Erscheinungsbild zu bekommen. Für Microsoft ist es sowohl die Chance, die eigene Produktentwicklung von Komplexität zu befreien als auch weiterhin Technologieglaubwürdigkeit zu behalten.
Anwender sollten das „A“ in SOA besonders betonen. Es ist der wichtigste Begriff. Die Architektur muss im eigenen Hause entwickelt und den individuellen Gegebenheiten angepasst sein. Hier wird der zukünftige Grundstein für erfolgreiche IT/Business-Integration gelegt. Diese nächste Abstraktionswelle der IT – nach der Mainframe-Ära und den Client/Server-Architekturen – ist eine langfristige Umstellung in der Art, wie IT-Lösungen das Kerngeschäft der Unternehmen unterstützen. Kurzfristige Erfolge werden eher die Ausnahme bleiben. Insofern ist der SOA-Weg eher ein langer Königsmarsch als ein einfacher Königweg aus der Legacy-Falle.
SOA (SOE) stellt eindeutig keine Technologie, sondert ein Architekturkonzept, ein Managementframework dar.
Folgedessen kann ich SOA / SOE nicht als Standard kaufen, implementieren und betreiben.
Andererseits können mittels SOA / SOE vielfältige Anforderungen interner und externer Art durch das Unternehmen erfüllt werden.
SOA / SOE greift auch die alte Idee des Profitcenters wieder auf und macht auch nur mittelbar am Unternehmenserfolg beteiligte Bereiche profitabel.
Es geht also auch um Software, um Legacy-Systeme, um Tools. Auch, aber eben nicht nur.
SOA / SOE geht sehr viel weiter. Die Idee der SOA / des SOE – ursprünglich im IT-Bereich entwickelt, hat diese Idee das gesamte Unternehmen, die Prozess- und die Aufbauorganisation, erfaßt.
SOA / SOE ist ein Managementframework geworden, das als strategische Unternehmensausrichtung verstanden
verstanden und implementiert werden muß.
Peter E. Teichreber
Consultant Geschäftsprozessoptimierung
LEgacy los zu werden ist aktuell sicherlich einer der größten Treiber bei IT Projekten. Aber ich sehe nicht so ganz wie die Einführung einer neuen Programmiersprache (Java oder .NET) und das kaufen einer Middleware (Oracle, SAP, …) verhindert dass wir in 10 Jahre wieder vor einer Altlast stehen?
Dank zunehmender IT Unterstützung und Integration nimmt die Komplexitaet von IT Lösungen zu, diese werden durch eine verteilte Architektur nicht einfacher ersetzbar.
Und die Datenhaltung wird noch garnicht von einer Service Orientierung addressiert. Höchstens der durchgriff durch die Anwendung wird einfacher (wenn es die Anwendung zuläßt, aber man kann einer Host Datenbank sicher nicht vorwerfen dass diese die Daten versteckt)
Gruss
Bernd
Der aus IT Sicht nachvollziehbare Ansatz, über SOA Kosten in den Griff zu bekommen, ist nachvollziehbar. Bevor das gelingt, muss investiert werden und Kollegen aus dem Business haben entweder den Begriff noch nicht gehört oder halten ihn für einen der vielen IT Hypes.
Für das Business ist es daher meiner Erfahrung nach viel wichtiger darzustellen, wie SOA dazu beitragen kann, den heutigen Anforderungen an die Unternehmen in den Bereichen Flexibilität oder Innovation gerecht zu werden. Sei es, weil mit SOA IT Projekte schneller realisiert werden können, sei es, weil sich über die Anbindung von Drittanwendungen neue Funktionen schnell bereitstellen lassen.
Die Anbindung von Legacy Systemen kommt im Kielwasser mit.
Ich bin der Meinung, dass Legacy ein absolut dehnbarer Begriff ist. Was für viele Legacy ist, ist für die anderen der gerade nachvollzogenen Systemaupgrade auf ein Release, das aber bereits schon seit 5 Jahren auf dem Markt ist. Und Legacy-System sollten nicht gleichbedeutend mit “negativ”, “altmodisch”, “innovationsresistent” und schlecht gesehen werden. Vielmehr ist in einer aktiv “gemanageten” System- und Anwendungslandschaft immer ein Teil älter und ein anderer Teil jünger. Wichtig ist ein vernüftiger Mix mit dem Bestreben, auch die älteren Systeme zukunftfähig zu machen oder ggfs. auszutauschen. Das schlichte Argument “never change a running system” bzw. die Änderung wird auf jeden Fall teuer, als die Weiterbenutzung des bestehenden Systems (wenn auch mit schlechteren Nutzungsmöglichkeiten) geht in aller Regel nach hinten los: Die “Legacy-Schere” geht immer weiter auf und inkrementelle Anpassungen werden zunehmend unmöglich, das zu viele Technologiesprünge auf einmal gemacht werden müssten. Folglich gräbt sich das Unternehmen IT-mäßig immer mehr in seine Historie ein.
Trotzdem wird es auch in Unternehmen, deren IT nach “adaptiven Regeln” geführt wird, immer Anwendungen geben, die älter und somit potentielle Legacy-Anwendungen sind. Ich sehe daher nicht in 10 Jahren wieder einen Legacy-Berg von Anwendungen, sondern im Rahmen von kontinuierlichen Anpassungen werden immer Altsystem im Anwendungsportfolio sein. Wichtig ist die zugrundeliegende Architektur (inkl. eines aktiven Applikationsportfolio-Managements), die verhindert, dass ältere System zu unüberwindlichen Legacy-Fallen werden. SOAs haben das Potential, IT-Managern den Weg der kontinuierlichen Erneuerung ihrer Anwendungslandschaft leichter zu machen.
… allerdings bin ich mir nicht sicher ob es dank SOA nicht eher mehr als weniger Legacy Anwendungen gibt, da diese dank MDM so “halb” für lange Zeit parallel laufen können mit einer lockeren “notdürftigen” kopplung.
Das ist jedenfalls eine Situation die man als EA unbedingt vermeiden muss.
Bernd
SOA oder Enterprise SOA darauf zu reduzieren wäre aus meiner Sicht, dann doch eine etwas zu eingeschränkte Perspektive.
Menschen arbeiten entlang von Geschäftsszenarien (Prozessen, Wertschöpfungsketten), die sich, wie wir alle erleben dürfen, einer hohen Dynamik ausgesetzt sind. Entsprechend wird es auch immer Systeme oder Services geben, die in die Jahre kommen und neu überdacht werden müssen.
Und Menschen arbeiten über Technologie- und Systemgrenzen hinweg.
SOA oder ESOA sollte als Architekturkonzept beiden Sichtweisen Mensch – Geschäftsszenarien und Mensch – Technologie dienen.
Dazu bedarf es meiner Meinung nach, dass SOA /ESOA sich als ein flexibles, sich potentiell stetig veränderndes Rahmenwerk versteht und ein fachlich logisches und technologisches Abbild heutiger und zukünftiger Geschäftsszenarien und Technologien/Standards darstellt.
SOA oder unter dem Aspekt der Geschäftsszenarien vielleicht besser ESOA birgt damit nicht nur das Potential einer neuen technologischen Ära der Service- und Repository-Orientierung, sondern auch ein betriebswirtschaftlich unternehmensorganisatorisches Potential, in der IT- und Fachverantwortliche in neuen Rollen positiv ertragssteigernd zusammenarbeiten.
Enterprise Content Management (ECM) befasst sich gemäss der AAIM Definition mit den unstrukturierten Daten einer Organisation. SOA steht hingegen für die ganzheitliche Betrachtung einer IT-Systemlandschaft als Unterstützungsfunktion für betriebliche Prozesse. Da sehe ich keine Nähe zwischen ECM und SOA.
Selbstverständlich kann eine ECM Infrastruktur mittels SOA umgesetzt werden, wobei noch zu diskutieren wäre, welche Vorteile denn SOA als Realisierungarchitektur im Gegensatz zu einer Umsetzung mit einem Standard ECM-Produkt hat. Hauptsächlich sehe ich die Schwierigkeit darin, unstrukturierte Daten durch die Orchestrierungsprozesse zu schleusen, d.h. erheblichen zusätzlichen Datentransfer zu erzeugen.
Sehr geehrter Herr Liebhart,
SOA ist im ECM-Bereich keine Fantasie sondern tagtägliche Praxis. Hierbei spielt die Art der Daten – die im ECM-Bereich zumindest semistrukturiert ist – keine große Rolle. Es geht vielmehr darum, über eine standardisierte Plattform die Integration der verschiedenen Komponenten einer ECM-Strategie zu erreichen.
ECM ist kein “Produkt”, sondern ein für jedes Unternehmen individuelles Konzept, dass mit einer Vielzahl von Produkten realisiert werden kann.
Das SOA im Bereich Overhead, Sicherheit, etc. noch entwicklungsfähig ist, steht auf einem anderen Blatt.
Herzlichst,
Ihr Jörg Dennis Krüger