SOA Maturity Model: Leitfaden für die Einführung einer serviceorientierten Architektur

Das Nervensystem des Geschäfts

Hub Vandervoort

Während Entwickler und Systemarchitekten schnell erkannt haben, welche technischen Vorteile mit der Konzeption, Entwicklung und Implementierung serviceorientierter Architekturen verbunden sind, haben es IT-Manager schwer, deren wirtschaftlichen Nutzen genau einzuschätzen. Diese Aufgabe soll das neue SOA Maturity Model (SOA MM) unterstützen, denn es definiert die zu erwartenden Auswirkungen der Einführung serviceorientierter Architekturen aus kaufmännischer Sicht, und zwar für jede einzelne Reifephase.

Unternehmen haben bislang Methoden zur Kostenreduzierung wie Outsourcing oder Offshoring viel Zeit gewidmet und sich dabei weniger um den geschäftsfördernden Wert von neuer Technologie gekümmert. Ein neuer Ansatz im Design und in der Einführung von Informationstechnologie, eine serviceorientierte Architektur (SOA), kann die Basis für die Technologie- und Geschäftsabteilungen bilden, um gemeinsam an der Leistungssteigerung des Unternehmens zu arbeiten, und zwar in verschiedener Hinsicht einschließlich Kostenreduzierung und schlanker Ausrichtung der Implementierung neuer Geschäftsmodelle. Der SOA-Ansatz stellt eine Weiterentwicklung des verteilten Computing dar und ermöglicht die Interaktion von Diensten über ein Netzwerk, wobei die Services zu Anwendungen zusammengebaut werden und sich mehrfach verwenden lassen.

Bei der Einführung einer neuen Architektur stehen Unternehmen vor der schwierigen Aufgabe herauszufinden, wie sie die Vorteile der SOA nutzen und die erforderlichen Investitionen rechtfertigen können; außerdem müssen sie einen Anfangspunkt sowie ein Endziel festlegen. All diese Fragen bedürfen der Anleitung: Eine Lösung liefert das von AmberPoint, BearingPoint, Sonic Soft-ware und Systinet entwickelte SOA Maturity Model (SOA MM), das zeigt, welche zunehmend positiven Auswirkungen eine SOA-Einführung aus geschäftlicher Sicht haben kann. Das Reifemodell greift auf zwei Inspirationsquellen zurück: Zum einen ist das der Erfolg des Capability Maturity Model (CMM) und des neueren Capability Maturity Model Integration (CMMI). Beide stammen vom Software Engineering Institute (SEI) und liefern ein allgemeines Framework für die Defini-tion und Überprüfung der Verbesserung von Prozessen in Software- und anderen Entwicklungsprojekten. Zum anderen boten Beiträge wie die von Randy Heffner, Vice President bei Forrester Research, Anregungen und zeigten verschiedene erfolgreiche Wege auf, die Unternehmen zur Einführung einer SOA beschritten haben.

CMM und CMMI
Das Capability Maturity Model (CMM) ist ein Prozessmodell zur Beurteilung der Qualität des Softwareprozesses von Organisationen sowie zur Bestimmung der Maßnahmen zur Verbesserung desselben. Bei CMM wird die Qualität in fünf Stufen bewertet, wobei die Qualität mit jeder Stufe steigt [Wikipedia: CMM].
Die Capability Maturity Model Integration (CMMI) ersetzte CMM 2003. CMMI definiert Anforderungen an eine gute Produktentwicklung, aber keine konkreten Schritte. Das primäre Ziel von CMMI ist es, eine kontinuierliche Prozessverbesserung zu unterstützen, indem Anforderungen bzw. Kriterien an eine professionelle Produkt-Entwicklungs-Organisation definiert werden. Die Definition des Entwicklungsprozesses obliegt der Organisation und ist eine wichtige Teilaufgabe der Prozess­verbesserung [Wikipedia: CMMI].

