Wie das in der Praxis aussehen kann, diskutieren Vertreter von Bea, Computer Associates, Enteo, IBM, IDS Scheer AG, Microsoft, Oracle, Software AG und T-Systems mit IDG-Redakteur Uwe Küll und dem freien Journalisten Bernd Seidel
? In der Realität scheint SOA in den Führungsetagen nicht angekommen zu sein. Wie kann ich den Business-Verantwortlichen dafür interessieren?
Dr. Wolfram Jost, Vorstand der IDS Scheer AG: Wir versuchen dem Management zu verdeutlichen, was ihm eigentlich längst klar ist: dass es sein Geschäftsmodell permanent anpassen muss und dass dies zwangsläufig bedeutet, dass sich Prozesse verändern - täglich, wöchentlich, monatlich. Wenn das Management nicht in der Lage ist, diese Anforderungen mit wenig IT-Aufwand umzusetzen, kann es seine Prozesse nicht so steuern, wie es erforderlich wäre. SOA ist die Antwort auf die Forderung nach einer adaptierbaren, also anpassungsfähigen IT. Der Fachbereich weiß mittlerweile, dass er ohne Software seine Prozesse nicht mehr innovativ steuern kann. Das heißt, er hat ein Selbstinteresse daran, sich des Themas anzunehmen.
?Sie meinen: Die Fachbereiche kommen auf die IT zu?
Jost: Das ist noch ein Wunschtraum. Der Fachbereich hat noch nicht erkannt, dass ein Konzept wie SOA ihm hilft, seine Prozesse rascher adaptieren zu können. Technisch ist die Brücke zwischen IT und Fachabteilung geschlagen, aber kommunikativ muss noch Überzeugungsarbeit geleistet werden.
Markus Hieronimus, IBM Softwaregroup: Wenn man SOA-Beiträge in Zeitschriften, Zeitungen liest oder so manchen Vortrag von Anbietern verfolgt, wundert mich das nicht: Es wird darüber zu abgehoben oder technisch berichtet. Mitarbeiter oder Manager aus einem Fachbereich wie dem Vertrieb beispielsweise bekommen den Eindruck, hier arbeitet die IT wieder an einem komplizierten technischen Kunstwerk. Das schreckt die Fachbereiche leider ab, die aber noch mehr als die IT von SOA profitieren würden.
Ivo Totev, Mitglied des erweiterten Vorstands der Software AG: WSDL, XML, UDDI, http, BPEL, Ochestrierung, Choreografie und so weiter - das ist die Begriffswelt, mit der die IT ihren Kunden - den Anwendern - SOA näher bringen will. Und ich glaube nicht, dass diese technischen Ausdrücke dazu geeignet sind, einen Mitarbeiter aus der Fachabteilung anzusprechen.
Jost: Richtig. Diese Sprache hat die IT in der Vergangenheit gepflegt und den Mythos aufgebaut: "Die IT, das sind die Leute aus dem Elfenbeinturm." Doch das kann sich die IT nicht länger leisten, denn der Mythos ist entzaubert: Die Informatik im Unternehmen kämpft um ihre Existenzberechtigung. Und daher ist sie gut beraten, ihre Begriffswelt an die Sprache der Anwender anzupassen.
Wolfgang Weigend, Teamleader Systems Engineering, Bea Systems: Wir sehen auch, das die Fachabteilungen noch nicht in dem erforderlichen Maße auf die IT zugehen. Doch sie haben Druck, ihre Aufgaben zu erledigen. Beispielsweise hat der Vertrieb unterschiedliche Kundensegmente zu betreuen, er soll Cross- und Upselling umsetzen und vielleicht auch noch kurzfristig ein neues Verkaufsbüro in Osteuropa aufmachen. Wenn dazu eine Änderung in seiner IT-Anwendungen erforderlich ist, muss er auch heute noch Formulare ausfüllen, Pflichtenhefte schreiben und Änderungen beantragen. Dieser formelle Akt ist IT von gestern, denn das dauert heute viel zu lange.
Karin Sondermann, BDM Platform Value Developer Platform & Strategy Group, Microsoft Deutschland GmbH: Viele Unternehmen haben mittlerweile erkannt, dass die Weiterentwicklung ihrer Waren, Produkte und Dienstleistungen allein nicht mehr ausreicht, um im Wettbewerb zu bestehen. Was zählt, sind Geschwindigkeit und Wandlungsfähigkeit. 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 Geschäfts-Chancen rechtzeitig erkennen und diese kreativ und innovativ umsetzen, um so dem Wettbewerb einen Tick voraus zu sein.
Bernard Tsai, Focus Solution Manager SOA bei T-Systems: Es geht ja noch weiter. Das Gros der Fachbereiche denkt überhaupt noch nicht in Geschäftsprozessen. Diese Menschen erreichen wir nur, wenn wir die bestehenden Sprachbarrieren überwinden. Hierfür benötigen wir ein gemeinsames Subset an Begriffen und Konzepten, die sowohl für die IT als auch für das Business verständlich sind. Ein wesentlicher Grund für Fachbereiche und das Management, sich mit dem Thema SOA auseinanderzusetzen, ist die Flexibilität, mit der einmal getätigte Entwicklungen erneut verwendet werden können.
?Flexibilität und Wiederverwendung sind verlockende Schlagworte - allein der Glaube daran fehlt, dass die IT diesmal die eierlegende Wollmilchsau liefern kann ...
Tsai: Das muss man natürlich erklären, was das fürs Business bedeutet. Und das kann man dem Management und den Fachbereichen, wie Herr Jost bereits sagte, anhand ihrer eigenen Tätigkeit sehr gut klar machen. Es lässt sich quasi eine Analogie zwischen einer SOA und einer flexiblen Business-Architektur herstellen.
?Können Sie das bitte genauer erläutern?
Tsai: Fachabteilungen fokussieren sich auf spezielle Tätigkeiten. Im Rahmen von Prozessen integrieren sie ihre Leistungen beispielsweise zu Produkten. Ändert sich die Produktpalette, so müsste im Prozessablauf nicht alles von Grund auf neu entwickelt werden. Ändert sich jetzt ein Ablauf oder ein Produkt, wird in der Regel nicht immer alles von Grund auf neu gemacht, sondern man kann auf Grundstrukturen zurückgreifen. Das ist das Thema Wiederverwendung. Es gibt also beispielsweise einen bestehenden Prozessablauf, der segmentiert wird in Teile, die unverändert bleiben, und Teile, die verändert werden müssen. Das ist die Idee von SOA, und das versteht auch der Fachbereich.
Sondermann: Eine große Herausforderung für die Realisierung einer SOA in Bezug auf IT ist das "richtige" Design von Services. Hier bedarf es praktischer Erfahrung und einer sorgfältigen Business-Analyse der geschäftlichen Fähigkeiten des Unternehmens unter Einbeziehung der Mitarbeiter, Geschäftspartner und Kunden wie auch der regulatorischen Rahmenbedingungen. Es existieren allerdings keine formalen Ansätze zur Modellierung von Services, wie es für die Datenmodellierung oder das objektorientierte Design der Fall ist.
Jost: Die Fachbereiche sind in den vergangenen Jahren von der IT nicht sonderlich verwöhnt worden. Wir haben zwar immer gepredigt, dass sich die Anwender über ihre Prozesse Gedanken machen sollen, und das haben sie dann auch zum Teil brav gemacht und dokumentiert. Am Ende hat die IT dann doch etwas anderes geliefert, weil sie bislang technisch und weniger betriebswirtschaftlich dachte.
Nils Meyer, Senior Consultant, Computer Associates: Das bedeutet, dass die IT-Systeme gar nicht das tun, was die Fachbereiche brauchen. Und die Namensgebung oder das, was man unter SOA versteht, ist etwas anderes in den Augen der Fachbereiche als das, was ein IT-Architekt darunter versteht.
Alexander Schmid, Direktor Produktentwicklung, enteo Software GmbH: Wir müssen noch viel tun, um die IT und das Business zusammenzubringen. Dazu gehört es für beide Gruppen, strategischer zu denken. Das bedeutet, sich Gedanken zu machen, wie sich Servicementalität und Serviceorientiertheit in der Denkweise eines Unternehmens verankern lassen. Dazu gehört insbesondere, dass wir lernen, einen Service nicht mehr als ein IT-Stück zu verstehen, sondern vielmehr als eine Dienstleistung, die vom gesamten Unternehmen erbracht wird, ob das jetzt ein Kredit-Check ist, die Auslieferung eines Produkts oder der Vorgang von der Bestellung einer Ware bis hin zur Bezahlung.
?ERP-Systeme haben eine Lebensdauer von 16 Jahren. Schlecht geht es den meisten Betrieben trotz dieser alten Systeme nicht gerade. Wer braucht die Flexibilität wirklich? Sind es nicht eigentlich die Hersteller, die ihre Produkte damit wartbarer gestalten und versuchen, Entwicklungskosten zu senken?
Jost: Unternehmen wie Oracle oder SAP tätigen die großen Investitionen nicht, weil sie Spaß daran haben. Die Kunden setzen die Anbieter unter Druck, weil sie mit den bestehenden Systemen die nötigen Anpassungen nur mit sehr großem Aufwand hinbekommen. Das Gros der ERP-Systeme wird maximal zu 60 Prozent genutzt, schlicht und ergreifend aus dem Grund, weil sich damit die Prozessveränderungen nicht mehr in der Software nachvollziehen lassen. Und die Anwender behelfen sich mit Excel-Tabellen oder anderen abenteuerlichen Lösungen, die sie um die Kernsysteme herumgestrickt haben.
Weigend: Die Flexibilität liegt also auch außen herum. Die Fachbereiche schaffen sich weiter fleißig Insellösungen an, und das führt zu massiven Integrationsproblemen
Hieronimus: Jedes Unternehmen braucht Flexibilität. Sie ist die Grundlage für Innovation, um Prozesse zu optimieren und neue Geschäftsmodelle zu kreieren. Schwierig ist es jedoch, den Anspruch an Flexibilität, den sowohl das Business als auch die IT haben, miteinander zu synchronisieren. Der Fachbereich hätte gerne eine bessere IT-Unterstützung für seine Prozesse, und die IT hätte gerne eine flexiblere Architektur, die genau das ermöglicht. Eine SOA kann beides unterstützen. Die Frage ist nun, wer diese fünf- bis zehnjährige Reise zu einer SOA erklärt und umsetzt.
?Bei IT-Projekten geht es auch immer um schnelle Erfolge, also Quick Wins. Wer bewilligt das Geld für einen Fünfjahreshorizont?
Totev: Bei dieser ganzen SOA-Diskussion gibt es ein ganz grundlegendes Problem: SOA ist so breit, wir haben so viele unterschiedliche Themen, dass wir über völlig unterschiedliche Ebenen hinweg reden. Man will ganz neue Architekturen aufbauen, auf eine ganz neue Art und Weise. Wenn wir so weiterdiskutieren, wird SOA scheitern und zum Buzzword verkommen. Viele Ansätze aus dem SOA-Ideen-Baukasten sind längst erprobt und reif für den Einsatz. Ich plädiere daher dafür, SOA nach Teildisziplinen aufzuteilen - sodass die Unternehmen und die Entscheider sich angesprochen fühlen und erkennen, dass SOA genau die Probleme löst, die ihnen unter den Nägeln brennen.
?Was verstehen Sie unter Disziplinen?
Totev: Das sind dringend anstehende Arbeiten, die erledigt werden müssen und ohnehin schon auf der Agenda des CIOs stehen. Etwa die Modernisierung von Legacy-Anwendungen, der Austausch der alten grünen Bildschirme (Green Screens), die Verbesserung der Integrationsfähigkeit einer bestehenden Lösung oder der Wunsch, die Leistungsfähigkeit von Prozessen messen zu können. Stichwort: Business oder Process Performance Management. Das wären bereits drei unterschiedliche Ansätze, über die wir reden und die sich alle dazu eignen, sie SOA-mäßig anzugehen und damit zukunftssicher zu machen. Für solche Projekte sind die Budgets vorhanden, und sie überfordern die Anwender nicht.
Jost: Diesen Ansatz kann ich nur unterstützen. Ich glaube auch, dass man differenzieren sollte. Wichtig ist eine Art Landkarte, also: Wie sieht meine Roadmap aus?, aber dann muss man mit konkreten Anwendungsfeldern beginnen. Die Einführung einer SOA ist ein Prozess, und wenn ein ERP-Hersteller schon fünf Jahre dazu braucht, um seine Software umzustellen, dann kann man vom Kunden nicht verlangen, dass er das in zwei Jahren macht.
?Was wäre ein guter Einstieg in SOA. Wie könnten weitere Disziplinen aussehen?
Hieronimus: Auf der Reise zu einer SOA sehen wir, dass Unternehmen eine von sechs typischen Einstiegspunkten wählen. Einer ist beispielsweise der strategische Ansatz. Nachdem ein Gesamtbild des Unternehmens erstellt wurde, geht man daran, taktische Bereiche oder Fachbereiche herauszuarbeiten, bei denen man mit der Umsetzung beginnt. Eine andere Vorgehensweise ist der pragmatische, Bottom-up-Ansatz, wie ihn Herr Totev angesprochen hat. Kunden möchten beispielsweise Prozesse optimieren, einheitliche Informationen haben, IT Anwendungen in neuen Szenarien wiederverwenden, Anwendungen miteinander verbinden oder Menschen in und um ihr Unternehmen herum produktiver machen. Kurz und gut: sehr pragmatische Ziele, die sich mit Hilfe von Softwarekomponenten umsetzen lassen, die wiederum die Bestandteile einer SOA-Strategie sind. So baut sich langsam wie ein Puzzle eine SOA im Unternehmen auf.
Sondermann: Oftmals besitzen diese kurzfristig eine höhere Priorität als die Umstrukturierung der gesamten Infrastruktur. IT-Projekte, die neue Anwendungsfunktionalität bereitstellen, sollten aber gleichzeitig auch ein Stück Architekturfunktionalität realisieren, denn nur so verbinden sie Geschäftsnutzen mit Architekturnutzen im Sinne einer schrittweisen, evolutionären Migration. Der Nutzen einer SOA steigt erst mit dem Durchdringungsgrad im Unternehmen.
Totev: Es ist aus unserer Erfahrung sinnvoll, dass Unternehmen eine kleine Zahl von drei, vielleicht fünf Disziplinen definieren, also konkrete Ziele wie die gerade genannten. Wenn es deutlich mehr werden, dann wird es wieder unübersichtlich, und der Blick für das große Ganze geht verloren. Als einen wichtigen Auslöser sehen wir auch das Ziel, ein Master Data Management aufzubauen - also einheitliche Stammdaten zu schaffen.
Bernd Trops, SOA Architect bei Oracle:
Die Kategorisierung ist sicher sinnvoll, jedoch besteht die Gefahr, die Gesamtstrategie aus den Augen zu verlieren. Wie stellt man die Governance sicher und schafft es, dass SOA wirklich langfristig und nachhaltig funktioniert, wenn man sich lediglich auf taktische Projekte konzentriert?
Meyer: Egal in wie viele Disziplinen wir SOA unterteilen, ich würde mir auch wünschen, von diesem ganz strategischen Ansatz wegzukommen. Wir müssen alle zur Kenntnis nehmen, dass es einen Bottom-up- und einen Top-down-Ansatz für SOA-Projekte gibt. Die Wahrheit liegt irgendwo in der Mitte. Punkt, aus. Mit einem Blueprint oder Bebauungsplan für die nächsten zehn Jahre zu starten, das können wir gleich vergessen.
Tsai: Sie wollen die strategischen Aspekte weglassen?
Weigend: Aus unserer Sicht ist auch beides machbar, das machen wir unseren Kunden klar. Klein starten und das Ganze im Blick behalten.
Totev: Der Bottom-up-Ansatz ist in der Praxis viel stärker vertreten, als wir ihn hier bisher diskutiert haben. SOA muss leichtgewichtig werden. Nur dann haben wir die Chance, dass sie wirklich abhebt und nicht irgendwie in einer großen Strategiediskussion untergeht.
Hieronimus: Allein schon aus Sicht der knappen IT-Budgets werden viele Projekte bottom-up angegangen oder, besser gesagt, aufgrund eines konkreten, nutzenbringenden Geschäftvorfalls realisiert. Das Risiko, ein groß angelegtes SOA-Projekt lehrbuchgerecht umzusetzen, geht in der Praxis kaum jemand ein. Wichtig ist dabei, dass das Thema ,SOA Governance’ nicht auf der Strecke bleibt.
Jost: Das ist auch eine Frage, wie Projekte geschnitten werden, also in welchen Teilschritten sie realisiert und aus welchen Segmenten sie zusammengesetzt sind. Aber irgendwie muss es den ersten Schuss geben, und der erste Schuss ist immer der, der das höchste Risiko trägt und am meisten Geld kostet.
Weigend: Aber auch beim ersten Schritt sollte darauf geachtet werden, den Governance-Prozess mit anzustoßen und zu berücksichtigen, dass Rahmenvorgaben existieren, Methoden und Richtlinien, die SOA langfristig im Unternehmen etablieren. Dazu gehören auch technische Standards. Sicherlich werden Unternehmen dazu ein Repository nutzen, in dem Daten und Services beschrieben sind. Das gehört zum Handwerkszeug, das wir Hersteller und Berater mitbringen. Wenn es allerdings nicht gelingt, die Kollegen und Projektleiter in dem Unternehmen zu motivieren, überhaupt etwas damit zu machen, dann wird es natürlich nicht funktionieren. Das heißt, ich muss die Motivation von oben schaffen und darf die Menschen nicht abstrafen, wenn sie Dinge ausprobieren, die eigentlich im größeren Rahmen besser formuliert wurden.
?Also ist bei SOA mal wieder das Top-Management gefragt, das unbedingt dahinterstehen muss ...
Hieronimus: Bei EAI hatten wir eine ähnliche Ausgangsposition. Das Konzept war bestechend, aber es wurde kaum konsequent umgesetzt, da das einzelne Projekt nicht für das große Ganze aufkommen wollte. Ich denke das Thema SOA ist so wichtig, dass es von den verantwortlichen Unternehmenslenkern unterstützt werden muss. Beispielsweise muss man sich über die Verankerung einer SOA Governance Gedanken machen und auch, wie eine notwendige Anfangsinvestition, von der das ganze Unternehmen profitieren wird, zu leisten ist.
Schmid: Ich habe den Eindruck, dass wir aus der IT-SOA auf Teufel komm raus verkaufen wollen. IT kann aber nicht der Treiber von SOA sein, die Forderung nach einer derartigen Lösung muss vom Business kommen. Letztendlich refinanziert sich SOA durch die Einsparungen und Verbesserungen, die sich bei den Prozessen ergeben. Wenn das Business aber weiterhin in Funktionssilos agiert - also fein säuberlich unterteilt in Funktionsbereiche - und nicht deutlich wird, dass die Projekte über Bereichsgrenzen hinausgehen, wird SOA scheitern. SOA kann maximal eine Antwort auf eine Business-Frage sein, aber das Konzept allein stiftet keinen Mehrwert.
Sondermann: Bei SOA handelt es sich ganz klar um eine strategische Ausrichtung des Unternehmens, die wesentliche Teile der IT betrifft, und nicht um eine punktuelle Maßnahme im Unternehmen. Somit bedarf es bei der Einführung von SOA der intensiven Beteiligung und der Zustimmung des Managements.
?Also wer treibt SOA nun: die IT oder das Business?
Jost: Gegenfrage: Wenn man jetzt mal die Realität sieht: Seit wann diskutieren wir über Kunden-Management? Seitdem es CRM-Systeme gibt. Seit wann diskutieren wir in dem Maße über das Thema Flexibilität? Seitdem das Thema SOA existiert. Die IT startet häufig den initialen Prozess, weil beispielsweise die Technik einen neuen Stand erreicht hat und mehr Möglichkeiten bietet. In der Folge läuft der Prozess dann allerdings falsch weiter, weil die IT die Fachbereiche viel zu spät mit ins Boot holt. Bis dahin haben die Unternehmen bereits viel Geld in die neuen Tools und Plattformen investiert und fangen an, nach dem ROI zu fragen. Erst dann beginnt die IT, das Thema zu verkaufen. Der CPO fehlt bis heute.
Hieronimus: Für SOA-Initiativen, ob klein gestartet oder im großen Stil, muss es einen Businessplan geben. Den CEO interessiert nämlich nur eines: Umsatz und Gewinn. Dieser Businessplan kann aber nur durch IT gemeinsam mit den Fachbereichen erstellt werden und stellt so den langfristigen Aufbau einer SOA durch individuelle, sich selbst finanzierende Projekte sicher. Für die IT und deren Leiter ist es daher notwendig, noch stärker in die betriebswirtschaftliche Denkweise einzutauchen und quasi ein Prozessberater der Fachbereiche zu werden. Ich bin daher auch überzeugt, dass sich ein CIO und IT-Bereich in einen CPO (Chief Process Officers) wandeln wird. Es muss einen CPO geben, der sagt: "Prozessmanagement ist mein Thema".
?Die Prozess-Manager-Diskussion ist alt. Die gab es schon bei CRM und SCM. Doch die Realität sieht anders aus. Welcher Fürst gibt schon gerne sein Fürstentum auf?
Trops: Das wäre eine Aufgabe, in die sich ein CIO quasi hineinwandeln muss. Der CIO ist ja klassisch fast immer technisch ausgeprägt, er war Systemprogrammierer oder EDV-Abteilungsleiter. Dann wurde aus einer deutschen Aufgabenbezeichnung eine englische, und dann hieß er CIO. Er hat zu wenig betriebswirtschaftliches Denken.
?Die Schwierigkeit scheint zu sein, dass es diese Profile, die Sie da beschreiben, kaum gibt, also dass es die Leute kaum gibt ...
Jost: Die muss man ausbilden.
Trops: Das ist ein wichtiger Punkt. Ich glaube auch, dass das kein Know-how-Problem ist und auch kein Technologieproblem. Solange es Bereichsfürsten-Blöcke in Unternehmen gibt und man sie beim Bau einer SOA ignoriert, wird es scheitern. Die Bereichsfürsten werden alles daran setzen, ihre Machtmonopole zu halten. Eine Lösung ist, die Komponenten von SOA so zu schneiden, dass sie funktioniert, auch wenn man dann nur einen Teil des Potenzials ausschöpft.
Meyer: Natürlich brauchen wir diesen CPO - irgendwann. In diese Richtung bewegen sich viele CIOs mittlerweile auch, aber der Weg ist noch lang.
?Wie viele Unternehmen sind denn momentan auf dem Weg zu SOA?
Jost: Die Unternehmen befassen sich damit, gehen auf Konferenzen, machen Workshops. Aber wie immer: Die Umsetzung hinkt den Schlagzeilen und Marketingbroschüren der Hersteller hinterher.
?Der Beweis, dass es funktioniert, fehlt also. Ein Professor aus der Schweiz hat gesagt: Das Problem ist, dass die Fachabteilung die Schnauze voll hat von den Versprechungen der IT ...
Jost: Die Frage, ob SOA funktioniert oder nicht, ist schon eine Gretchenfrage. Obwohl ich noch keine vollständige Service-orientierte Architektur in einer Anwendung gesehen habe, glaube ich fest an das Thema. Wenn man das Problem der Prozessflexibilität in Anwendungssystemen lösen möchte, gibt es zu SOA keine Alternative.
Hieronimus: Natürlich sind noch einige
Fragen der IT zu beantworten, wie Laufzeit von Service, Performance, Verfolgungsstabilität und Sicherheit. Aber wir können heute, und tun dies auch schon erfolgreich in Hunderten von Kundensituationen, mehr, als die meisten Fachbereiche ahnen. Die Technik ist derzeit nicht der limitierende Faktor, sondern die Veränderungsgeschwindigkeit und -willigkeit sowie das fehlende Wissen und Vorstellungsvermögen über die Fähigkeiten von SOA.
Sondermann: Es gibt bereits Beweise im Markt, dass SOA funktioniert. So können sich die Resultate der SOA bei Siemens ITO sehen lassen. Durch die Wiederverwertbarkeit von Diensten reduzierte sich der Entwicklungsaufwand um 50 Prozent, die Aufwendungen für Schnittstellenpflege und für die Anpassung verringerten sich jeweils um 25 Prozent. 35000 Endkunden nutzen die Integrationsplattform und erzeugen dabei 64000 Anfragen pro Monat. Auch die Bereitstellungszeit für neue Dienste gegenüber dem Kunden konnte von 30 bis 45 auf wenige Minuten reduziert werden.
Meine Dame, meine Herren, wir danken Ihnen für das Gespräch.