Serviceorientierte Architektur: Anforderungen, Konzeption und Praxiserfahrungen

Von Hermann Schlamann

Die Geschäftsfunktionalität eines Unternehmens sollte durch IT automatisiert und unterstützt werden. Das lehrt die Wirtschaftsinformatik. Bei vielen IT-Projekten steht jedoch am Anfang häufig die Diskussion, wie man zu einem Ergebnis kommt, das einerseits vom Auftraggeber akzeptiert wird und andererseits für die Zukunft anpassungsfähig genug ist. Hermann Schlamann macht in diesem shortcut den Arbeitsprozess serviceorientierter Architektur nachvollziehbar. Ausgehend von den spezifischen Unternehmensanforderungen thematisiert er die IT-Konzeption sowie ihre Inbetriebnahme und nennt anwendungsorientierte Beispiele aus der Praxis.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 25. Apr. 2012
• ISBN: 9783868024166

Buchvorschau

Hermann Schlamann

Serviceorientierte Architektur

Anforderungen, Konzeption und Praxiserfahrungen

ISBN: 978-3-86802-416-6

© 2012 entwickler.press

Ein Imprint der Software & Support Media GmbH

1 Serviceorientierung praktisch

Kontext

Die Wirtschaftsinformatik lehrt, dass Geschäftsfunktionalität durch IT-Funktionalität automatisiert und unterstützt werden sollte. IT-Funktionalität wird meist durch Projekte gestaltet und bereitgestellt.

Bei vielen IT-Projekten steht jedoch oft am Anfang die Diskussion, wie man am besten vorgehen sollte, um zu einem Ergebnis zu kommen, das einerseits vom Auftraggeber akzeptiert wird und andererseits für die Zukunft flexibel genug und anpassungsfähig ist. Diese Diskussion führt zu einer ganzen Reihe weiterer Fragen:

Ist Serviceorientierung das richtige Mittel?

Wenn ja, welche Services (auch externe!) können (wieder)verwendet und welche Services müssen vom Projekt neu erstellt werden?

Was ist der passende Funktionsumfang von Services?

Inwieweit machen wir uns vom Serviceanbieter abhängig, wenn keine eigenen Services benutzt werden?

Sollten die eigenen Services so gestaltet werden, dass andere sie wiederverwenden können?

Manche Antworten auf diese Fragen beeinflussen die IT-Landschaft weit über den Projektrahmen hinaus und müssen mit dem Blick aufs Ganze gegeben werden.

Eine Diskussion über die richtige Vorgehensweise und die Abgrenzung zu anderen Projekten findet oft nur innerhalb des Projekts statt. Kommunikation über Projektgrenzen hinweg ist meist problematisch und wird eher selten extensiv gepflegt. So kommt es unvermeidlich bei der Abgrenzung von Projekten zu Überschneidungen. Im günstigsten Fall werden solche Überschneidungen rechtzeitig bemerkt und bereinigt.

1.1 Sichtweisen

Wie kommt man innerhalb mehrerer Businesseinheiten (Organisationseinheiten) nun zu einer klaren Abgrenzung der Geschäftsfunktionalität? Betrachten wir einmal innerhalb der Organisationseinheit „Vertrieb" das Geschäftsobjekt Kunde. Aus Vertriebssicht wird man folgender Definition von Kunde zustimmen: „Einer, der beim Unternehmen etwas kauft". Wie verhält es sich dann mit Interessenten? Interessenten haben noch nichts beim Unternehmen gekauft, sind aber aus Vertriebssicht potenzielle Kunden.

Einige Geschäftsprozesse können mit Informationstechnologie automatisiert werden. Die notwendige Funktionalität ist dazu korrekt mit IT umzusetzen. IT bildet demnach eine Teilmenge der Businessaktivitäten ab, aber eben nicht alles, denn es bleiben manuelle Tätigkeiten im Business, die nicht automatisiert werden können. Ist die zu automatisierende Funktionalität einmal bestimmt, kann aus informationstechnischer Sicht überlegt werden, wie diese Funktionalität am besten umgesetzt und betrieben werden kann.

Hier stellt sich wieder die Frage: „Ist für jede Funktion ein eigenes System notwendig, oder können auf einer technischen Plattform mehrere Systeme gleichzeitig betrieben werden?" Wenn es nicht möglich ist, alle Systeme auf einer technischen Plattform zu betreiben, wie viele Plattformen sind dann notwendig? Wo liegt das ökonomische Maximum für die Anzahl der zu unterstützenden Plattformen aus betrieblicher Sicht?

Die Antworten auf die gestellten Fragen sind vielschichtig. Um ein wenig Ordnung und Übersicht zu schaffen, hat die Objekt Management Group (OMG) folgendes Standardschema festgelegt (Abb. 1.1).

Abbildung 1.1: Model-driven Architecture der OMG

Den ersten Bereich bildet das