4 Gründe, warum Sie nicht über eine service-orientierte Architektur nachdenken müssen

Keine Flexibilität der IT notwendig

Im Gegensatz zur Masse der Organisationen steht Ihr Unternehmen nicht unter dem Druck von zunehmender Komplexität, Konkurrenz oder Unsicherheit. "Shareholder Value" (bzw. die konstante Steigerung desselben) ist entweder überhaupt kein Thema oder immer schon in der Geschäftsstrategie pro-aktiv abgebildet gewesen. Überraschende Forderungen der Benutzer nach noch mehr Informationen oder neuen Funktionalitäten in bestehenden Applikationen existieren nicht oder sind bereits in einem langfristigen IT Masterplan (der sich im übrigen auch nicht ändert) alle vorweggenommen und eingeplant.

Kein Kostendruck in der IT

Als Manager sehen Sie die klassischen Effizienzmaße in der IT (bspw. Entwicklungskosten, Wartungskosten) entspannt, da Sie entweder bereits (bspw. durch nachgewiesenes Benchmarking) world-class Performanz demonstriert haben oder auch gegenüber der Geschäftsführung keine Schwierigkeiten haben, höhere Lizenzkosten oder Personalkosten in einem höheren IT Budget unterzubringen. Oder aber Sie kennen genügend bisher noch gar nicht angezapfte Quellen von Produktivitätsgewinn in der IT Abteilung, sodass es diesbezüglich auf absehbare Zeit keiner besonderen Anstrengung bedarf, kontinuierliche Verbesserungsprozesse (KVPs) mitzumachen.

Kein Integrationsproblem

Forderungen nach abteilungs- oder funktionsübergreifenden Prozessen und Aufgaben (z.B. Basel II oder Geschäftsprozessmanagement) sind leicht in die bestehende Applikationslandschaft integrierbar; Fach- und Ablauflogik sind nicht tief in (möglicherweise sehr altem) Programmcode der Anwendungen definiert abgebildet, sondern ohne weiteres zugänglich, extrahierbar und wieder verwendbar. In Ihrer Architektur haben Sie auch das zugegebenermaßen komplexe Problem der Enteprise Application Integration (EAI) von Formaten, Daten und (Stichwort: Semantisches Web) auch Bedeutungen konzeptionell und technisch bereits gelöst und können Ihren (internen und externen) Kunden den berühmten Single View auf die notwendigen Informationen zur Verfügung stellen.

IHRE HERAUSFORDERUNG

In dem Maße, in dem die IT die hier angeführten Eigenschaften bereits besitzt, macht es tatsächlich keinen Sinn, über die Einführung einer service-orientierten Architektur nachzudenken; im Gegenteil: Es würde uns sehr interessieren, ihr offensichtlich alternatives Konzept zu einer SOA kennen zu lernen - durchaus im Sinne eines "Lernen von den Besten".

In allen anderen Fällen aber könnte es sich auszahlen, darüber nachzudenken, ob für ihr Unternehmen "SOA" die Antwort auf die oben angedeuteten Fragestellungen sein könnte.

Was ist eine service-orientierte Architektur (SOA)?

Analog zum klassischen Begriff der "Architektur" von Gebäuden unterscheidet man den gedanklichen (abstrakten) architektonischen Bauplan (des Bauwerks bzw. der IT Landschaft) von der tatsächlichen Realisierung als Gebäude bzw. der Implementierung in der IT. Auch eine SOA braucht beide Komponenten, um zu "funktionieren".

SOA als Bauplan. Das gedankliche Konzept einer service-orientierten Architektur überwindet den Graben zwischen Fachabteilung und IT Spezialisten. Es wird eine Abstraktion eingeführt, die zwischen den notwendigen Funktionen und Fähigkeiten, die die Fachabteilungen tatsächlich benötigen, und ihrer technischen Implementierung vermittelt: den so genannten "Services". Diese Services werden aus Sicht der Fachabteilung definiert - ganz unabhängig davon, wie und wo sie technisch in Applikationen realisiert werden. Diese Unabhängigkeit wird oft in den drei wichtigen Prinzipien:

• lose Kopplung (der einzelnen Services untereinander),
• Ortsunabhängigkeit (insbesondere davon, wo und auf welcher Maschine ein Service tatsächlich abläuft),
• Protokollunabhängigkeit (keine proprietären Applikationsstandards, sondern offene Standards für die Beschreibung von Services, z.B. XML oder WSDL für Web Services)

zusammen gefasst.

SOA als Implementierung. Da aber auch eine SOA letztlich nicht ohne (IT-) Technik abläuft, findet man bei typischen SOA Implementierungen noch zwei weitere Bausteine:

• Enterprise Service Bus (ESB) verbindet (im Sinne der Kommunikation) die Services, Benutzer und Applikationen.
• Service Repository: Das Verzeichnis, in dem die verfügbaren Services und ihre Eigenschaften näher beschrieben sind.

Rufen Sie uns einfach an:
Christoph F. Strnadl
Chief IT Architect
Software AG Österreich
Tel: +43/1/32950-114
www.softwareag.com/austria