CW: Die großen Hersteller von Infrastruktursoftware, allen voran IBM, Oracle und Microsoft, bauen ihr Angebot zu so genannten Superplattformen aus. Fehlende Technik kaufen sie einfach hinzu. Was bleibt noch übrig für die kleinen Softwarehäuser?
Howard: Sobald sich eine Technik zur Commodity entwickelt hat, wird sie oft Teil einer Superplattform. Ein Beispiel dafür ist Virtualisierung als Komponente von Server-Plattformen. Weniger wahrscheinlich ist diese Entwicklung im Bereich Sicherheit. Es wird immer einen Bedarf an spezialisierten Herstellern geben, die Sicherheitslöcher stopfen können. Die Hacker-Community ist sehr aktiv. Der Trend geht aber eindeutig dahin, immer mehr Komponenten in eine Plattform zu integrieren.
CW: Welche Folgen hat die Entwicklung für Anwender?
Howard: Vielen CIOs bereitet die damit verbundene drohende Abhängigkeit Sorgen. Sie setzen in der Regel mehrere unterschiedliche Plattformen ein. Einen Hersteller wie Oracle oder Microsoft für sämtliche Anforderungen wollen sie nicht. Vielmehr geht es den Unternehmen darum, verschiedene Techniken zu nutzen und miteinander zu kombinieren. Je mehr diese Techniken aber in die großen Plattformen integriert werden, desto schwieriger ist es für IT-Verantwortliche, sich die geeigneten Komponenten herauszupicken und mit anderen Systemen zu verbinden.
CW: Wird eine Best-of-Breed-Strategie bei der Softwareauswahl eines Tages nicht mehr möglich sein?
Howard: Die Bedingungen dafür verschlechtern sich, wenn einzelne Funktionen tief im Software-Stack eines Anbieters integriert sind. Etliche große Unternehmen nutzen etwa einen IBM-WebSphere-, einen Microsoft- und einen SAP-Stack. Zwischen diesen Blöcken gibt es nur einen geringen Grad an Integration, mit Ausnahme der Stellen, die die Hersteller explizit dafür öffnen.
CW: Also geht die Konsolidierung im Softwaremarkt zu Lasten der Anwender?
Howard: Für große Organisationen trifft das zu. Kleine oder mittlere Unternehmen können von einem integrierten Angebot auch profitieren.
CW: Ein Beispiel für einen Superplattform-Anbieter ist Oracle, das für 8,5 Milliarden Dollar Bea Systems übernimmt. Welche Auswirkungen sehen Sie für Bea-Kunden?
Howard: Der Merger reduziert den Wettbewerb im Markt für Softwareplattformen. Wir haben viele Kunden, die mit Bea sehr zufrieden sind, Oracle aber kritisch gegenüberstehen. Wenn Bea-Produkte im Oracle-Portfolio aufgehen, dürfte das für einige Anwender Probleme bringen.
CW: Bea besitzt einen kompletten Middleware-Stack. Was bedeutet der Deal für Oracles eigene Middleware Fusion?
Howard: Oracle hat eine lange Tradition von großartigen Ideen, die nie umgesetzt wurden. Das Versprechen von Fusion, die unterschiedlichen Anwendungen im Portfolio zu integrieren, steht bislang nur auf dem Papier. Mit Bea besitzt Oracle plötzlich zwei sehr ähnliche Integrationstechniken. Dabei hat Bea besonders bei Kunden mit hohen Integrationsanforderungen einen besseren Stand. Meine Vermutung: Oracle hat Bea gekauft, weil klar wurde, dass Fusion nicht funktioniert.
CW: Sowohl Bea als auch Oracle setzen große Hoffnungen in den Markt für Service-orientierte Architekturen (SOA). Nach der anfänglichen Euphorie scheint sich eine gewisse Desillusionierung breitzumachen. Ist der SOA-Hype passé?
Howard: Eine neue Architektur einzuführen ist harte Arbeit und braucht viel Zeit. In typischen Projekten können drei bis fünf Jahre vergehen, bis eine gewisse Reife erreicht ist. Gleichzeitig sehen sich Unternehmen mit Quartalsberichtspflichten und jährlichen Planungszyklen konfrontiert. Das passt nicht zusammen und führt durchaus zu einer gewissen Desillusionierung. Ein anderes Problem liegt darin, dass viele glauben, eine SOA könne man von einem Hersteller kaufen. Man kann ein Architekturprinzip nicht von irgendjemand erwerben sondern muss es selbst gemäß den eigenen Bedürfnissen entwickeln. Die SOA-Anforderungen der Deutschen Bank unterscheiden sich stark von denen der Deutschen Post.
CW: Wie steht es mit dem Fachwissen in Sachen SOA?
Howard: Infrastrukturkomponenten für eine SOA sind extrem komplex. Sie werden oft nicht richtig verstanden und sind schlecht dokumentiert. Die Idee hinter SOA ist ja, komplexe Monolithen in Module aufzubrechen, die sich relativ einfach wieder zusammensetzen lassen. Die Erfahrung zeigt aber, dass sich Unternehmen schwertun, solche Gebilde auseinanderzureißen.
CW: Sie meinen nicht nur Anwendungen, sondern beispielsweise auch den Integrations-Stack einer Softwarearchitektur?
Howard: Richtig. Das trifft auf den Integrations-Stack ebenso zu wie auf das Datenmodell. Schon aus technischer Sicht kann das in einer Legacy-Umgebung Probleme bereiten. Hinzu kommen organisatorische Hürden. Die Mitarbeiter haben ihre Arbeit an diesen Monolithen ausgerichtet; zwischen IT- und Fachabteilungen bestehen feste Verbindungen, die sich nicht so leicht kappen lassen. Es gibt so etwas wie virtuelle Stacks in den Unternehmen, beispielsweise das Investment-Banking und die Privatkundenbetreuung in einer Bank. Das SOA-Konzept ersetzt diese vertikalen Einheiten durch einen horizontalen Ansatz, in dem Ressourcen in der gesamten Organisation genutzt werden sollen. Hier liegt die eigentliche Schwierigkeit. Die technischen Komponenten der SOA funktionieren.
CW: Steckt dahinter das altbekannte Alignment-Problem?
Howard: Ich möchte das Thema nicht überbetonen. Das Kernproblem liegt darin, dass Prozesse, Daten und Funktionen in Unternehmen nicht gemeinsam genutzt werden. Das hat viel mit Kultur zu tun.
CW: Gibt es keine technischen Hürden?
Howard: Die Techniker haben verstanden, worum es bei SOA geht. Sie haben sich schon mit Objektorientierung und Corba auseinandergesetzt und kennen deshalb das Entwicklungsmuster der Service-Orientierung. Dennoch hat die objektorientierte Programmierung niemals das große Ziel der Wiederverwendung von Komponenten erreicht. Ich fürchte, dass auch SOA keine Wiederverwendung bringen wird. Das hat mehrere Gründe, beispielsweise die mangelnde Transparenz von IT-Assets, fehlende Vereinbarungen für das Servicedesign und vieles mehr.
CW: Inwieweit tragen die Softwarehersteller zu den Problemen bei, wenn sie einfach bestehende Produkte mit einem SOA-Label versehen?
Howard: Das lässt sich mit dem Hype um Green IT vergleichen. Ergibt es Sinn, wenn ein Hersteller von Bandspeichern seine Geräte mit einem Green-IT-Label schmückt und von einer neuen Produktkategorie spricht? Ähnlich verhält es sich mit SOA. SAP will seine Anwendungsfunktionen künftig als Services verstanden wissen. Sind die Anwendungen deshalb SOA-kompatibel?
CW: Das behauptet SAP.
Howard: Die Frage ist doch, wie SOA-kompatibel ein Hersteller sein möchte. In der Theorie lässt sich jeder Service einer Anwendung mit beliebigen Diensten anderer Programme kombinieren. Man könnte also jede SAP-Anwendung in Services aufbrechen und diese mit anderen Diensten etwa von Oracle verbinden. An SAPs Stelle hätte ich daran kein Interesse.
Mehr zum Thema Service-orientierte Architekturen im SOA-Expertenrat der COMPUTERWOCHE. (wh)