Eine SOA lässt sich in ein dem CMM ähnliches Framework einpassen. Damit können die Ziele, Merkmale und Voraussetzungen des Einfluss einer SOA auf das Geschäft über mehrere Ebenen hinweg gezeigt werden. Ausgehend von neuer Funktionalität über Kostenreduzierung und Reaktionsfähigkeit des Geschäfts reichen die Ebenen bis zur Transforma-tion und schließlich Optimierung des Geschäfts. Das Maturity Model gibt für jede Ebene Ziele, Beschreibung des Umfangs und des Geschäftsnutzens, die wichtigen Standards, Practices und entscheidende Erfolgsfaktoren – sowohl technischer als auch organisatorischer Art. Auf diese Weise liefert das Reifemodell Anleitungen für das Erarbeiten einer SOA-Vision und auch Benchmarks zum Messen der Fortschritte.

Forrester Research hat festgestellt, dass- Unternehmen sich einer SOA über unterschiedliche Wege nähern, wobei je–der einen anderen Geschäftsnutzen bietet sowie unterschiedliche Kenntnisse und eine eigene technische Infrastruktur benötigt. Für manche stehen die interne Integration und der Workflow im Vordergrund, während für andere wiederum die Partnerintegration im Mittelpunkt steht. Dennoch können diese verschiedenen Ansätze mit den Ebenen im Maturity Model in Beziehung gesetzt werden, um die technischen und unternehmerischen Anforderungen und Ziele auf dem Weg zur SOA-Reife zu verfolgen.

Reifeebene Haupt-
geschäfts-
vorteile
Ziele,
Umfang
Technologische
Erfolgsfaktoren
Organisatorische
& menschliche Erfolgsfaktoren
Relevante
Standards
1.
Erste Services

(Initial
Services)
Neue
Funktionalität
Pilotprojekte,
Experimente, Portal, Integrations-
anpassungen, wenige Dienste
Standards,
Legacy-
Integration
Entwickler
erwerben Kenntnisse bei der Erstellung von Diensten
XML,
XSLT, WSDL, SOAP, Java, .NET
2.
Architektur für Services (Architected Services)
IT-Kosten-
reduzierung
und -kontrolle

Mehrfache
integrierte Anwendungen
Unterstützung
heterogener und verteilter Systeme, verlässliches Messaging,
Mediation, einfache Einführung, Datenbank-
integration,
Versionierung, interne Sicherheit, Performance-
Management
Architektur-
Team übernimmt die Projektleitung, SOA-
Kompetenz-
Center
UDDI,
WS-Reliable Messaging, WS-Policy, WS-Addressing, XQuery,
WS-Security, SAML
3.a
Business Services
Auswirkung
auf das Geschäft: schnelle, effiziente Änderung von
Geschäfts-
prozessen
Geschäftsprozesse
über Geschäfts-
einheiten hinweg oder aufs ganze
Unternehmen ausdehnen
Wiederverwendung,
einfache Modifizierung, Verfügbarkeit, Regeln für
Geschäftsprozesse, ereignisgesteuerte Prozesse, Composite
Applications
IT-Partnerschaft
mit dem Geschäft und zwischen Abteilungen,
SOA-
Lebenszyklus-
Leitfaden, Zustimmung durch die Geschäftsführung,
ereignisgesteuerte Designkenntnisse
WS-BPEL
3.b
Collaborative Services
Auswirkung
aufs Geschäft – Collaboration mit Geschäfts- und
Handelspartnern
Services
verfügbar für externe Partner und zwischen Unternehmen
Zurverfügungstellen
von externen Services, unternehmens-
übergreifende Sicherheit,
Übersetzung entsprechender Protokolle, lange andauernde
Transaktionen
s.o. RosettaNet,
ebXML, WS-Trust
4.
Messen von Business Services
Umwandlung
des reaktiven in ein Echtzeitgeschäft,
Geschäfts-Performance-
Metriken entsprechen

Geschäfts-einheiten
oder Unternehmen, unternehmens-
übergreifend

