SOA MANAGEMENT –DER UNBEACHTETE ASPEKTDER ARCHITEKTUR

die Gesamt-IT und die Abhängigkeiten dereinzelnen Komponenten untereinander.

Eine Aussage über durch auftretendeFehler betroffene Geschäftsprozesse istnicht möglich. Es gibt keine Verknüpfungzu den implementierten Prozessen. Ver-stärkt wird diese Problematik, wenn wirvon mehrschichtigen Architekturen hin zueiner Serviceorientierten Architektur gehen.Durch Veröffentlichung des Services ineinem Unternehmensregister ist noch nichteinmal die Zahl derjenigen, die den Servicebenutzen können vorhersehbar.

Neue Aufgabender IT-GovernanceDie Aufgaben einer IT-Governance sindnicht nur durch den Einzug von Service-orientierten Architekturen gewachsen.

IT-Governance ist strategischer, verfolgtheute Ziele wie:

■ Strategic Alignment: Ist die IT an denUnternehmenszielen und –prozessenausgerichtet?

■ Ressourcen Management: für nachhal-tigen und verantwortungsvollen Ein-satz von IT- Resourcen,

■ Risk Management: Erkennen, beurtei-len und managen von IT Risiken

■ Performance Measurement: Messungder Performanz der IT-Prozesse undServices

■ Value Delivery: die Bewertung desWertbeitrags der IT für das Gesamt-unternehmen

Zum Erreichen dieser Ziele bedarf es eineneue Sichtweise auf die IT, die zusätzlichzur Hard- und Softwaresicht die Geschäft-prozesse und sogar inhaltliche Kriterien derProzesse mit einschließt.

Die Serviceorientierte Architektur hat ihre Feuerprobe in der Praxis bestanden.Jetzt gilt es diese Architekturen im laufenden Betrieb zu verwalten. Die steigendeAnforderungen an ein IT-Governance, der wachsende Bezug der Geschäftsprozes-se des Unternehmens auf die IT, aber auch einfach die technische Herausfor-derung der Verteilung eines einzelnen Geschäftsprozesses auf unterschiedlicheSysteme, stellen Anforderungen an ein IT-Management, die traditionelle Systemenicht leisten können. Neue SOA Management Tools bieten Ergänzungen zu her-kömmlichen Lösungen und eröffnen neue Möglichkeiten.

Eric Schaumlöffel (E-Mail:Eric.Schaumloeffel@progress.com) istSenior Technologie Consultant in derEnterprise Infrastructure Division,einem Geschäftsbereich der ProgressSoftware GmbH.

Überwachung der Hardware, des Netz-werks und dem Ressourcenverbrauch einerAnwendung, der Middleware oder derDatenbanken. Die jeweilige Anwendungliefert zusätzlich noch Reports.

Diese Art und Weise der Überwachunggenügt jedoch nicht, wenn wir keine monoly-tische Anwendungen mehr haben. Ein tradi-tionelles IT Managementssystem würde beieiner verteilten Anwendung wie in Abbildung1 gezeigt im Fehlerfall zwei unterschiedlicheFehler finden. Ob diese Fehler inhaltlichzusammenhängen oder der Fehler gar auseiner falschen Berechnung aus einem Dritt-system herrührt, wird auf traditionelle Weisenicht erkannt. Was fehlt, ist ein Überblick über

Warum SOA Management?Die Flexibilität einer ServiceorientiertenArchitektur in Bezug auf ihre Erweier-barkeit und Skalierbarkeit überzeugenimmer mehr IT-Verantwortliche. Die mo-derne Architektur hilft ihnen schneller aufneue Anforderungen aus den Geschäfts-bereichen zu reagieren. Die ersten Projektesind bereits umgesetzt und die ersten posi-tiven Erfahrungen daraus gesammelt. DieseProjekte gehen nun in den Betrieb und hiererkennt man, dass eine SOA eine weitereHerausforderung abverlangt aber auchneue Möglichkeiten für die Betreiber bietet.

