»Die Modellierung der Geschäftsprozesse wird abheben«
»Die Modellierung der Geschäftsprozesse wird abheben« Tom Rosamilia, Chef der Websphere-Sparte bei IBM, diskutiert mit InformationWeek-Redakteur Werner Fritsch über SOA und Standards, seine Produkte, den Wettbewerb und die weitere Entwicklung.
Herr Rosamilia, die Marke Websphere steht bei IBM für »Application and Integration Middleware«. Was ist damit gemeint? Es geht um die Technologien, die zwischen dem Betriebssystem und der Anwendung liegen. Da ist zunächst einmal der Application Server, dann gibt es auf dieser Basis den Websphere Enterprise Service Bus, den Process Server, den Service Registry und Repository Server, einen Message Broker und viele weitere Produkte. Dazu gehören Java-Programme, aber auch CICS und MQ Series. Ein wesentliches Augenmerk liegt insgesamt auf serviceorientierten Architekturen.
Am Anfang hat man von einer serviceorientierten Architektur im Hinblick auf Software gesprochen. Inzwischen wird damit auch ein Managementkonzept bezeichnet oder eine innere Einstellung. Was verstehen Sie unter SOA? In erster Linie ist SOA für mich eine Herangehensweise. SOA ist kein Selbstzweck. Vielmehr geht es darum, dass der Kunde etwas Geschäftliches erreichen will. Und das kann er mit Hilfe einer SOA tun: SOA ist eine zugrundeliegende Architektur, die es ermöglicht, Veränderungen zu implementieren. Wir wollen mit unseren Technologien das SOA-Versprechen erfüllen und den Kunden helfen, ihr Geschäft auf eine solche Architektur zu gründen.
Was bedeutet das? Es ist wichtig, zu verstehen, dass es um lose Kopplung von Diensten geht. Denn bei enger Kopplung gibt es keine Wiederverwendung und keine Flexibilität. Ferner sollte ein Bus den Bezugspunkt bilden. Bei Punkt-zu-Punkt-Verbindungen sind der Skalierung Grenzen gesetzt und die Komplexität nimmt rasch zu. Besser ist es, Abläufe zu orchestrieren, um die Geschäftsprozesse neu zu organisieren. Dabei sind Standards für Web Services wichtig. Und ehe das alles in einer Laufzeitumgebung umgesetzt wird, sollte modelliert werden.
Ist für Sie bereits eine SOA erreicht, wenn die Software modular und auf Geschäftsprozesse bezogen ist, oder müssen die Web-Services-Standards gelten? Ich denke, dass es große Vorteile bietet, mit den Standard-Schnittstellen zu arbeiten und dadurch die Hersteller zu zwingen, diese Standards zu befolgen. Zum Beispiel implementieren wir und andere Anbieter in neueren Produkten für Geschäftsprozesse den Standard BPEL. Wir haben aber auch ältere Produkte für das Management von Geschäftsprozessen und auch die werden wir weiterführen, um unsere Kunden zufrieden zu stellen.
Ihr Corba-Broker oder Ihr proprietäres Messaging-Produkt MQ Series sind demnach durchaus für eine SOA geeignet? Mit dem Websphere Message Broker haben wir ein Produkt, das MQ Series und Corba unterstützt, aber auch die Web-Services-Standards, und eine ganze Reihe von Adaptern bietet. Außerdem ist diese Middleware hoch skalierbar und sehr performant. Es wird nicht vorausgesetzt, dass alles mit Web Services gemacht wird. Unser Websphere Enterprise Service Bus ist im Vergleich dazu leichtgewichtiger und konzentriert sich auf Standardfunktionalität auf Basis des Websphere Application Server. Der beruht auf Java und erbringt die Leistungen eines Transaktionsmonitors, bietet aber auch eine JMS-Implementierung für lose Kopplungen.
IBM unterstützt also SOA im engeren Sinn mit dem ESB und SOA im weiteren Sinn mit dem Message Broker. Gibt es Szenarien, in denen das eine Produkt besser geeignet ist als das andere? Wenn eine Umgebung auf Web Services beruht oder sich leicht so umformen lässt, dann passt der ESB gut. Wenn hingegen viele Backend-Systeme verbunden werden müssen, wird man nicht alle Schnittstellen in Web Services konvertieren wollen, und dann ist der Message Broker die bessere Wahl.
Die Leistungsfähigkeit und Reife der Web-Services-Standards steht durchaus in Zweifel, etwa im Hinblick auf hohe Anforderungen bei der Transaktionsverarbeitung. Ich denke, dass die Standards im Lauf der Zeit reifer werden. Zunächst kommt Java, dann der Applikationsserver, dann der ESB und der Broker und dann schließlich, für die Geschäftsprozesse, der Process Server. Viele unserer Kunden nutzen heute den ESB im Process Server, um ihre Applikationen auf Web-Services-Basis zu verbinden. Unseren Mainframe-Transaktionsmonitor CICS gibt es allerdings schon 35 Jahre und es wird ihn noch sehr lange geben. Aber es entstehen auch immer mehr Unternehmensanwendungen, die mit der Java Enterprise Edition gebaut und sehr robust sind.
Wird der Bedarf für traditionelle, proprietäre Integrationswerkzeuge im EAI-Sinn fortbestehen, wenn die Web-Services-Standards reifer werden? Viele IBM-Kunden haben ihre Prozesse mit MQ Workflow implementiert, mit unserer Flow Definition Language. Die werden ihre Abläufe viele weitere Jahre auf dieser Basis darstellen und erweitern. Denen zu sagen, sie sollen damit aufhören und alles in BPEL umwandeln, wäre in finanzieller Hinsicht kein guter Ratschlag. Sie können ihre Abläufe jedoch föderieren und BPEL in Aufrufen einbeziehen. EAI und SOA: das ist eine Evolution.
Kompatibilität und Interoperabilität sind für die Anwender wichtig. Denn sie benutzen meist nicht die Middleware eines einzigen Herstellers. Wie kann man die Integrationssoftware integrieren? Standards bieten eine Möglichkeit dazu. Sie liefern notwendige Bedingungen, aber noch keine hinreichenden. Wenn etwa zwei Applikationsserver JEE-zertifiziert sind, reicht das noch nicht, um Code unverändert von einem auf den anderen zu übertragen. Standards sind gut, garantieren aber nicht 100 Prozent. Sie erfordern immer noch Interpretationen und Implementierungen. Anders ist es mit der Interoperabilität. Man kann durchaus verschiedene Broker oder ESBs verbinden oder föderieren. Man muss nicht alles, was man hat, austauschen, um Websphere einführen zu können. Wir haben zum Beispiel viele Kunden, die SAP-Middleware verwenden, die aber Websphere einsetzen, wenn sie Software integrieren wollen.
Ist die SAP-Welt für IBMs Middleware nicht in Gefahr, weil SAP alles liefern möchte? Tatsache ist, dass viele Unternehmen SAP-Anwendungen mit Websphere integrieren, mehr als 1000 sind es weltweit. Fast alle unserer Kunden haben auch andere Technologien als die von SAP im Einsatz. Wir haben rund 1500 Konnektoren und Adapter. Die, die wir am meisten verkaufen, sind die für SAP.
Aber Websphere wird nicht mehr eingesetzt, um SAP-Applikationen darauf ablaufen zu lassen, oder? Dafür hat SAP eigene Middleware geschrieben, ja. Wir haben aber auch Kunden, die alles auf den Websphere Application Server genommen haben.
Wie sieht es in Oracle-Umgebungen aus? Wir arbeiten im Hinblick auf die Software von Peoplesoft, JD Edwards und Siebel weiterhin zusammen, sodass diese Anwendungen mit Websphere und DB2 laufen können. Die Kunden haben das verlangt, und Oracle hat das öffentlich zugesichert. Bei den ursprünglichen E-Business-Applikationen von Oracle war das hingegen nie der Fall. Wir verkaufen aber auch viele Oracle-Adapter. Es gibt sogar Kunden, die mit unseren Adaptern Oracle- und Peoplesoft-Applikationen verbinden.
Und in einer Microsoft-Welt, gibt es da auch Platz für Middleware von IBM? Ja, absolut. Interoperabilität mit .Net ist eine wichtige Fähigkeit, die wir bereitstellen. Wir sagen: Wenn beim Anwender etwas da ist, dann lass uns das in die Lösung einbeziehen statt das auszutauschen, ob das nun CICS- oder .Net-Anwendungen sind. Eine Möglichkeit ist, die vorhandenen Funktionen als Web Services zu verpacken und in dieser Form in neuen Anwendungen und Geschäftsabläufen zu nutzen. Die Dienste können einander im Rahmen der Orchestrierung durch unsere Middleware aufrufen.
Oracle hat viel zugekauft, SAP hat eine große Kundenbasis. Diese beiden, ebenfalls auf Java fokussierten Hersteller werden versuchen, IBM bei ihrer Stammkundschaft heraus- oder zumindest zurückzudrängen. Jeder Hersteller geht von seinen Stärken aus und versucht dann, mehr zu machen. So stehen wir im Wettbewerb. Bei Standards arbeiten wir zusammen. Wir unterscheiden uns aber in der Art und Weise, wie wir sie implementieren. Ich möchte den Kunden helfen, sich die Wertschöpfungskette hinaufzubewegen: zum ESB, zu unserem Process Server und zu branchenspezifischen Lösungen.
Bei einem Application Server oder einem Enterprise Service Bus orientierten sich alle Hersteller an den Standards. Aber alle fügen etwas hinzu, weil der Standard angeblich nicht ausreicht. Die Hersteller sagen, sie verbessern etwas. Für die Anwender bedeutet das jedoch oft, abhängig zu werden. Aber wir bringen die Sachen mit den Standards wieder in Einklang, wenn sie reifer werden. So ist das zum Beispiel bei Java gewesen.
Das wäre jedenfalls zu wünschen. Was sind Ihre Pläne mit der Websphere-Produktlinie in diesem Jahr und in der absehbaren Zukunft? Das wichtigste Thema für die absehbare Zeit ist BPM, Business Process Management. Die Orchestrierung erlaubt es, Services verschiedener Herkunft zu kombinieren, so dass die Anwender rasch neue Fähigkeiten nutzen können und nicht Jahre darauf warten müssen. Viele Anwender stehen damit noch am Anfang. Aber ich denke, die Modellierung der Geschäftsprozesse wird abheben. Denn dadurch können Business- und IT-Leute miteinander sprechen. Mit Java oder BPEL geht das nicht: Da verliert man viele Leute aus den Fachbereichen. Das sind aber genau diejenigen, die ihre Geschäftsprozesse kennen und wissen, was die Software tun soll. Sie sollen die Geschäftsprozesse modellieren. Danach können sich IT-Leute darum kümmern, das umzusetzen.
Müssen das die Anwender bloß noch tun, oder muss IBM da noch viel in Forschung und Entwicklung investieren? Man kann heute schon viel machen, aber es gibt immer mehr, das man tun kann. Viele Anwender fangen mit der Modellierung an, ändern den Geschäftsprozess und überwachen ihn dann. Ein anderer Weg zu BPM ist BAM, Business Activity Monitoring. Da fängt man statt mit der Modellierung damit an, bestehende Prozesse zu überwachen, und schaut dann, was fehlt. Letztlich geht es um eine kontinuierliche Verbesserung der Geschäftsprozesse.