Business
Activity Monitoring, Event Stream Processing, komplexe
Ereignisverarbeitung, ereignisgesteuerte Dashboards und Alerts
Stetige
Auswertung von Geschäftsprozessen und den Wirkungen
5.
Optimierte Business Services
Optimierung
des Geschäfts – automatisch reagieren und antworten
Geschäfts-
einheiten oder Unternehmen, unternehmens-
übergreifend
Ereignisgesteuerte
Automatisierung für die Optimierung
Stetige
Verbesserung

Maturity
Level
Hauptziele Wichtige
Practices
1.
Erste Services
1. Erlernen der SOA-Technologie in Experimenten und Pilotprojekten
2. Anwenden von SOA-Technologie auf dringenden Bedarf
3. Definieren von ersten ROI-Maßzahlen für SOA-Projekte
1. Erstellen von Service-Definitionen
2. Integrieren von SOA in die Projektentwicklungsmethodologie
3. Festlegen von Kosten, Zeit und Geschäftsnutzen der Pilotprojekte
2. Architektur für Services 1. Festschreiben der Verwendung einer SOA
2. SOA als Hauptarchitektur festlegen
3. Beweisführung über Nutzen der Standardtechnologie
1. Spezifizieren von Technologiestandards
2. Integration der SOA in den abteilungsweiten Entwicklungsprozess
3. Abteilungsweites SOA-Training und Kompetenz-Center
4. Inkrementelle Integration
3.a Business Services 1. Ständige Partnerschaften zwischen Geschäfts- und Technologieabteilungen schaffen
2. Unterstützung aller Geschäftsprozesse durch SOA
3. Nutzennachweis zur Wiederverwendung von Diensten und der
Auswirkungen
1. Festlegen von Regeln für die Verwendung der SOA bei der Erstellung und Modifizierung von Geschäftsprozessen
2. Nutzen von ereignisgesteuerter und vermittelnder Funktionalität für die Verbesserung bzw. Erweiterung von Prozessen
3.b Collaborative Services 1. Ständige Partnerschaften zwischen Geschäfts- und Technologieabteilungen schaffen
2. Ausweiten der SOA-Geschäftsprozesse auf externe Organisationen
3. Nutzennachweis über die Verwendung von Services für die Collaboration
1. Festlegen von Regeln für die Verwendung der SOA bei der Zusammenarbeit mit Partnern
2. Implementierung von unternehmensübergreifender Sicherheit
4. Messen von Business Services 1. Festschreiben der Umwandlung von reaktiven in Echtzeit-Geschäftsprozesse
2. Definieren und Einhalten von geschäftsorientierten Performance-Metriken
1. Sammeln und Analysieren von geschäftsprozessbezogenen Echtzeit-Leistungsmetriken
2. Implementieren einer stetigen Geschäftsprozessauswertung und Re-Engineering
5. Optimierte Business Services 1. Einführen der unternehmensweiten Führung durch SOA
2. Nutzennachweis über SOA-gestützte anhaltende Verbesserungen
1. Implementieren von selbstheilenden Geschäftsprozessen
Erste Services für die Lernstufe

Die erste Ebene (SOA Maturity Level 1) umfasst bereits erste Services (Initial Services, Tabelle 1 und 2) und stellt die erste Lern- und Projektstufe einer SOA-Einführung dar. Typische Projekte in dieser Phase haben das Ziel, eine bestimmte Anforderung durch die Implementierung von Funktionalität zu erfüllen, aber auch, gewisse Techniken und den SOA-Ansatz auszuprobieren. Diese Reifeebene umfasst zudem auch erste Entwicklungsaktivitäten, um serviceorientierte Techniken in einer Laborumgebung zu testen. Üblicherweise steht die Abteilung für Anwendungsentwicklung als treibende Kraft hinter der Einführung einer SOA – häufig als Teil eines Anwendungsintegrationsprojekts. Dabei erwerben die Entwickler neue Kenntnisse und es gibt bereits Versuche, einen ROI zu errechnen. Dies ist auch die Stufe, auf der die grundlegenden SOA-Standards des W3C eingeführt werden. Dazu gehören XML für die Definition der Nachrichtenformate, WSDL für die Definition der Serviceschnittstellen und SOAP für den Nachrichtenaufruf.