Herkömmliches IT Management be-gnügte sich im einfachsten Fall mit der

der au toradver tor i a l

1

Abbildung 1: Wie viele Fehler sieht ihr IT Management Tool?

4 / 2 0 0 6

Die Geschäftsbereiche als Auftragsgebersind die Treiber. Sie wollen wissen, ob derDienst, den sie beauftragt haben, auch dievorgegebenen Service Level Agreements(SLA’s) einhält. Sie wollen wissen, wer ihreServices benutzt und die Kosten dafür inRechnung stellen. Oder sie wollen fürunterschiedliche Benutzer, Benutzer-gruppen, Eingabekanäle oder Geschäfts-prozesse unterschiedliche SLA’s definieren.

Unterschiedliche Sichtweisenfür SOA Runtime GovernanceDie neuen technischen und wirtschaftlichenHerausforderungen führen hin zu einerneuen Art des IT-Managements, von dembesonders Serviceorientierte Architekturenprofitieren.

Das normale Vorgehen bei der Ent-wicklung einer SOA ist ein Design-Review-Audit-Zyklus. Innerhalb dieses Zykluswerden statische Checks auf PolicyCompliance durchgeführt. Sowohl zur Ent-wicklungszeit als auch bei der In-betriebnahme werden diese Tests durchTools unterstützt. Die Beschränkung aufeinen rein statischen Check geht jedoch voneinigen falschen Annahmen aus.

Zum einen ist es nie sicher, dass derKontrollprozess vollständig ist und auchalle Eventualitäten abdeckt. Das istdadurch schon nicht gegeben, weil nichtalle implementierten Services von der ITgeplant, implementiert oder eingespieltwerden. Jede gekaufte Anwendung kommtheute „out of the box“ mit jeder MengeDiensten einher, die einfach nur aufgerufenwerden.

Zum anderen sind die Policies nicht sta-tisch, sondern ändern sich während des

Lifecycles des Services oder sind sogarabhängig vom semantischen Kontext, indem sich der Service befindet.

SOA Management kommt daher nichtohne Governance zur Laufzeit aus.

InfrastruktursichtDie Basis für die SOA Governance ist dieSicht auf die IT Infrastruktur. Jedoch nichtals Inselsicht auf einen Rechner oder einenService, sie gibt vielmehr eine Laufzeitsichtauf die komplette IT. Welcher Service wirdvon wem wie häufig aufgerufen? WelcheProtokolle werden verwendet? WelcheDatenbanktabellen werden aufgerufen?Wie ist die Antwortzeit etc.?

Mit der Infrastruktursicht soll jedochnicht das traditionelle IT Managementabgelöst werden. Im Gegenteil. Sie ist alsderen Ergänzung zu sehen. Im Fehlerfalloder bei Missachtung eines Service LevelAgreements kann die Infrastruktursichteiner SOA Governance dem traditionellenIT Management zusätzliche Kontextinfor-mation zu Verfügung stellen.

Die Infrastruktursicht macht die komple-xen Verknüpfungen der einzelnen Servicestransparent.

Geschäftsprozess SichtIT Governance war bislang ein Thema desIT-Bereichs. Die Sicht auf die Geschäfts-prozesse bietet dem Fachbereich erstmalsinteressante Informationen. Welche in mei-ner Verantwortlichkeit befindlichen Ge-schäftsprozesse laufen gerade? Er kann fürseine Prozesse über den GesamtprozessService Levels Agrements definieren undderen Einhaltung überwachen.

Business Kriterien SichtEine Business Kriterien Sicht ist eine Ab-straktionsebene über die Geschäftprozesse.Hier werden die Eingaben und Aufrufe derDienste beim Ablauf eines Geschäfts-prozesses interpretiert. Der Prozess-verantwortliche legt seine Kriterien fest. Erentscheidet, dass der Kunde „Meier“ zumKreis seiner „Gold“ Kunden gehört odergruppiert Ländereingaben zu Regionenoder fasst Produkte zu Produktgruppenzusammen.

