Die Schwierigkeiten bei der Erstellung unternehmensweiter Softwarelösungen ergeben sich in mindestens vier
Hauptbereichen:
-
Verständnis hochkomplexer Geschäftsbereiche
-
Ermittlung der effizientesten Nutzung von IT-Ressourcen zur Erfüllung geschäftlicher Bedürfnisse
-
Steuerung der Entwicklungsarbeit großer Entwicklerteams über mehrere Projektphasen und viele Monate hinweg
-
Die Implementierung von Lösungen in einem komplexen Sortiment von Infrastrukturtechnologien, die sich über viele
Jahre entwickelt haben und eine Vielzahl von Middleware-Produkten verschiedener Anbieter umfassen, die in spärlich
dokumentierten Integrationsvorgängen unterschiedlicher Qualität assembliert wurden.
Lösungen in diesem Kontext zu entwickeln, erfordert einen Ansatz in der Softwarearchitektur, der Architekten hilft,
ihre Lösungen auf flexible Weise weiterzuentwickeln und bereits geleistete Arbeit im Kontext neuer Funktionen
wiederzuverwenden, die Geschäftsfunktionen schnell implementieren, auch wenn die Zielinfrastruktur selbst sich
weiterentwickelt. Um diesen Anforderungen besser gerecht werden zu können, versuchen viele Organisationen,
Informationsquellen als weitgehend unabhängige, wiederverwendbare, funktionale Funktionen zu reorganisieren, die eine
per se anpassbare Umgebung erstellen. Durch Beschreibung dieser wiederverwendbaren Funktionen mit offenen
Standardprotokollen kann eine Organisation selbsterklärende Services erstellen, die unabhängig von der zugrunde
liegenden Technologie verwendet werden können. Diese technische Unabhängigkeit erlaubt es, Services in verschiedenen
Kontexten zu verwenden, um Geschäftsprozesse, Regeln und Richtlinien zu standardisieren. Es wird jetzt allgemein
anerkannt, dass dieser Ansatz für IT-Systeme, der als serviceorientierte Architektur (SOA) bezeichnet wird, das
Potenzial für eine enorme Verbesserung der Reaktionsfähigkeit von Geschäfts- und IT-Abteilungen hat.
Die Entwicklung hin zur SOA stellt eine Organisationen vor viele Herausforderungen. Serviceorientierte Konzepte führen
beispielsweise neue Begriffe und Modelle ein und fördern die Interoperabilität und Prozessintegration. Außerdem kann
die Integration vieler zugrunde liegender Technologieschichten, die eine serviceorientierte Architektur ausmachen, eine
sehr komplexe Aufgabe sein. IT-Abteilungen kommen oft zu der Erkenntnis, dass es notwendig ist, das Konzept zu ändern,
das Know-how auf den neuesten Stand zu bringen, neue Funktionen in die Entwicklungsumgebungen aufzunehmen oder
Änderungen an den Prozessen für Lösungsdesign vorzunehmen. Das Konzept der SOA, das erst seit kurzem existiert, besteht
in dem Bestreben, alle diese Anforderungen zusammenzubringen. Es gibt allerdings verschiedene klare Perspektiven zur
Spezifik einer SOA und ihrer Rolle bei der Handhabung wichtiger Probleme im Zusammenhang mit der Entwicklung von
Softwarelösungen für Unternehmen.
Systeme setzen sich aus Sammlungen von Services zusammen, die Aufrufe für Operationen durchführen, die über ihre
Serviceschnittstellen definiert sind. Viele Organisationen drücken jetzt ihre Lösungen durch Services und deren
Zusammenwirken aus. Das höchste Ziel bei der Anpassung einer SOA besteht darin, Flexibilität für das Geschäft und den
IT-Bereich zu schaffen. Es wurden eine Reihe wichtiger Technologien zur Unterstützung eines SOA-Ansatzes definiert,
besonders wenn die Services auf viele Maschinen verteilt sind und eine Verbindung zu ihnen über das Internet oder ein
Intranet besteht. Diese Web-Services-Ansätze stützen sich auf Kommunikationsprotokolle wie SOAP, die zwischen Services
verwendet werden, und bieten die Möglichkeit, Web-Services-Schnittstellen (ausgedrückt in WSDL (Web Services Definition
Language)) bei öffentlichen Verzeichnissen zu registrieren und in UDDI-Registrys (Universal Description, Discovery and
Integration) zu durchsuchen. Außerdem nutzen sie Informationen in Dokumenten, die in XML definiert und in
Standardschemata beschrieben werden, gemeinsam. Darüber hinaus werden Standards entwickelt, um weitere Bereiche wie
Richtlinien, Zuverlässigkeit, Ermittlung usw. abzudecken. Diese Standardfamilie wird im Allgemeinen mit "WS-* family"
bezeichnet.
Die serviceorientierte Architektur ist jedoch genauso wenig nur eine Gruppe von Standards und Servicebeschreibungen wie
die Objektorientierung einfach nur eine Gruppe von Klassenhierarchien ist. Tatsächlich besteht die Möglichkeit, eine
SOA aufzubauen, die keine Web-Services-Technologie verwendet, und es ist auch möglich, die Web-Services-Technologie
nicht serviceorientiert zu nutzen. Es gibt wesentlich mehr Punkte zu berücksichtigen, wenn man verstehen möchte, warum
ein serviceorientierter Blickpunkt einem Geschäft Nutzen bringt und wie serviceorientierte Lösungen entworfen,
implementiert und verwaltet werden. [SOA ist nicht mit WS identisch]
Lösungen für SOA zu erstellen, bedeutet, das Konzept von Systemen, die heute entwickelt werden, sowie das Know-how in
Organisationen zu überdenken. Es bedeutet auch, die Art und Weise der Zusammenarbeit von Teammitgliedern neu zu
definieren. Wichtig ist vor allem, dass bei einer serviceorientierten Lösungsentwicklung die Auswirkungen auf das
Lösungsdesign umfassender geprüft werden müssen. Es muss geprüft werden, wie die Lösungen aus den verschiedenen
Services zusammengestellt und implementierte serviceorientierte Lösungen verwaltet und weiterentwickelt werden.
Eine wichtige Änderung in diesem Zusammenhang ist, dass der Begriff "Anwendung", wie schon erläutert, problematisch
wird. Es findet eine Verlagerung statt: von der Anwendung als zentraler Größe aller Projekte hin zum Service-Portfolio,
auf dem ein Geschäft basiert. Diesbezüglich kann die Verlagerung von anwendungsorientierten zu serviceorientierten
Projekten als Verlagerung vom Design einer vertikal integrierten Gruppe von Komponenten, die eine Anwendung ausmachen,
hin zum Design einer horizontalen Servicegruppe betrachtet werden. In Zukunft wird der Begriff der Anwendung wohl nur
noch zur Beschreibung einer kleinen Schicht spezifischer, mit den Services für die Benutzerinteraktion in engem
Zusammenhang stehender Geschäftslogik verwendet, die die Geschäfts- und Infrastrukturservices mit dem größten Nutzen
bereitstellen.
Gartner bezeichnet diesen weiteren Kontext der Serviceorientierung als
serviceorientierte Entwicklung von Anwendungen (Service-Oriented Development of Applications, SODA). Er geht bei der
SODA von folgenden fünf Grundsätzen aus: Zusammensetzung, adaptives Prozessmanagement, servicebasierte
Interoperabilität und Integration, Erkennung und Beschreibung sowie schnelle Anwendungspflege. Aus der Perspektive des
Toolherstellers beziehen sich diese Punkte auf Technologieunterstützung in drei Bereichen:
SOA-Lebenszyklus. Die Grundsätze "Erkennung und Beschreibung" und "Schnelle Anwendungspflege" beziehen sich auf
den Lebenszyklus, die Lokalisierung, Anwendung, Weiterentwicklung und Pflege von Services. Toolhersteller stellen immer
mehr Methoden bereit, mit denen Services gespeichert, katalogisiert, gesucht und abgerufen werden können. Unterstützung
für die laufende Weiterentwicklung von Services ist in diesem Zusammenhang ein kritischer Aspekt, der zu vielen
Serviceversionen führt.
SOA-Plattform und -Programmiermodell. Der Grundsatz "Servicebasierte Interoperabilität und Integration" bezieht
sich auf die Verbindung, das Deployment und die Verwaltung von Services in einer bestimmten Laufzeitplattform. Die
wichtigsten Plattformhersteller unterstützen serviceorientierte Funktionen direkt als Teil der Middleware-Laufzeiten
und entwickeln die Laufzeitprogrammiermodelle weiter, um die Servicekonzepte als Elemente ersten Grades
bereitzustellen. Infolgedessen können Lösungen aus einer einzigen servicebasierten Perspektive konzipiert, entworfen,
implementiert und verwaltet werden.
SOA-Verfahren und -Tools. Die Grundsätze "Komposition" und "Management adaptiver Prozesse" beziehen sich auf die
Erstellung und Assemblierung von Services im Kontext der Lösung sich ändernder Geschäftsanforderungen. Toolhersteller
unterstützen die Filterung vorhandener Anwendungen zur Ermittlung potenzieller Services, wobei man vorhandene
Funktionen als Basis verwendet, um die Leistungsmerkmale als Services zur Verfügung zu stellen. Des Weiteren
unterstützen Toolhersteller die Erstellung neuer Services und die Verbindung von Services, wobei Verbindungen zwischen
dem über die Schnittstellen bereitgestellten Verhalten hergestellt werden. Von entscheidender Bedeutung in diesem
Zusammenhang sind klare Anleitungen und bewährte Verfahren für die Entwicklung serviceorientierter Lösungen, die
wiederholbar und voraussagbar sind.
Alle drei Bereiche sind für den Erfolg bei der Entwicklung serviceorientierter Lösungen wichtig. Sie müssen alle
berücksichtigt werden, um den Anforderungen einer Organisation in Bezug auf die effiziente Erstellung flexiblerer
Lösungen, die besser auf die geschäftlichen Ziele ausgerichtet sind, gerecht zu werden.
Eine der primären Herausforderungen bei der Entwicklung unternehmensweiter Lösungen ist, die domänenspezifischen, durch
Geschäftsanalysten ausgedrückten Anforderungen mit den technologiespezifischen, von der IT-Abteilung entworfenen
Lösungen zu verbinden. Normalerweise ist die Verbindung zwischen diesen zwei getrennten Welten nicht positiv. Die zwei
Communitys haben ein sehr unterschiedliches Know-how, verwenden verschiedene Modellierungskonzepte und Notationen
(falls überhaupt) und haben oft keine Vorstellung von der Zuordnung zwischen ihnen. Die Verwendung eines
serviceorientierten Ansatzes soll diese Lücke zwischen den Geschäftsanalytikern, den Geschäftsbereichsspezialisten und
IT-Spezialisten, z. B. Architekten, Systemanalytikern, Integratoren, Designern und Entwicklern, überbrücken helfen.
Insbesondere die Integration von Prozessen, Assets und Liefergegenständen sollen diese zwei verschiedenen Aspekte des
Systems klar und präzise verbinden.
SOA stellt eine serviceorientierte Sicht bereit, um diese Herausforderungen zu bewältigen:
Diskrepanz zwischen Geschäft und IT überbrücken. Es ist von wesentlicher Bedeutung, die Geschäftssicht von
Aktivitäten und Prozessen an der Technologie auszurichten, die zur Realisierung von Teilen dieser Aktivitäten verwendet
wird. Diese Ausrichtung beinhaltet die Fähigkeit von Geschäftsmodellen, Downstream-Entwicklung zu steuern und die
Geschäftsmodelle und IT-Lösungen in Kombination zu entwickeln. Das Servicekonzept ist für diese Ausrichtung von
entscheidender Bedeutung. Services und servicebasierte Denkweise bilden die allgemeine Grundlage, die
Geschäftsanalytiker, IT-Architekten, Integratoren und Entwickler miteinander verbindet. Die Spezifik von Services, der
Unterteilungs- und Kapselungsstufe, die sie unterstützen, erlaubt ihnen eine viel stärkere Ausrichtung auf die
Geschäftsprozessmodelle, die das Geschäft steuern. Allgemeine Designverfahren sind von entscheidender Bedeutung, um
sicherzustellen, dass die Konzepte, Arbeitsergebnisse und Aufgaben in diesen verschiedenen Perspektiven synchronisiert
werden. Außerdem sind Tools, die Modelle, die die Geschäftsabsicht repräsentieren, in effiziente Implementierungen
umwandeln können, sehr wichtig, um die Lücke zwischen Geschäft und IT zu überbrücken.
Die sich ändernden Rollen in der IT-Abteilung unterstützen. Die Verlagerung hin zu serviceorientierter Denkweise
ändert das Know-how und die Zusammensetzung von Teams in einer Organisation. Der Fokus der Entwicklung liegt darauf,
Services zu suchen, definieren, verwalten und assemblieren, mit architektonischen Beschreibungen, die
Service-Level-Agreements (SLAs) und Protokolle zwischen Services hervorheben. Die traditionelle Gliederung von
Toolfunktionen in die heutige Produktaufstellung lässt sich mit diesem Ansatz nicht vereinbaren. Es gibt eine andere
Mischung von Funktionen, die von den verschiedenen Mitgliedern in IT-Abteilungen angefragt werden. Beispielsweise wird
das Know-how, das von vorhandenen Rollen, z. B. dem Softwarearchitekten, sich dahingehend ändern, dass es die
Assemblierung und das Management von Services in einer anderen Gruppe von Serviceprovidern stärker betont. Analog dazu
entstehen neue Rollen wie die des Integrationsspezialisten, die sich auf die Assemblierung einer servicebasierten
Wertschöpfungskette zur Unterstützung der wichtigsten Geschäftsziele einer Organisation konzentrieren.
Fokus auf Assets und Wiederverwendung. Die Berücksichtigung von Services als wichtige Assets im Systemdesign
ändert den Blick einer Organisation auf den Nutzen, den die Wiederverwendung dieser Services bringt. Zuvor wurde die
Verlagerung von der vertikalen Entwicklung einer Gruppe von Anwendungskomponenten hin zur horizontalen Integration von
Komponenten erläutert. Ein wichtiger Aspekt in diesem Zusammenhang ist, dass die Services selbst in höherem Maße
wiederverwendet werden können. Tatsächlich ist die Kombination der Services zu neuen Funktionen, ihre Zusammensetzung
zu neuen Services ein grundlegender Aspekt der Änderung. In vielen Geschäften rechtfertigt diese Hoffnung auf eine
bessere Wiederverwendung im Rahmen einer SOA die Kosten, die mit dem Design und der Entwicklung eines
Service-Portfolios verbunden sind. Infolgedessen werden Technologien und Techniken zur Verwaltung und Steuerung von
Assets sowie wiederholbare Methoden zur Erfassung von Mustern für die Kombination von Assets sehr viel wichtiger. In
einem assetbasierten Entwicklungsansatz haben diese Assets einen großen Wert für die Organisation und müssen sorgfältig
verwaltet werden. Die Infrastruktur des Teams für die Asset-Verwaltung übernimmt in diesem Ansatz eine wichtige Rolle.
Mehr Kollaborationsebenen in Anwenderrollen und darüber hinaus. Die Entwicklung von Unternehmensanwendungen
basierte schon immer auf Teamarbeit und konzentrierte ihre Aufmerksamkeit im gesamten Lebenszyklus von Projekten auf
die Verwaltung gemeinsam genutzter Assets, die Rückverfolgbarkeit von Arbeitsergebnissen und gemeinsam genutzte
Verfahren und Prozesse. Die Interaktivität der Softwareentwicklung gewinnt mit größerer geographischer Verteilung von
Organisationen, verbesserter Echtzeitkommunikation zwischen Einzelpersonen in Teams und Software, die als Bestandteil
breiter angelegter Initiativen zur Systementwicklung integriert werden, an Bedeutung. Die Rolle der Infrastrukturen der
Softwareentwicklung wird in immer stärkerem Maße als interaktive Entwicklungsumgebung für Softwareanwender gesehen, die
die teamübergreifende gemeinsame Nutzung und Wiederverwendung von Services unterstützen.
Bei jeder neuen Entwicklung im Bereich des Software-Engineering ist es sehr einfach, anzunehmen, dass jemand dieselben
Techniken und Tools anwenden kann, die in vorherigen Projekten funktionierten. Diese Tendenz, neue Probleme mit
veralteten Lösungen zu beheben, ist nicht neu. Als Entwickler begannen, komponentenbasierte Anwendungen zu entwickeln,
versuchten sie, Probleme zu lösen, indem sie ihre Erfahrung mit objektorientierter Entwicklung nutzten. Mit zunehmender
Erfahrung begriff man, dass objektorientierte Technologie und Sprachen sehr gut zur Implementierung von Komponenten
geeignet sind, obwohl man sich über die Kompromisse bei Entscheidungen und Implementierung im Klaren sein muss.
Beispielsweise muss hinsichtlich der Implementierung polymorphen Verhaltens oder der Überarbeitung von
Klassenbibliotheken ein Kompromiss zwischen Übernahme und Aggregation gefunden werden, damit Komponentengruppen als
Basis für eine monolithische C++-Anwendung verwendet werden können.
Analog dazu bieten Komponenten die beste Möglichkeit zur Implementierung von Services, obwohl betont werden muss, dass
eine vorbildliche komponentenbasierte Anwendung nicht notwendigerweise eine vorbildliche SOA ausmacht. Wenn Sie sich
mit der Rolle, die Services in der Anwendungsarchitektur spielen, vertraut gemacht haben, haben Sie eine gute Chance,
die Komponentenentwickler Ihres Unternehmens einzusetzen und vorhandene Komponenten zu verwenden. Wichtig zur
Durchführung dieses Übergangs ist, zu erkennen, dass ein serviceorientierter Ansatz eine zusätzliche Schicht der
Anwendungsarchitektur einschließt. Die Abbildung unten zeigt, wie man Technologieschichten auf die
Anwendungsarchitektur anwenden kann, um allgemeiner definierte Implementierungen bereitzustellen, wenn man sich den
Konsumenten der Lösung annähert. Für diesen Bereich des Systems wird der Begriff "Anwendungsrand" verwendet, der zum
Ausdruck bringt, dass ein Service sich gut dazu eignet, eine externe Sicht eines Systems offen zu legen, mit interner
Wiederverwendung und Komposition, bei Verwendung des traditionellen Komponentendesigns. Eine Möglichkeit, die
Unterschiede zwischen Objekten, Komponenten und Services zu untersuchen, besteht in der Art und Weise, auf die sie an
ihre Implementierung gekoppelt sind. Ein Objekt ist fest an seine Programmiersprache gekoppelt, Komponenten sind an
eine Laufzeit oder Plattform (COM, CORBA, J2EE u. Ä.) gekoppelt, wohingegen Services wirklich nur an die Gruppe der
Standards gekoppelt sind, die deren Spezifikation beschreiben.
Allgemein betrachtet nahm der Wechsel von der objektorientierten zur komponentenbasierten Methode zwischen 6 und 18
Monate in Anspruch. In dieser Zeit machten sich die Entwickler mit dieser neuen Technologie und ihren Anforderungen
vertraut. Es bleibt zu hoffen, dass der Wechsel zu serviceorientierten Lösungen schneller vonstatten geht. Um das
möglich zu machen, müssen Entwickler sich mit den Herausforderungen, Kompromissen und designbezogenen Entscheidungen
vertraut machen, die die Entwicklung und Wiederverwendung von Komponenten zur Unterstützung serviceorientierter
Lösungen ermöglichen.
|