Beispiel einer SOA-Implementierung auf der ersten Reifestufe mit einigen Diensten

Ein typisches Beispiel eines solchen anfänglichen Projekts (Abb. 1) ist die Anbindung eines unternehmensweiten Vertriebsportals sowohl direkt an einen neuen Application Server, um einen Forecasting- und Tracking-Dienst zu implementieren, als auch an eine traditionelle CRM-Applikation über einen Web-Service-Adapter. Die Serviceschnittstelle dieses Beispiels liefert die Verbindung und die erforderliche Übersetzung zwischen der Anwendungsimplementierung und den gewählten Kommunikationsprotokollen für die Dienste. Die Servicesschnittstellen selbst können über verschiedene Produkttypen bereitgestellt werden, etwa durch einen Appli
cation Server oder einen ESB-Adapter.

Der wichtigste Nutzen dieses ersten Projekts besteht in der Bereitstellung der erforderlichen Geschäftsfunktionalität. Gleichzeitig sammeln die Entwickler erste Erfahrungen damit, wie eine Basis-SOA-Anwendung entwickelt und eingeführt wird. Eine solche Implementierung nutzt das SOAP-Protokoll für die Kommunikation zwischen dem Portal-Server und den involvierten Diensten, aber auch für den Sales-Forecasting- und Tracking-Service, wenn dieser Informationen aus der CRM-Anwendung benötigt.

Bereits eine solch einfache Anwendung kann von der Nutzung weiterer SOA-Infrastruktur-Komponenten profitieren. Der wichtigste Grund für deren Einführung in ersten Projekten ist neben dem erzielten Lerneffekt durch eine frühzeitige Nutzung die Schaffung einer skalierbaren Grundlage, die den Anforderungen auch dann noch entspricht, wenn die SOA weitere Geschäftsfunktionen mit einbezieht.

Beispiel einer SOA-Implementierung, der bereits ein ESB hinzugefügt wurde, auf der ersten Reifestufe

Abbildung 2 zeigt dasselbe Beispiel wie Abbildung 1, wobei ein Enterprise Service Bus (ESB) hinzugefügt wurde. Er bietet ein Standard-Interaktionsmodell für SOA-Komponenten einschließlich Web Services und relationalen Datenbanken als eine skalierbare, einfach einzuführende verteilte Infrastruktur. Der ESB liefert eine Vielzahl von Adaptern, um Services in verteilten Technologien den Nachrichtenaustausch zu ermöglichen. Beispielsweise kann eine .NET- mit einer Java EE-Anwendung auf Serviceebene kommunizieren. Des Weiteren enthält das Beispiel nun einen Service Level Management Service, der Einsicht in die Performance der Web Services und auch Service-Level-Metriken bietet. Schließlich ist eine Services Registry mit UDDI-Unterstützung hinzugekommen. Sie liefert einen zentralen Speicherort für Servicedefinitionen und auch ihren zentralen Referenzpunkt.