Auch hier muss die Möglichkeit bestehenspezielle Service Level Agreements für dieseKriterien zu definieren.

Verknüpfung der einzelnen SichtenJede einzelne Sicht allein bietet schon einengroßen Pool an Informationen und Mög-lichkeiten des Managements. Zum Teilwerden diese Sichten bereits von bestehen-den Monitoring-Werkzeugen generiert.Aber erst die Verknüpfung der einzelnenSichten untereinander bietet die Möglich-keit eine Serviceorientierte Architektur effi-zient zu verwalten. Nur durch die Ver-knüpfung ist es zum Beispiel möglich dieFolgen eines IT-Ausfalls zu bestimmen. Zuwissen, welche anderen Dienste betroffensind oder welche Kunden oderGeschäftsprozesse berührt werden, machteine übergreifende Reaktion erst möglich.

Zum Beispiel kann man bei langenAntwortzeiten auf einem Backend Service,Goldkunden bevorzugt behandeln, wäh-rend man andere Kunden schon amUnternehmensportal versucht abzuweisenoder zu anderen Diensten umzurouten.

adver tor i a l

w w w. s i g s - d a t a c o m . d e 2

Abbildung 2: Die Verknüpfung der einzelnen Sichten bringt den entscheidenden Vorteil

tor integriert. Dieser Interceptor beobach-tet alle ein- und ausgehenden Nachrichten,markiert sie wie in Abbildung 3 zu sehen istund gibt Informationen an einen Dienstweiter.

Abbildung 4 zeigt diesen Dienst einesSOA Management Tools als eine überge-ordnete Ebene in der SOA. Dieser Dienstverwaltet die definierten Service LevelAgreements. Entsprechend nach den SLA’saggregiert er die einzelnen Informationenaus den Interceptoren. Er wertet sie aus,speichert sie und reagiert bei SLA Ver-letzungen. Durch die Markierungen, derNachrichten und Aufrufe ist es möglich dieHistorie und den Kontext des Aufrufs ein-deutig zu bestimmen und im Fehlerfall eineRoot-Cause-Analyse durchzuführen.

ZusammenfassungDie Einführung einer ServiceorientiertenArchitektur in einem Unternehmen hilft derIT sich schnell an Veränderungen vonGeschäftsprozessen anzupassen. DieserVorteil ist unbestritten. Die Ausrichtungder IT an die Geschäftprozesse muss jedochständig neu verifiziert und dokumentiertwerden. Dazu brauchen im Unternehmenvorhanden IT-Management-Tools Ergän-zungen, die integriert die Geschäftssichtmit aufnehmen. Diese Management Toolsbieten erstmalig sowohl Business- als auchIT-Managern Unterstützung an und helfendadurch die IT und die Geschäftsprozesseauch in der Verwaltung näher zusammenzu bringen. ■

sich in die Plattform auf der dieAnwendung läuft, integrieren, sind einfa-cher in der Anwendung. Dabei wird in derPlattform, sei es ein Applikationsserveroder ein Transaktionssystem, ein Intercep-

Technische Anforderungenund UmsetzungUm eine Serviceorientierte Architektur zuverwalten, muss das Managementsystem indie Architektur integriert sein. Entspre-chend dem Paradigma als Dienst in derSOA.

Um eine Infrastruktursicht zu erzeugenbedarf es jedoch einer engeren Integration.Im Idealfall ist dies eine für die Dienstenon-invasive Ergänzung. Das heißt, esbraucht beim Design oder der Entwicklungdes Dienstes das Vorhandensein eines SOAManagements nicht einbezogen zu werden.Der Dienst kann sogar nachträglich instru-mentarisiert werden.

Proxy Lösung sind durch die einfacheArt sie zu umgehen und durch den zusätz-lichen Adressierungsaufwand weniger gutgeeignet. SOA Managementsysteme, die

adver tor i a l

3

Abbildung 3: Automatisches Tagging des Prozessflows

Abbildung 4: Einbindung des SOA Managements als zusätzlicher Dienst.