Lässt sich eine Botschaft von der diesjährigen Konferenzmesse "EAI Forum" in Karlsruhe mitnehmen, so die, dass künftig das Konzept eines fachlichen Softwareservice die Entwicklung und Integration von Anwendungen und Komponenten prägen wird. Die gute Nachricht an die rund 1000 Teilnehmer war dabei, dass viele Prinzipien der Serviceorientierung nicht neu sind. Das Ziel einer losen Kopplung von Diensten steht schon lange im Raum, ebenso das Interesse an gemeinsamen Kommunikationsprotokollen und der Wiederverwendung von Softwarebausteinen. Diese Szenarien wurden schon mit der objektorientierten und komponentenbasierenden Softwareentwicklung zum Thema. Ebenso liegen heute erste Erfahrungen mit Web-Services vor, die für die meisten Experten als die wichtigste Implementierungstechnik für Service-orientierte Architekturen (SOAs) gelten, und auch das Interesse an agileren Geschäftsprozessen existiert seit längerem.
Von Komponenten zu Diensten
Kein Wunder daher, dass nicht nur Anbieter von Integrationssoftware ihre Produkte zusehends als Infrastruktur für Services vermarkten, sondern auch Anwender Projekte nun pauschal als SOA bezeichnen.
Andererseits verheißt die Dienstorientierung einen erheblichen Vorteil gegenüber bisherigen Komponententechniken. So setzen Letztere bestimmte Plattformen und Laufzeitumgebungen, homogene Anwendungen und proprietäre Kommunikationsprotokolle voraus, was einer agilen und möglichst langlebigen Organisation entgegenwirkt. Services hingegen sind als eine weitere Abstraktionsebene über den Komponenten-Frameworks zu sehen. Sie sind autonom, können sich aber auch aus anderen Diensten zusammensetzen und hängen nicht von einer bestimmten Implementierung ab. Ihre Schnittstellen sind über ein Schema beschrieben, und der kompatible Nachrichtenaustausch wird mit Hilfe von Policies gewährleistet. Mit Web-Services stehen interoperable und leichter zu beherrschende Kommunikationsstandards bereit, die von der Softwareindustrie breit unterstützt werden.
Zugleich verschiebt sich mit dem SOA-Konzept der Blick auf die Anwendungen und Prozesse von der IT zu den fachlichen Anforderungen. Das richtige Design eines wiederverwendbaren Service und seine "Granularität" werden zur zentralen Herausforderung. Dabei ist zu berücksichtigen, dass sich die Dienste fortan in immer komplexere und sich ändernde Prozesse einbinden lassen und interne wie externe Anwendungen mit neuem Verhalten versehen sollen. Zwar können Unternehmen hierfür auf methodische Grundlagen zurückgreifen, die schon beim Entwurf von Objekten und Komponenten halfen. Vor allem aber werden ein großes Prozesswissen und Best Practices über die Branche und Unternehmensorganisation erforderlich sein. Ebenso müssen Anwender Metainformationen in einer Registry bereitstellen, in der Angaben über den Serviceeigner, Zugriffsrechte und andere Aspekte der Servicequalität definiert sind. Die Diskussion darüber, wie sich eine SOA weiterentwickeln und vor allem warten lässt, hat erst begonnen.
Das Business verstehen lernen
Um Services zu definieren, die für beide Parteien verständlich sind, benötigen IT und Business künftig eine gemeinsame Sprache, sagte Christof Sprenger, Architekturberater bei Microsoft Deutschland. Dazu arbeitet Microsoft an einer "Business Capability Map" für seine Berater und Partner. Mit ihr lassen sich zunächst Kernkompetenzen eines Unternehmens identifizieren, um dann zu entscheiden, wie man diese serviceorientiert über Geschäftsprozesse und mit Hilfe entsprechender XML-Technik verbinden könnte.
Einen ähnlichen, schon seit Jahren entwickelten Ansatz stellte Kristof Kloeckner, Vice President Software Group Architecture and On Demand Software Development bei der IBM, mit dem "Component Business Model" vor. Dies sei praktisch für jede Industrie verfügbar und zerlege Unternehmen in einzelne Komponenten oder Prozesse, damit klarer werde, wie sie im Einzelnen und untereinander funktionieren. Ziel ist es, Möglichkeiten für Innovationen und Verbesserungen zu identifizieren. Die Bausteine lassen sich nach bestimmten Standards entwerfen, um sie austauschbar zu machen, und sie können gegebenenfalls auch per Outsourcing verwaltet werden. Experten wie Lothar Wieske, Systemarchitekt bei Zühlke Engineering, empfehlen zudem, sich mit Patterns zu beschäftigen, um eine SOA zu strukturieren. Insbesondere die von Frank Buschmann definierten "Architectural Patterns" könnten hierbei hilfreich sein. Ebenso wären Patterns, die die Unternehmensorganisation abbilden, sinnvoll.
Verwirrende Produktvielfalt
Währenddessen positionieren Hersteller von Integrationstechnik, aber auch Standardsoftwarehersteller wie SAP oder Siebel ihre Produkte nun als Teil oder gar Herzstück einer SOA. So verwiesen die Aussteller in erster Linie auf die Features ihrer immer komplexeren Integrationsprodukte zur Prozessmodellierung und -steuerung, mit denen sich auch eine Messaging-Infrastruktur für Services aufbauen lässt, die derzeit als "Enterprise Service Bus" beworben wird. Doch allen Beteiligten wird langsam klar, dass SOA eine hochkomplexe und vor allem beratungsintensive Angelegenheit ist. Dementsprechend waren in Karlsruhe auch keine Patentrezepte zu erwarten, sondern eher Pragmatismus. EAI-Experten wie Wolfgang Martin rieten den Anwesenden, nicht den großen Wurf zu versuchen, sondern in überschaubaren Projekten mit klarem Nutzwert einen serviceorientierten Ansatz auszuprobieren - etwas, was heute bereits in vielen Unternehmen gängige Praxis ist.