Die zweite Ebene des SOA MM enthält in eine Architektur eingebaute Services. Auf dieser Ebene werden als technischer Leitfaden Standards für die SOA-Implementierung festgelegt, typischerweise unter der Leitung des Architektur-Teams. Der Hauptnutzen auf diesem Level besteht in der Senkung der Kosten für die Entwicklung und Einführung durch die Verwendung einer SOA-Standardinfrastruktur und deren Komponenten – traditionelle Technologien verursachen durch viele Einmal-Projekte höhere Kosten. Die Vorteile einer serviceorientierten Infrastruktur sind in verteilten Umgebungen, die für viele Unternehmen typisch sind, noch größer.
Auf der Basis der erworbenen Kenntnisse und des Feedbacks von Maturity Level 1 lassen sich architektonische Normen und Technologien für eine Standardimplementierung festlegen. Standards werden beispielsweise für die Verwendung von unternehmensweiten SOA-Protokollen ausgewählt. Empfehlenswert sind vor allem die von W3C, OASIS und WS-I. Darüber hinaus handelt es um Implementierungsplattformen, Policies einschließlich solcher für die Wiederverwendung, Compliance und die Sicherheit, aber auch um einen technischen Überprüfungsprozess für die Definition neuer Dienste und die Wiederverwendung bereits vorhandener.

Beispiel einer SOA-Implementierung auf der nächsten Reifestufe mit zusätzlichen Architekturdiensten

Abbildung 3 zeigt das Beispiel einer SOA-Einführung auf der Ebene 2 bei einem Finanzdienstleister. Das Maturity Level 2 umfasst sowohl die Verwendung der Schlüsselkomponenten aus Abbildung 2, einschließlich des Service Level Management, des Enterprise Service Bus und zusätzlicher wichtiger Komponenten. Dazu gehören „Services and Policies Repository“. Es erweitert die Services Registry um ein Repository für die vollständige Speicherung und Unterstützung von SOA-Informationen einschließlich der Policies und Servicedefinitionen mit Lebenszyklusmanagement, Benachrichtigung und Bewilligungen. Die Nutzung eines solchen Repository mit Entwicklungs- und Runtime-Unterstützung ist für die Prozesse der Ebene Architected Services von entscheidender Bedeutung. Ein Excep-tion Management Service liefert einen Mechanismus für das Aufspüren, Diagnos-tizieren und die automatische Behebung von Fehlern sowohl auf Anwendungs- als auch auf Systemebene. Nachrichtentransformation ermöglicht die Integration von Diensten mit unterschiedlichen Nachrichteninhalten und -formaten. Die Umwandlung wird häufig durch den Aufruf von XLST-Übersetzungsmechanismen für eine XML-Nachricht durchgeführt. Im Beispiel handelt es sich um eine Mediation-Funktion, die vom ESB kontrolliert wird. Ein Single-Sign-on-Service für die unternehmensweite Authentifizierung und Autorisierung der Benutzer stellt einen weiteren wichtigen Aspekt auf dieser Ebene dar. Ein solcher Dienst, den üblicherweise ein weiterer Anbieter liefert, kann auf den SAML-Standard der OASIS- für den Austausch von Authentifizierungs- und Autorisierungsinformationen beruhen.

Der Schwerpunkt des SOA Maturity Level 3 liegt auf der Zusammenarbeit von Technologie- und Geschäftsabteilungen, um sicherzustellen, dass der Einsatz einer SOA klare Rückwirkungen auf das Geschäft hat. Der Kern einer SOA besteht in der Verbindung der Geschäftsprozesse mit den digitalen Prozessen. Ebene 3 legt zwei Wege fest, um diese Ziele zu erreichen: Business Services konzentrieren sich auf die Verbesserung der internen Geschäftsprozesse und Collaborative Services sind auf die Verbesserung der kollaborativen Prozesse mit externen Partnern fokussiert. Selbstverständlich können beide genutzt werden, um den größten Nutzen aus einer SOA zu ziehen, doch Maturity Level 3 lässt sich auch mit einem der Wege erreichen, falls dieser die bestmöglichen Geschäftsvorteile bietet.

Beispiel einer SOA-Einführung auf Maturity Level 3 mit Business Process Management und weiteren Diensten

