Discover millions of ebooks, audiobooks, and so much more with a free trial

Only $11.99/month after trial. Cancel anytime.

Serviceorientierte Architektur: Anforderungen, Konzeption und Praxiserfahrungen
Serviceorientierte Architektur: Anforderungen, Konzeption und Praxiserfahrungen
Serviceorientierte Architektur: Anforderungen, Konzeption und Praxiserfahrungen
Ebook72 pages32 minutes

Serviceorientierte Architektur: Anforderungen, Konzeption und Praxiserfahrungen

Rating: 0 out of 5 stars

()

Read preview

About this ebook

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.
LanguageDeutsch
Release dateApr 25, 2012
ISBN9783868024166
Serviceorientierte Architektur: Anforderungen, Konzeption und Praxiserfahrungen

Related to Serviceorientierte Architektur

Titles in the series (100)

View More

Related ebooks

Software Development & Engineering For You

View More

Related articles

Reviews for Serviceorientierte Architektur

Rating: 0 out of 5 stars
0 ratings

0 ratings0 reviews

What did you think?

Tap to rate

Review must be at least 10 words

    Book preview

    Serviceorientierte Architektur - Hermann Schlamann

    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

    Enjoying the preview?
    Page 1 of 1