![[externer Link]](../../../../images/link.gif)
www.computerwoche.de/soa-expertenrat/, wo neben Herstellern auch Anwender aus Unternehmen verschiedener Größen bloggen.Bereichsleiter (beiläufig): Heute habe ich schon wieder so eine Einladung zu einem SOA-Frühstück erhalten. Möchte da jemand hin?
Programmierer (begeistert): Ich wollte mich schon länger zu Web-Services weiterbilden! Das Angebot würde ich annehmen.
Berater: Na, das wird wohl nichts für Sie sein. Das dürfte wohl thematisch eher auf die Führungsetage zugeschnitten sein. Da gehts in der Regel um strategische Neuausrichtung.
Programmierer: Was haben denn Web-Services mit Neuausrichtung zu tun? Mir geht es um Wiederverwendbarkeit! Und die Benutzbarkeit von Services, die Dienstleister zur Verfügung stellen. Jeder programmierte doch früher sein eigenes Süppchen zusammen – bei Ressourcenknappheit musste man womöglich externe Bibliotheken einkaufen, die keinen standardisierten Zugriff erlauben, also hohe Einarbeitungszeiten erfordern. Das kann durch Web-Services endlich besser werden.
Bereichsleiter (nachdenklich): Wir wollten ja schon letztes Jahr die Effektivität unserer IT steigern – das ist nur zum Teil gelungen. Zu viele Teilbereiche haben nicht verstanden, wo wir hinwollten. Und wir mussten auch eingestehen, die Anforderungen thematisch unterschätzt zu haben.
Projektleiter: Moment mal, Ihr redet aneinander vorbei! Web-Services müssen doch nichts mit SOA zu tun haben. Das ist eine zu einseitige Betrachtung. Ich habe in vergangenen Projekten gelernt, dass man vor allem den Projektsponsor und sein Problem verstehen muss... Dem wird SOA schon eher gerecht.
Berater (nickt): SOA steht dafür, seine Geschäftbereiche grundlegend zu analysieren, indem man die angebotenen Leistungen seiner Abteilungen oder auch eines Dienstleisters und deren Schnittstellen betrachtet und daraus ein genaueres Verständnis gewinnt. Man hat erkannt, dass Menschen und Prozesse genau verstanden werden müssen, bevor wir "im System denken" können.
Projektleiter: Es geht auch darum Schnittstellen, Daten und Methoden zu entflechten, um den erhöhten Aufwand für mehrfach vorhandene Prozesse aufzuzeigen. Nicht nur im Prozesswesen, sondern auch bei dessen Umsetzung in der IT kann man dann Einsparpotenzial entdecken.
Administrator (skeptisch): So neu ist das doch aber nicht! Früher hatten wir viele AbteilungsServer und oft hat jemand in der Abteilung diesen Server betreut – meist nebenher. Heute haben wir zentrale Server und hauptamtliche Administratoren, die mehr von ihrer Tätigkeit verstehen.
Sicherheitsbeauftragter: Und das ist auch gut so! Wenn ich mich daran erinnere, was für Vorfälle wir seinerzeit gehabt haben, weil niemand an Sicherheit und Datenschutz gedacht hat... Von den Personalakten auf dem Etagendrucker will ich ja gar nicht wieder anfangen.
Bereichsleiter: Wir achten doch schon länger darauf, unsere Geschäftsabläufe möglichst schlank zu gestalten. Mir kann SOA nur dann etwas bringen, wenn ich das damit der Führungsebene besser klarmachen kann. An technischen Details ist man da kaum interessiert – Einsparungen und Effizienzsteigerungen sind gefragt!
Projektleiter: Ich wollte darauf hinaus, dass die Analyse der Schnittstellen und Prozesse ermöglicht, eine softwaregestützte Modellierung vorzunehmen. Dabei geht es zugegebenermaßen nicht nur um Prozesse – das wäre reines Business Process Management. Es geht vielmehr auch um deren nachhaltige Umsetzung unter Berücksichtigung der Wiederverwendbarkeit!
Bereichsleiter: Ein Hauptproblem für mich bleibt immer noch, dass ich im Vorwege nicht erfahren kann, was eine Änderung durch ein Projekt bewirkt. Deshalb haben wir doch mit BPM angefangen und auch damit, die Modellierung von Prozessen einzubeziehen, seit Neuestem sogar mit der Möglichkeit, Veränderungen zu simulieren.
Administrator: Andere Probleme haben uns ja zusätzlich auch im Systembereich zu schaffen gemacht: Die Abteilungen wollten von uns Daten geliefert bekommen, die in verschiedensten Systemen gespeichert wurden. Immer wieder gab es Probleme bei der Zusammenführung!
Programmierer: Da kam vor einigen Jahren ja EAI auf – Enterprise Application Integration. Historisch bedingt waren Softwareentwickler früher an lokalen Standorten tätig und haben direkt auf Zuruf Anforderungen umgesetzt. Als Anwendungen so komplex wurden, dass das kein Mensch mehr alleine machen konnte, fing man an das Ganze in kleine Stücke zu zerteilen und musste nun mit etwas erhöhtem Aufwand alle Stücke wieder zusammensetzen – das war nur mithilfe von Werkzeugen möglich, also klassischem Anwendungs- und Versionsmanagement. (fragende Blicke aus der Runde) Und seit einigen Jahren ist es essenziell, dass die Anwendungen gegenseitig auf ihre Daten zugreifen können. Da hat EAI ja auch unbestreitbar geholfen, jedoch war es weitestgehend auf die Systeme fixiert. Für EAI wurden passende Werkzeuge entwickelt, bei SOA genauso: JCoffee ist zum Beispiel die Java-Variante zum Erstellen von SOA-konformen Komponenten. Alle großen Hersteller haben jetzt auch Lösungen, um SOA zu unterstützen – zum Beispiel im Workflow, als Programmier-Frameworks oder zur Datenintegration.
(Stille)
Administrator: Bezüglich der Integration ist die Einführung und Nutzung von Directory Services oder Datenreplikationsmechanismen ja auch nichts Neues mehr. Schwieriger wird es, verschiedene Directories oder Datenstände abzugleichen, weil Synchronisationsmechanismen natürlich abhängig von der Infrastruktur bleiben – da hilft auch SOA nicht drüber hinweg. Obwohl es mit standardisierten Sicherheitsmechanismen jetzt immer besser möglich wird, die Authentifizierung und Autorisation auch speziell auf Web-Services zu erlauben. Die Erweiterung der vorhandenen A&A-Produkte kann doch aber nur sinnvoll laufen, wenn wir vorher nachdenken, mit wem wir morgen sprechen wollen. Fraglich ist hierbei sicherlich, ob sich der Einsatz – besonders über das Internet – als so sicher erweist wie geplant.
Berater: Da gibt es ja noch kaum Referenzen. Die meisten Unternehmen fangen aber an, sich intern mit SOA auseinanderzusetzen. Da gibts dann bestimmt auch bald mal Erfahrungen, wie sicher die Kommunikation verschiedener Services über das Internet ist. Aber darauf kann man nicht warten! Erst dann über SOA nachzudenken wäre fatal: Fast alle großen Firmen haben schon Piloten oder Adaptionsprogramme begonnen. Daran merkt man, dass SOA an Bedeutung nicht mehr wegzudiskutieren ist!
Bereichsleiter (schaut den Programmierer an): Das lässt sich auf Unternehmungen übertragen: Durch die Globalisierung werden Unternehmen so komplex, dass man nun anfangen muss, genauer zu verstehen, wie die einzelnen Bereiche zusammenarbeiten. Wichtig ist dabei, dass hinter Prozessen nicht nur Systeme stehen, sondern oft auch Menschen, die eine manuelle Tätigkeit ausführen. Erst wenn man anfängt, die Prozesse als Ganzes zu modellieren, kann man sie auch mit IT wirklich gut unterstützen. Oft zeigen erst softwaregestützte Simulationen, ob eine Parallelisierung etwas verbessern kann oder ob ein anderer Mitarbeiter eine Tätigkeit vielleicht zu einem anderen Zeitpunkt besser ausführen könnte.
Berater: Ja! Und genau hier wird ein Durchbruch mit SOA erreicht: geschäftliche und technologische Betrachtungsaspekte fließen endlich zusammen. SOA betrachtet nicht mehr nur einen Web-Service, sondern unterstützt die Unternehmung mit Mitteln, die sich in verschiedensten Bereichen als sehr nützlich erwiesen haben. Wenn man so will, sind EAI und BPM quasi Vater und Mutter von SOA. Das alles braucht aber Zeit: Auf einschlägigen internationalen Konferenzen geht man davon aus, dass SOA nicht nur Jahre, sondern über die ganzen nächsten Dekaden hinweg als wichtige Triebfeder dienen wird.
Projektleiter: SOA ist aber auch kein Allheilmittel! Es ist notwendig, dass alle Mitarbeiter auch daran erinnert werden, etwas über den Tellerrand zu schauen. Hier dürfen wir nicht – nur um den Anschluss zu behalten – mögliche Probleme ausblenden, sondern müssen uns den zukünftigen Herausforderungen wirklich stellen. Dabei dürfen wir auch die Systeme und die Sicherheit nicht außer Acht lassen!
Programmierer: Und das Beschaffungsproblem nicht vergessen! Es geht ja aus Anwendungssicht darum, dass ich nicht immer alles neu programmieren kann. Dann muss ich aber auch wissen, woher ich einen Service bekomme. Ein Beispiel, wo das geklappt hat, ist unser Logistikprogramm, das jetzt sein Kartenmaterial von einem Anbieter über das Internet abruft – das war früher aufgrund der Bandbreiten unserer Netze völlig undenkbar.
Administrator: Jetzt versteh ich auch, warum die Netzlast so hoch ist. Warum hat denn keiner mit mir gesprochen? Naja... Bei Web-Services gibt es aber noch andere Probleme: Kennt ihr das Simple Object Access Protocol, kurz SOAP? SOAP über HTTP wird von vielen Administratoren gar nicht erkannt, weil die meisten Firewallsysteme davon ausgehen, dass da nur eine normale WWW-Kommunikation läuft – obwohl tatsächlich aber ein Service von außerhalb befragt wird, der auf dem anfragenden System durchaus erweiterte Privilegien genießen kann. Wir müssen uns also darauf vorbereiten auch hier unseren Blickwinkel zu erweitern!
Projektleiter (nachdenklich): Mir war gar nicht bewusst, dass wir dich hätten fragen müssen – wir haben den Zugang zum Internet einfach als gegeben betrachtet.
Berater (freudig): Sehen Sie, was ich meine? Da ist eine Anforderung, die schon lange auf der Wunschliste der Logistiker stand. Jetzt, wo Sie einen Service-Dienstleister gefunden haben, der Ihnen für erschwingliches Geld Kartenmaterial ins Haus liefert, erweitern Sie Ihre Anwendung endlich! Aber Sie haben dabei übersehen, dass ein anderer Service dafür gebraucht wird: Den stellt Ihr Administrator zur Verfügung, ohne dass Sie noch darüber nachdenken. Genau solche Abhängigkeiten versucht SOA aufzuzeigen, indem "interne" Dienstleistungen – wie der Internetzugang – nicht einfach als gegeben betrachtet werden. Und auch die Frage nach der Quantität der benötigten Services ist hierbei von Bedeutung!
Bereichsleiter: Dann wissen wir also vorher, welcher Service benötigt wird... Aber wenn es dem Projektleiter bewusst ist, fragt er ja auch – das setze ich mal voraus.
Berater: Zu vieles vorauszusetzen ist ein häufiger Fehler! Wenn es im Unternehmen nicht gelingt, Mitarbeitern den Sinn von SOA klarzumachen, dann kann man sich vorstellen, dass man gegenüber Unternehmen ins Hintertreffen gerät, die das schaffen – das kann einen spürbaren Wettbewerbsnachteil bewirken.
Programmierer: Gerade darum geht es doch! Wir waren nicht in der Lage, selber eine Anwendung zu schreiben, die uns Kartenmaterial aufbereitet. Über die Dienstleistung von außen konnten wir einen Vorteil im Logistikbereich erarbeiten. Dazu müssen wir aber wissen, wie wir darauf zugreifen können.
Sicherheitsbeauftragter: Unsere vorhandenen Systeme müssen sicherheitstechnisch ohnehin immer wieder überprüft werden. Solche Projekte eignen sich dann hervorragend, um gleichzeitig darüber nachzudenken, wie eine Weiterentwicklung mit SOA zusammenpasst und ob diese Systeme wirklich abgelöst werden müssen. Wenn wir im Rahmen neuer Compliance-Anforderungen ein System sowieso ablösen müssen, dann könnte man diesen Zeitpunkt nutzen, um den Ersatz unter SOA-Aspekten zu gestalten. Aber meistens brauchen wir ja gar keine neuen Produkte – und haben nicht auch zahlreiche Hersteller schon Erweiterungen im Angebot, um ihre Lösungen SOA-fähig zu machen und gleichzeitig die vorhandenen Sicherheitsmechanismen weitestgehend beizubehalten?!
Berater (wissend): Sie haben ja im Kleinen mit SOA schon angefangen, ohne dass es Ihnen bewusst war: Sie haben einen externen Service in Anspruch genommen, den Sie unmöglich in der Qualität und zu diesen Kosten im Hause hätten entwickeln können. SOA funktioniert zwar auch erstmal in kleinen Stücken, aber das Ziel muss sein, das große Ganze im Auge zu behalten! SOA muss früher oder später jeder nutzen, wenn er global integriert arbeiten möchte. Und wie gesagt: SOA "geschieht" nicht in ein oder zwei Jahren, sondern braucht viel mehr Zeit, weil es kein Software-Update in einem System ist, sondern eine Einstellungsveränderung in den Köpfen der Menschen voraussetzt! SOA ist notwendig, damit heutige Beschränkungen in der Verbindung vom Unternehmen und seiner Informationstechnik aufgebrochen werden können.
Bereichsleiter: Gerade die operativen Langzeitkosten wurden bei Themen, die man aus Flexibilitätsgründen gerne selbst umsetzen wollte, immer wieder völlig unterschätzt! Wir werden in Zukunft vermehrt auch Services von außen einsetzen müssen, um die Kosten unter Kontrolle zu halten und uns auf unser Kerngeschäft zu konzentrieren. Dabei müssen wir auch darüber nachdenken, wie wir vielleicht unsere eigenen Kernkompetenzen als Service nach außen anbieten können.
Administrator: Wo wir gerade dabei sind: Um überhaupt die SOA-konforme Integration zu ermöglichen, ist ein Enterprise-Service-Bus Voraussetzung. Und bei so einem ESB wird häufig missverstanden, wie wichtig die fehlerresistente Implementierung ist. Im Kleinen mag eine einfache Implementierung ja noch funktionieren, aber wenn dann die Kapazitäten und Verfügbarkeiten nicht richtig geplant sind, ist mit weitreichenden Folgen zu rechnen!
Sicherheitsbeauftragter: Wir haben schon eine recht eingeschliffene Benutzer- und Rollenverwaltung auf unserem Großrechner – hiermit verbunden läuft auch ein Transaktionssystem. Muss das jetzt durch einen ESB ersetzt werden? Dann müssten wir ja auch hier die Produkte ablösen – das hätte ja weitreichende Konsequenzen! Da wäre eine neue Benutzerverwaltung nur der Anfang...
Berater: Das ist schwer zu sagen, ob Sie da was Neues machen müssen – ich habe ja jetzt Ihr gesamtes Unternehmen nicht mit allen Prozessen und Schnittstellen im Kopf... Aber ob Sie es glauben oder nicht: Vielleicht haben Sie mit Ihrem Transaktionssystem ja schon einen ESB! Es geht nun darum, genau den Teil zu beginnen, den Sie bisher nicht haben: nämlich die Prozesse und Schnittstellen, die nie dokumentiert wurden, endlich wahrzunehmen und bewusst mit ihnen zu arbeiten. Hierbei muss man sich dann auch fragen, ob einige Services besser von außen zu beziehen wären – so wie mit dem Kartenmaterial. Aber ein Transaktionssystem auf einem Großrechner klingt wirklich so, als hätten Sie schon Ihren ESB-Grundstock! Die Frage ist, ob er allen Anforderungen der Zukunft genügt. Ich möchte hierbei wieder auf die Wichtigkeit der Analyse Ihrer internen Services hinweisen! Stichwort: Anforderungsmanagement.
Projektleiter: Machmal denke ich, die IT-Anbieter haben jetzt einfach nur begriffen, dass kein Unternehmen auf der Welt aus irgendeinem noch so verlockendem Grund das Risiko eingehen wird, alles auf einmal umzubrechen. Fast jedes Unternehmen hat mehrere IT-Projekte, die per Notbremsung gestoppt wurden. Heute verlangt einfach jeder nach der Integration mit den Altsystemen – und das zurecht. SOA versucht nun von Anfang an damit umzugehen, dass es – wie man so schön sagt – nicht auf der grünen Wiese startet.
Administrator: Ja, das stimmt. Aber es kann auch kein Unternehmen von heute auf morgen seine gesamte Kommunikation auf einen ESB umlenken. Und auch in kleinen Schritten wird das scheitern, wenn man sich vorher nicht im Ganzen klar darüber ist, was alles an Daten darüber fließt, will sagen, welche Prozesse letztlich unterstützt werden müssen. Auch wird zu oft vermittelt, dass ein ESB ein einziges neues Produkt sein muss: Für kleinere Unternehmen gibt es sogar schon Appliances, die Sicherheitsintegration und ESB vereinen sollen, ähnlich den integrierten Sicherheitslösungen mit Firewall und Intrusion Detection. Ich denke, zumindest in größeren Unternehmen wird erst eine Reihe von Systemen den ESB implementieren.
Sicherheitsbeauftragter: Dann kann man also alle Altsysteme und die Sicherheitskontrollen so belassen? Ich glaube, da sind verschiedene Fakten noch nicht beleuchtet worden! Wie zum Beispiel gehen wir mit externen Services um, wenn diese sehr wichtig für unseren Geschäftserfolg werden?
Programmierer: Ich müsste mal prüfen, wie wir eigentlich auf das Kartenmaterial zugreifen – das kann ich aus dem Stegreif nicht sagen. Wir haben vom Anbieter Quellcode geliefert bekommen, den wir mit wenigen Änderungen übernommen haben.
Berater: Ihre Benutzerverwaltung, Ihr Rollensystem – all das bleibt durchaus erhalten, aber es gibt ganz neue Sicherheitsaspekte, die beim vermeintlich sicheren Zugriff auf Services außerhalb Ihrer Kontrolle zu Bedeutung gelangen! Wem werden Sie in der Zukunft vertrauen, wie wird sich ein beauftragter Service Ihnen gegenüber authentifizieren? Es muss sicher sein, dass – um auf das Kartenmaterial zurückzukommen – keiner die Geodaten manipuliert, um für Verwirrung zu sorgen und damit einen Wettbewerbsvorteil zu bekommen. Und das wäre ja noch harmlos! Nehmen wir mal an, mit dem Quellcode, den Sie verwendet haben, hätte der Anbieter noch ganz andere Programmfunktionen eingeschleust, etwa um bei Ihnen Informationen zu sammeln. Durch offenen und dokumentierten Quellcode haben Sie zwar die Möglichkeit zu kontrollieren, aber haben Sie das auch getan?
Programmierer (nachdenklich): Nein, dazu hatten wir gar keine Zeit. Mir wird grade bewusst, wovon Sie sprechen! Wenn wir in Zukunft oft keine Software mehr kaufen, die wir selber konfigurieren, sondern nur einen Service über das Netz in Anspruch nehmen, dann müssen wir irgendwie sicherstellen, dass wir auch das bekommen, was wir eigentlich haben wollen – und nur das! Und dass wir es auch wirklich von dem bekommen, von dem wir es erwarten...
Berater: Es kommt noch ein wichtiger Faktor hinzu: Wenn Sie einen ESB implementiert haben und dieser kompromittiert wird, ist das etwas ganz anderes, als wenn verschiedene Systeme nur jede Nacht über Batchläufe miteinander Daten austauschen... Noch komplizierter wird es, wenn Sie selbst Daten anbieten, also nicht nur Konsument von Services, sondern auch Anbieter sind.
Sicherheitsbeauftragter: Im Gegensatz zu den derzeit gängigen Verfahren zur Identifikation und Kommunikationssicherung wird sich wohl bei SOA erst noch zeigen müssen, wie gut das Auffinden und Sichern von Services zwischen verschiedenen Unternehmen letztlich funktioniert. Ich erwarte aber nicht, dass wir dafür sofort neue Verfahren finden müssen, denn wir werden natürlich die ersten Services mit Dienstleistern implementieren, denen wir partnerschaftlich verbunden sind. Dennoch: Wie schon erwähnt, muss sich die Sicherheit von Services über das Internet erst noch erweisen, um das Vertrauen in deren flexible Benutzung zu unterstützen.
Bereichsleiter: Werte Herren, nichts für ungut, aber ich habe noch einen Termin…
Programmierer: Wie sieht es denn mit dem SOA-Frühstück aus?
Bereichsleiter: Ich glaube jetzt, dass ich diesen Termin doch lieber selbst wahrnehmen sollte…
Mehr Informationen zu SOA gibt es auch auf den Portalen aller großen Softwarehersteller – IBM, Microsoft, SAP, Sun, um nur einige zu nennen. Empfehlenswert ist zudem der "SOA-Expertenrat" auf www.computerwoche.de/soa-expertenrat/, wo neben Herstellern auch Anwender aus Unternehmen verschiedener Größen bloggen.
Joel Loewenstein ist IT Architect bei der IBM Business Services GmbH.
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2007#4, Seite 6
tag:kes.info,2007:art:2007-4-006
| 