Abbildung 4 zeigt am Beispiel eines Finanzdienstleisters die SOA-Einführung auf Maturity Level 3. Mehrere Aspekte sind dabei von entscheidender Bedeutung: Business Process Management (BPM), das Management lang andauernder Prozesse, umfasst den Austausch sequenzieller Nachrichten zwischen den Diensten. Diese Aufgabe kann beispielsweise ein Orchestration Server übernehmen. Dieser bietet die Möglichkeit, den Status jedes Prozesses einschließlich der Zwischenergebnisse zu verwalten. Die Business Services lassen sich noch weiterentwickeln. Dazu gehört die Verbesserung der Geschäftsprozesse, denn ein Hauptvorteil einer SOA liegt darin, die Veränderung von Geschäftsprozessen über eine Neukonfiguration von Diensten zu ermöglichen. In dem Beispiel wird ein neuer Compliance Service, der für die Einhaltung gesetzlicher Vorschriften sorgt, in den Nachrichtenfluss zwischen dem Order Management Service und dem Trading Service eingefügt, ohne dass Änderungen in den Implementierungen der vorhandenen Dienste anfallen. Auf dieser Ebene muss die Wiederverwendung von Diensten zum Tragen kommen. Im Beispiel zeigt sich dies bei einer Multi-Channel-Anwendung (z.B. für den Zugriff von Kunden auf eine Anwendung über unterschiedliche Kommunikationsmethoden), im Rahmen derer der Order Management Service sowohl vom Call Center Service als auch vom Online Service genutzt wird.

Alternativ dazu kann der Schwerpunkt auf dieser dritten Reifestufe auf Collaborative Services liegen, mit deren Hilfe externe Partner anzubinden sind. Abbildung 4 stellt dar, wie der Dienstleis-ter seine Tätigkeiten auf Devisengeschäfte über das Internet ausgeweitet hat. Zu den wichtigsten Merkmalen dieser Implementierung von Collaborative Services gehört die Nutzung von SOA-Standardprotokollen, die spezifische Business-to-Business-Funktionalität unterstützen. An dieser Stelle ist beispielsweise RosettaNet zu nennen, ein Standard, der XML-Messaging-Funktionen für unternehmensübergreifende Operationen, wie etwa den Abruf von Produktinformationen, des Lagebestands und von Bestellungen definiert. Ein weiterer Schlüsselbestandteil dieses Levels ist ein Collaboration Server, der die B-to-B-Protokolle implementiert und die erforderlichen Umwandlungen der Nachrichten übernimmt – sowohl der für die internen Prozesse notwendigen als auch derjenigen für die externen Abläufe. Die ECN-Verbindung ist von einem proprietären Protokoll auf ein Standardprotokoll für Industrieservices übergegangen und wird aufgrund dessen vom Collaboration Server verwaltet.

Nachdem die dritte Stufe die Implementierung von internen als auch externe Geschäftsprozessen in den Mittelpunkt stellt, konzentriert sich Maturity Level 4 auf die Messung und Darstellung dieser Prozesse auf Geschäftsebene. Das Ziel dabei ist, fortlaufend Feedback über die Performance und die Auswirkungen der auf Ebene 3 implementierten Prozesse auf das Geschäft zu liefern.

Beim Event Stream Processing (ESP) handelt es sich um eine Reihe von Technologien, welche die Herstellung Event-getriebener Informationssysteme unterstützen. Zu ESP-Technologien zählen Event-Visualisierung, Event-Datenbanken, Event-getriebene Mid-dleware und Event Processing Languages bzw. Complex Event Processing (CEP). ESP soll durch die Bearbeitung multipler Datenströme (Streams) mit Event-Daten wichtige Events in diesen Streams ermitteln. Zu den zu diesem Zweck verwendeten Verfahren zählen das Erkennen komplexer Muster von Events, Event-Korrelation und -Abstraktion, Event-Hierarchien, außerdem die Beziehungen zwischen Events, wie Kausalität, Mitgliedschaft, Timing und Event-getriebene Prozesse.

Beispiel einer SOA-Implementierung auf der Reifestufe 5 mit Event Stream Processing in Echtzeit

Abbildung 5 zeigt einen Beispielprozess für die Konfiguration, Bestellung und Fertigung mit Diensten für jede einzelne Funktion, wobei diese auf verschiedene geographische Orte verteilt sind. Ein entscheidendes Merkmal für diesen Anwendungsfall stellt das Event Stream Processing in Echtzeit dar, denn damit lassen sich alle RFID-Ereignisse in einer Event-Datenbank sammeln und die für das Geschäft wichtigen Events regelbasiert herausfiltern sowie an andere Diens-te weiterleiten. Die Funktionalität des Event Stream Processing ermöglicht die Umwandlung von reaktiven Geschäftsprozessen in solche, die auf Echtzeitintelligenz basieren.
Von entscheidender Bedeutung ist auch das Business Activity Monitoring, welches über ein Dashboard Feedback zu Echt
zeit-Performance-Metriken an das Management liefert. Der Level Management Service von AmberPoint kann z.B. ein solches Monitoring für Ereignisse, die direkt an die SOA-Infrastruktur gebunden sind, übernehmen. In anderen Szenarien lassen sich die vom Service Level Management Service generierten Ereignisse an eher generische Dienste zur Verarbeitung und Darstellung weiterleiten.

Das SOA Maturity Level 5 schließlich konzentriert sich auf eine SOA mit optimierten Geschäftsservices. Zu diesem Zweck fügt die Ebene eine automatische Reaktion auf die Messung und Darstellung auf Ebene 4 hinzu. Infolgedessen wird das SOA-Informationssystem zu einem unternehmensweiten Nervensystem, das auf Ereignisse auf Geschäftsebene reagiert, und zwar nach Regeln für die Optimierung der Geschäftsziele.
Abbildung 5 zeigt den oben beschriebenen Prozess für die Konfiguration, Bestellung und Fertigung, der nun um eine dy
namische Preisfindung entsprechend dem Materialstatus und der Bearbeitung in der Fertigungsfabrik verbessert worden ist. Wenn beispielsweise Teile für eine bestimmte Version eines Produkts nicht verfügbar sind, kann ein Preis festgesetzt werden, der Käufer dazu anregen soll, das Produkt mit anderen Bestandteilen zu bestellen. Dieses Beispiel orientiert sich an Dells Erfolg mit dieser Methode: Das Unternehmen setzt eine dynamische Preisfindung ein, bei der ein Sonderpreis berechnet wird, wenn etwa ein Laufwerk mit einer bestimmten Kapazität nicht verfügbar ist und der Käufer sich für eines mit höherer Kapazität entscheidet. Die Verwendung von SOA-Komponenten ermöglicht die einfachere Implementierung und Weiterentwicklung einen solchen Ansatzes als ein proprietäres System.

IT- und Geschäftsabteilungen gemeinsam zum Erfolg

Für eine erfolgreiche SOA-Einführung und -Weiterentwicklung ist eine Partnerschaft zwischen den Technik- und Geschäftsabteilungen von entscheidender Bedeutung. Die Grundlage dieser Beziehung bildet die Möglichkeit der IT-Abteilung, das Geschäft sowohl bezüglich seiner Wettbewerbsfähigkeit als auch bei der schnellen Implementierung neuer Geschäftsmodelle wie Distributionskanäle, neuer Produkte für Informationsservices oder neuer Preismodelle zu unterstützen – und all dies bei sich stetig verbessernden Metriken für Profitabilität und Kundenzufriedenheit.

Weiterhin hängt der Erfolg einer SOA-Implementierung in hohem Maße davon ab, mit welcher Methodik und Striktheit es vorgeht, um sich auf das höchste Reifelevel weiter zu entwickeln – sei es mit unternehmensinternen Kapazitäten oder auf dem schnellen Weg über einen Systemintegrator.

Hub Vandervoort ist Chief Technology Officer (CTO) bei Sonic Software und hat mehr als zwanzig Jahre Erfahrung als Berater und Senior Technology Executive in der Networking-, Kommunikationssoftware- und Internet-Industrie.
Geschrieben von
Hub Vandervoort
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.