Whitepaper Kosteneffizienz durch Innovation von - NTT Data

Kosteneffizienz durch Innovation von Integrationsinfrastruktur. Wo liegen die Potenziale?

Autoren:

Stefan Kohlmann SOA Architect [email protected] Martin Landua Principal Architect [email protected] Christian Cohnen Senior Managing Consultant [email protected]

Erschienen im: August 2012

mailto:[email protected]

© NTT DATA Deutschland 1 / 28

Inhalt

1 Abstract ................................................................................................................................... 2

2 Einleitung ................................................................................................................................ 4 2.1 Handlungsfelder zur Effizienzsteigerung .............................................................................. 4 2.2 Das Interesse an Integrationslösungen ist ungebrochen...................................................... 5 2.3 Schlüsseltechnologien zur Modernisierung der Integrationsinfrastruktur .............................. 5 2.3.1 Der Enterprise Service Bus als Fundament der Integrationsinfrastruktur......................... 6 2.3.2 Automatisierte Steuerung von Geschäftsprozessen ........................................................ 7 2.4 Ausgangspunkte für die Modernisierung der Infrastruktur .................................................... 9 2.4.1 Initiale Einführung einer Integrationsinfrastruktur ............................................................ 9 2.4.2 Optimierung und Ausbau bestehender Integrationsinfrastrukturen .................................. 9 2.4.3 Neue Versionen der Integrationsinfrastruktur von Produktherstellern ............................ 10 2.4.4 In welchen Fällen bringt eine neue Infrastruktur wenig Nutzen ...................................... 10 2.4.5 Innovationsprojekte und der Fachbereich ...................................................................... 11 2.5 NTT DATA Praxisbeispiel einer erfolgreichen Prozessautomatisierung ............................. 11

3 NTT DATA Praxiserfahrungen mit Integrationsinfrastrukturen ............................................... 13 3.1 Integrationsinfrastrukturen führender Produkthersteller ..................................................... 13 3.1.1 Oracle SOA Suite 11g ................................................................................................... 13 3.1.2 Die TIBCO Integrationsplattform ................................................................................... 15 3.2 Open Source Lösungen als Bausteine moderner Integrationsinfrastrukturen ..................... 16 3.2.1 Neue Geschäftsmodelle erleichtern den produktiven Einsatz ........................................ 17 3.2.2 FuseSource .................................................................................................................. 17 3.2.3 camunda fox BPM-Plattform ......................................................................................... 19

4 Wie wählt man die passenden Integrationskomponenten aus? ............................................. 21

5 Cloud Computing und Integrationsarchitekturen .................................................................... 24 5.1 Cloud Computing im Unternehmen .................................................................................... 24 5.2 Cloud Computing und Integrationsinfrastrukturen .............................................................. 24

6 Fazit ...................................................................................................................................... 26

7 NTT DATA Projektbeispiele ................................................................................................... 27

8 Über NTT DATA Deutschland ............................................................................................... 28


1 Abstract

Dieses Whitepaper zeigt auf, welche Potentiale in der Erneuerung der Integrationsinfrastruktur liegen. Es bietet eine Entscheidungshilfe für die Strategie zur Auswahl einer geeigneten Kom-munikationsinfrastruktur. Ein weiteres Augenmerk gilt der Abwägung zwischen Open-Source-Komponenten und der Lösungen von Produktherstellern.

Der Hype um das Architekturprinzip der Service-orientierten Architekturen (SOA) ist längst vor-bei. Die „Lessons learned“ sind in „Best Practices“ umgesetzt worden. Was bleibt ist die Frage „Wo liegen weitere Potenziale?“.

Abbildung 1: Kosteneffizienz durch Innovation der Integrationsinfrastruktur

Unbestritten ist, dass eine Auflösung der oftmals noch häufig anzutreffenden direkten Kopplun-gen durch einen Enterprise Service Bus (ESB) ein wichtiger erster Schritt ist, um den Weg für das Business-Prozess-Management frei zu machen. BPM Engines zur Abarbeitung und Auto-matisierung von Geschäftsprozessen haben an Reife gewonnen. Kennzahlen, die bei der Aus-führung automatisierter Geschäftsprozesse ermittelt werden, können komfortabel und aktuell mit Hilfe von Business Activity Monitoring ausgewertet werden.


Es gibt unterschiedliche Ausgangssituationen für die Erneuerung von Integrationsinfrastruktu-ren, die verschiedene Potenziale bergen:

Das Geschäftsfeld befindet sich in regem Wandel, die Systeme sind aber noch eng ge-koppelt. In diesem Fall müssen abteilungsübergreifende Prozesse definiert und eine zu-kunftsträchtige Integrationsinfrastruktur mit lose gekoppelten Systemen aufgebaut wer-den.

Ist eine Service-orientierte Architektur bereits vorhanden und die ersten Services erfolg-reich produktiv gesetzt, gilt es weitere Optimierungspotentiale gemäß der Best-Practices von erfahrenen Spezialisten umzusetzen. Solche Potentiale bieten sich zum Beispiel in der Prozessautomatisierung, gemäß der Best-Practices von erfahrenen Spezialisten umzusetzen.

Die während der Einführung der ersten Service-orientierten Systeme eingesetzten Integ-rationskomponenten sind nicht mehr State-of-the-art und müssen ersetzt werden. Hier stellt sich zwangsläufig die Frage, in wie weit Open-Source-Komponenten verwendet werden können.

Allen diesen Potenzialen gemeinsam ist die Fokussierung auf entkoppelte Systeme und darauf aufbauend die Geschäftsprozessautomatisierung. Sind die ersten Geschäftsprozesse automati-siert, liefern Statistikdaten aus den ausgeführten Instanzen die Grundlage für eine Geschäfts-prozessoptimierung durch den Fachbereich. Einhergehend mit dieser Strategie ist die Auswahl einer zukunftssicheren und in die Unternehmenslandschaft passenden Infrastruktur ein ent-scheidender Erfolgsfaktor.

Wenn es um die Kosten bei der Erneuerung einer Integrationsinfrastruktur geht, darf der Aus-blick auf das Thema Cloud Computing nicht fehlen. Gilt es große CRM- oder ERP-Systeme einzuführen, sind nicht nur die Kosten für die Entwicklung und Einführung dieser Systeme zu sehen, sondern vor allem auch die Kosten pro Anwender im laufenden Betrieb.

Cloud Computing, das sich, im Gegensatz zu reinen On-Demand-Lösungen nicht auf die Virtua-lisierung bestimmter Anwendungen (z.B. CRM) beschränkt, sondern die IT-Infrastruktur selbst skalierbar macht, verspricht Kosten pro Nutzer und Jahr, die mit reinen On-Demand-Lösungen, auch als Software as a Service, (SaaS) bezeichnet, nicht erreichbar sind. Cloud Computing verspricht durch seine flexible, skalierbare IT-Infrastruktur eine sehr schnelle Anpassung an veränderte Marktsituationen. Der Hebel für die Kosteneffizienz lässt sich bei der Infrastruktur und beim Betrieb der Systeme ansetzen.

Bei unternehmenskritischen Daten und Anwendungen ist die Auswahl der richtigen Cloud-Strategie ein sehr sensibles Thema. Neben der Verfügbarkeit der Anwendungen sind insbeson-dere der Datenschutz und die Datensicherheit als Auswahlkriterien relevant.

Dafür bieten heute die großen Anbieter von Cloud-Diensten ein ganzes Spektrum an Lösungen, wie z.B. die „private Cloud“ und „Platform as a Service“ (PaaS) an, die auf die aktuellen Bedürf-nisse des Marktes zugeschnitten sind.

Ein Ausblick auf die Potenziale, die sich aus der Auslagerung der Infrastruktur in eine Cloud-Lösung ergeben, rundet dieses White Paper ab.


2 Einleitung

Klassische IT-Integrationsinfrastrukturen haben einen großen Beitrag zur Entkopplung von IT-Systemen geleistet - und sie besser betreibbar, wartbar und erweiterbar gemacht. Dennoch ist die Komplexität solcher Landschaften groß. Die Entkopplung der IT-Systeme ist nach wie vor nicht weit genug fortgeschritten, vor allem durch die vielen Punkt-zu-Punkt-Verbindungen und unterschiedlichen Transportmechanismen.

Die Kosten für die Weiterentwicklung, Wartung und den Betrieb bestehender Systeme steigen mit jeder weiteren Anforderung an diese. Jedes neu in die Systemlandschaft zu integrierende System erhöht die Komplexität bei Rollout und Betrieb des Gesamtsystems. Die vielen direkten Punkt zu Punkt Verbindungen fordern hier ihren Tribut.

In einem sich ständig wandelnden Geschäftsumfeld mit Produktinnovationen und Unterneh-menszusammenschlüssen ist die von den Fachbereichen benötigte Flexibilität der IT-Systeme oftmals noch nicht gegeben. Viele Management-Initiativen, die die Effektivität und Effizienz im Unternehmen steigern sollen, werden von der bestehenden IT-Landschaft noch nicht in vollem Umfang unterstützt.

Potentiale liegen darin, Tätigkeiten zu steuern, die sich am Fachprozess orientieren und in der Automatisierung von monotonen manuellen Tätigkeiten: Sie sind noch häufig ungenutzt.

Jetzt ist der richtige Zeitpunkt, eine Renovierung der Integrationsinfrastruktur anzugehen. Die großen Produkthersteller bieten ein reichhaltiges Angebot an Integrationskomponenten, die in den letzten Jahren mit dem Bedarf in den Fachbereichen und IT-Abteilungen gereift sind.

Die Open Source Community bietet ebenfalls ein weitgefächertes Spektrum an Integrationslö-sungen, die sich schon lange im produktiven Einsatz bewährt haben.

2.1 Handlungsfelder zur Effizienzsteigerung

Im Fokus vieler Projekte bei Enterprise-Systemen steht die Steigerung von Effektivität und Effi-zienz. Eine moderne Integrationsinfrastruktur leistet einen entscheidenden Beitrag dazu:

Time To Market Wenn es um Time To Market geht, dann ist die Flexibilität und Standardisierung von IT-Lösungen gefragt. Die Wiederverwendung von Funktionalitäten in Form standardisierter Prozesse in einer BPM-Infrastruktur und Services in Form fachlicher Objekte in einem ESB verringert den Aufwand, neue Geschäftsideen umzusetzen.

Transparenz Die Transparenz der Abläufe und Bearbeitungsdauer von Aktivitäten und Prozessschrit-ten ist die Grundlage, um Geschäftsprozesse zu optimieren. Die von einer Business Prozess Engine gesteuerten Aktivitäten liefern die Datengrundlage für Geschäftsprozess relevante KPIs. Das Business Activity Monitoring und damit die Sicht auf die Geschäftsprozessabläufe in Echtzeit (Realtime) erlaubt eine sehr schnelle Reaktion auf rege Veränderungen im Ge-schäftsfeld.

Qualität Unter Qualitätsgesichtspunkten sollen Fehler vermieden werden und die Datenkonsis-tenz gesichert sein. Interne und externe Service Level Agreements (SLA) einzuhalten ist Voraussetzung für die Qualität der erbrachten Dienstleistungen. Fehler können durch Automatisierung der Geschäftsprozesse in BPM-Infrastrukturen vermieden werden. Durch das Monitoring auf Service-Ebene und die Echtzeitüberwachung der Service-Infrastruktur ist die Einhaltung von SLAs überprüfbar.


Automatisierung Gelingt es - durch den Einsatz von BPM-Infrastrukturen - anspruchslose manuelle Tätig-keiten zu automatisieren, dann führt das zu einer Effizienzsteigerung in zweierlei Hin-sicht. Mitarbeiter können anspruchsvollere und abwechslungsreichere Tätigkeiten über-nehmen. Und durch die Automatisierung erreicht man ein gleichmäßig hohes Qualitäts-niveau in optimaler Prozess-Durchlaufzeit.

Value Chain Bei der Value Chain steht die nahtlose Einbindung von externen Lieferanten und Dienst-leistern in die eigenen Geschäftsprozesse im Vordergrund. Hier spielen der Datenaus-tausch und standardisierte Services eine entscheidende Rolle. Bei dieser Einbindung gilt es, einen hohen Automatisierungsgrad unter Einhaltung der vereinbarten Qualitäts- und Durchsatzziele (SLA-Überwachung) zu erreichen. Eine ESB-Infrastruktur spielt hier ihre Vorteile aus.

Diese Optimierungspotentiale lassen sich mit einer modernen Integrationsinfrastruktur, die auf geeigneten, aufeinander aufbauenden Komponenten beruht, voll ausschöpfen.

2.2 Das Interesse an Integrationslösungen ist ungebrochen

Das Interesse an Infrastrukturkomponenten zur Entkopplung der IT-Systeme (Enterprise Ser-vice Bus) und zur Business-Prozess-Automatisierung (BPM Engines) ist nach wie vor ungebro-chen.

Aktuelle Studien z.B. „The Forrester Wave™: Enterprise Service Bus, Q2 2011” zeigen: Nur für 10% der befragten Enterprise Architekten und Manager aus dem Bereich der Anwendungsent-wicklung sei das Thema Enterprise Service Bus in ihrem Unternehmen nicht interessant, bzw. sie haben sich mit der Frage, ob ein ESB in ihrem Unternehmen relevant sein könnte, noch gar nicht auseinandergesetzt haben.

Etwa ein Drittel der Befragten gab jedoch an, einen ESB im Einsatz zu haben und derzeit dabei zu sein, diesen zu erweitern oder zu erneuern.

Interessant ist auch die Aussage, wofür der ESB in den Unternehmen eingesetzt wird. Ein wich-tiges Einsatzgebiet des ESB ist demnach das Routing und Messaging sowie die Datentrans-formation (jeweils über 90% der Nennungen). Das ist nicht verwunderlich, da dies die zentralen Disziplinen eines ESB sind.

Nur etwas mehr als ein Drittel der Befragten (35%) gab an, den ESB zur Erstellung von Ser-vices zu verwenden. Noch geringer (28%) war der Anteil derjenigen, die den ESB für die Or-chestrierung von Services verwenden.

Dieses Ergebnis mag den Schluss nahelegen, dass die Erstellung und Orchestrierung von Ser-vices weniger wichtig ist und im SOA Hype überbewertet wurde. Das Gegenteil ist richtig. In der Bereitstellung und Orchestrierung von Services zur Wiederverwendung in unterschiedlichen Kontexten liegt ein wichtiges Potenzial zur Steigerung der Effektivität. Dieses Potenzial ist in weiten Teilen noch ungenutzt.

2.3 Schlüsseltechnologien zur Modernisierung der Integrationsinfrastruktur

Eine moderne Integrationsinfrastruktur erreicht man klassischerweise durch eine auf mehrere Schichten verteilte Komponentenhierarchie, wie sie exemplarisch in Abbildung 2 dargestellt ist.


Abbildung 2: Komponenten einer Integrationsinfrastruktur

Die Basiskomponenten dieser Integrationsinfrastruktur sind der Enterprise Service Bus (ESB) und ein System zur Steuerung und Automatisierung von Business Prozessen (BPM Engine).

2.3.1 Der Enterprise Service Bus als Fundament der Integrationsinfrastruktur

Das Fundament einer modernen Kommunikationsinfrastruktur ist nach wie vor ein ESB. Er bie-tet die Basis für automatisierte Business-Prozesse und den Zugriff auf aktuelle Unternehmens-daten aus unterschiedlichen Kontexten.

Die wichtigsten Funktionalitätsbereiche des ESBs sind:

Bereitstellung einer auf Standards basierenden Kommunikationsplattform für Service-Anbieter und Service-Nutzer

Bereitstellung von Adaptoren zur nahtlosen Integration unterschiedlicher Ressourcen und Anwendungen

Transformation und Anreicherung (enrichment) von Daten beim Datenaustausch zwi-schen Service-Anbieter und Service-Nutzer

Von Nachrichteninhalten abhängige Weiterleitung von Daten (content based routing).

Ein Enterprise Service Bus stellt in erster Linie eine Plattform zum Datenaustausch zwischen einem Service-Anbieter und Service-Nutzer zur Verfügung. Der Service-Nutzer muss hierbei den Service-Anbieter nicht direkt adressieren. Die Systeme sind also mit Hilfe des ESB nur lose gekoppelt.

SAP ServiceORACLE DB

ServiceSibel Service Host ServiceService Schicht / ESB

Backend SystemeStandardanwendungen und Datenbanken

Lose Kopplung durch wiederverwendbare Services

Anwendungs- und Interaktionsschicht

spezifische Benutzeroberflächen für unterschiedliche Zielgruppen

Prozess Schicht / BPMAblauffähige Geschäftsprozesse


Diese lose Kopplung ist für die weitere IT-Strategie ein wichtiger Aspekt. Hierdurch wird der Austausch des Service-Anbieters ermöglicht, ohne die Service-Nutzer anzupassen.

Ein weiteres wichtiges Merkmal eines ESB sind die zur Verfügung stehenden Adaptoren zur Integration fachlich und technologisch heterogener Systeme. Sie ermöglichen z.B. die Integrati-on von Legacy Systemen in die neue Kommunikationsinfrastruktur, ohne dass die zugrunde liegenden Protokolle und Hostsysteme direkt adressiert werden müssen.

Die Schnittstelle, die der ESB dem Service-Nutzer bietet, ist fachlich geprägt und muss nicht der Schnittstelle des Service-Anbieters entsprechen. Hier kommt eine weitere wesentliche Ei-genschaft des ESB zum Tragen. Die Service-Anfragen werden vom ESB in das jeweilige Ziel-format transformiert. Das erleichtert den Austausch der Service-Anbieter, da nur die Transfor-mation vom fachlich geprägten internen Datenmodell zum Service-Anbieter angepasst werden muss.

Ein ESB sollte auch die Möglichkeit der Datenanreicherung (Enrichment) bieten. Ein Service-Anbieter kann dann mit neuen Funktionalitäten ausgestattet werden, ohne dass die Service-Nutzer zusätzliche Daten bereitstellen müssen. Der Service-Nutzer muss also nicht im selben Release angepasst und ausgerollt werden, wie der Service-Anbieter. Das reduziert die Komple-xität der Einführung neuer Funktionalität auf der Service-Anbieterseite erheblich. Die in der neuen Schnittstelle fehlenden Daten können vom ESB ermittelt und eingesteuert werden. Ist diese Anreicherung nicht möglich, so kann der ESB die Nachricht für den Aufrufer transparent an die vorherige Version des Services weiterleiten. Neue Services können aber die neuen Funktionalitäten bereits uneingeschränkt nutzen.

Ein Integrationsszenario, das durch den Einsatz eines ESB vereinfacht wird, ist die Anbindung weiterer gleichartiger Dienstanbieter. Beispielsweise können beim Zusammenschluss von Un-ternehmen die bestehenden Systeme mit ähnlicher Funktionalität leichter integriert und zu ei-nem späteren Zeitpunkt vereinheitlicht werden.

Wird ein neuer Dienstanbieter in die Wertschöpfungskette integriert, so kann dieser leichter und ohne Anpassung der Konsumenten integriert werden, wenn die gewünschte Funktionalität schon in Form eines Services gekapselt ist.

Der ESB ist die zentrale Stelle für den Service-Aufruf aus unterschiedlichen Anwendungen und Eingangskanälen. Deshalb können hier auch die für den Betrieb und die Überwachung des Sys-tems notwendigen Daten für das Monitoring des Systems zentral ermittelt werden. Aus den hier ermittelten Daten lassen sich aggregierte Zahlen ermitteln, um die Einhaltung von SLAs zu überwachen.

2.3.2 Automatisierte Steuerung von Geschäftsprozessen

Wie eingangs erwähnt, belegen aktuelle Studien das ungenutzte Potenzial bei der Service-Orchestrierung und der Automatisierung von Geschäftsprozessen. In den SOA-Reifegradmodellen (SOA Maturity Models z.B. in http://soablueprint.com/maturity_models) steht die automatisierte Steuerung von Geschäftsprozessen an oberster Stelle. Das bedeutet, dass erst durch automatisierte Geschäftsprozesse der Nutzen einer Service-orientierten Architektur voll ausgeschöpft wird und damit das Unternehmen einen hohen SOA-Reifegrad erreicht.

Automatisierte Geschäftsprozesse leisten ihren Beitrag zu effizienteren Unternehmen in vielfa-cher Weise:

Geschäftsregeln und Prozesse werden direkt in ausführbare Software abgebildet. Dadurch ist sichergestellt, dass alle Fälle gleichartig in optimaler Geschwindigkeit und Qualität ausgeführt werden.

http://soablueprint.com/maturity_models


Durch eine Teilautomatisierung und eine zielgerichtete Prozesssteuerung kann die Auslastung der Mitarbeiter optimiert werden. Das steigert die Qualität des Gesamtprozesses in mehrfacher Weise. Die Mitarbeiter werden von einfachen manuellen Tätigkeiten entlastet und können sich damit auf anspruchsvollere, nicht automatisierbare Tätigkeiten und Sonderfälle konzentrieren.

Durch Fristüberwachung und Eskalationsmechanismen ist sichergestellt, dass vereinbarte Qua-litäts- und Durchsatzziele erreicht werden. Engpässe werden frühzeitig erkannt und es kann den zugrunde liegenden Ursachen schnell gegengesteuert werden. Außerdem können rechtzei-tig Maßnahmen zur Kompensation der Verzögerung eingeleitet werden.

Die Automatisierung von Geschäftsprozessen ist auch die Grundlage für Business Activity Mo-nitoring (BAM). Die KPIs können an geeigneter Stelle direkt ermittelt werden. Die Auswertung der Prozessdurchlaufzeiten und der ermittelten Kennzahlen bieten die Grundlage für eine Ge-schäftsprozessoptimierung.

Ein automatisierter Geschäftsprozess baut auf Services auf, die von einem ESB bereitgestellt werden. Da die einzelnen Prozessinstanzen, und damit die Aufrufketten der Service-Aufrufe, anhand von fachlichen Schlüsseln ermittelt werden können, wird der fachliche Support in einer komplexen Systemlandschaft vereinfacht.

Um den Zugriff auf Service-Instanzen über den fachlichen Schlüssel und technische IDs zu er-möglichen, muss diese Anforderung schon bei der Modellierung der Services berücksichtigt werden. Mit Hilfe von Modellierungskonventionen wird dafür gesorgt, dass alle Services ein standardisiertes Format bezüglich der Schnittstellen und Protokollierung haben.

Zur Automatisierung von Geschäftsprozessen eignen sich unterschiedlichen Technologien die miteinander verwandt, technologisch aber unterschiedlich ausgeprägt sind und den folgenden Abschnitten kurz charakterisiert werden.

2.3.2.1 Service Orchestrierung

Das Architektur-Paradigma von Service-orientierten Architekturen fand auch deshalb eine breite Unterstützung bei den Enterprise-Architekten, weil die einzelnen Services zu höherwertigen Services und Teilprozessen zusammengesetzt werden können. Die bei dieser Orchestrierung entstandenen Services sind selbst wieder als Services in anderen Kontexten nutzbar.

Die XML basierende Programmiersprache, die hier Verwendung findet ist Business Process Execution Language (BPEL). BPEL unterstützt in besonderem Maße die Orchestrierung von Webservices. Der so orchestrierte Service bietet wiederum eine Webservice-Schnittstelle.

Mit Hilfe von asynchronen Service-Aufrufen sind auch lang laufende Services modellierbar. Durch die später erfolgte Standardisierung der Schnittstelle zur manuellen Bearbeitung (WS-HumanTask, BPEL4People,…) steht das Handwerkszeug zur Integration von manuellen Aktivi-täten als Teilschritt eines Services zur Verfügung und somit ist die Brücke zum ausführbaren Prozess geschlagen.

2.3.2.2 BPM Engines unterstützen die Automatisierung von Fachprozessen

Wesentlich für die Automatisierung und zielgerichteten Steuerung von Geschäftsprozessen sind aber die BPM Engines (Business Process Management Engines). Die Geschäftsprozesse sind in einer Granularität modelliert, die maßgeblich vom fachlichen Geschäftsprozess geprägt ist. Als Modellierungssprache wird oftmals die unter Business-Analysten und Prozessverantwortli-chen häufig eingesetzte Business Process Modelling Notation (BPMN) verwendet. Zumeist können die zugrunde liegenden BPM Engines BPMN direkt interpretieren. Die so modellierten Prozesse sind konzeptionell auf lang laufende Instanzen mit Benutzerinteraktion ausgelegt. Die in der Welt der Business-Prozess-Automatisierung klassischen Funktionalitäten wie 4-Augen


Prinzip, Weiterleitung und Wiedervorlage von Fällen sowie die Eskalation von nicht fristgerecht abgearbeiteten Fällen sind eine Domäne der BPM Engines.

Die bei der Modellierung von Geschäftsprozessen gewählte Granularität ist oftmals so gewählt, dass sich die Ableitung wesentlicher Kennzahlen direkt aus den Modellen ergibt.

Dabei sollte nicht davon ausgegangen werden, dass jedes BPMN-Modell auf jeder BPMN-Engine gleichermaßen ausgeführt werden kann. Die BPMN-Sprache geht zwar genau auf die Business-Prozessmodellierung ein, ist aber relativ unspezifisch bezüglich deren Implementie-rung. Das führt zu einem gewissen Maß an Abhängigkeit zur ausgewählten BPMN-Engine.

Weiterhin ist die technische Ausführungssicht auf einen Business-Prozess üblicherweise eine ganz andere Sicht auf den Prozess, als die rein fachliche Sicht. Das führt dazu, dass das fachli-che BPMN-Modell von SOA-Architekten um technische Belange erweitert werden muss. Um diese beiden Sichten synchron zu halten, ist ein gewisser Aufwand notwendig. Hersteller von BPMN-Modellierungswerkzeugen haben das Problem erkannt und bieten hierzu bereits unter-schiedliche Lösungen an, deren Praxistauglichkeit sich aber erst in Zusammenarbeit mit dem Fachbereich zeigen muss.

2.4 Ausgangspunkte für die Modernisierung der Infrastruktur

Aus IT-technischer Sicht sind die Gründe für eine erneuerte Integrationsinfrastruktur vielfältig. Die wichtigsten Gründe sind

Die initiale Einführung einer Integrationsinfrastruktur

Die Optimierung und der Ausbau bestehender Integrationsinfrastrukturen

Die Migration auf eine neue Version der Integrationsinfrastruktur

Die folgenden Abschnitte beschreiben für diese Gründe die jeweiligen Ausgangssituationen, Ziele und Herausforderungen.

2.4.1 Initiale Einführung einer Integrationsinfrastruktur

Wenn sich das Geschäftsfeld in regem Wandel befindet, aber die IT-Systeme noch eng gekop-pelt sind, ist jetzt der richtige Zeitpunkt um eine neue Integrationsinfrastruktur einzuführen. Oft-mals werden Daten redundant gehalten und die Weiterentwicklung und der Betrieb der Be-standssoftware verschlingen einen großen Teil des IT-Budgets.

In dieser Situation hat man große Freiheiten und kann von den Best-Practices am Markt profi-tieren. Allerdings sind hier auch die größten finanziellen, technologischen und organisatorischen Herausforderungen zu meistern.

Das Ziel bei diesem Szenario ist, eine zukunftsträchtige IT Architektur aufzubauen und die zur Unternehmenskultur passenden Integrationskomponenten auszuwählen. Wenn die anwen-dungs- und abteilungsübergreifenden fachlichen Prozesse festgelegt sind, können die neuen Integrations- und Prozessautomatisierungskomponenten schrittweise eingeführt werden.

Um dabei zielgerichtet zum Erfolg zu kommen, muss auf organisatorischer Seite das prozess-orientierte Denken gefördert und das „Silo“-Denken abgebaut werden. Im Einsatz von moder-nen Integrationskomponenten erfahrene Experten müssen die richtige IT-Architektur konzipie-ren und die dafür passenden Integrationskomponenten eruieren.

2.4.2 Optimierung und Ausbau bestehender Integrationsinfrastrukturen

Ist eine Integrationsinfrastruktur bereits erfolgreich im Einsatz und sind ausreichend positive Erfahrungen mit dieser Infrastruktur gesammelt, sind die Optimierung und Weiterentwicklung der Integrationsplattform die konsequenten nächsten Schritte.


In der Praxis haben sich die Optimierungspotenziale im laufenden Betrieb einer Integrationsinf-rastruktur schnell gezeigt. Das technische Monitoring der Integrationsinfrastruktur ist im Allge-meinen standardmäßig bereits umgesetzt. Damit der Betrieb die Fachbereiche noch besser pro-aktiv unterstützen kann, ist ein fachliches Monitoring wichtig.

Für den Support der Fachbereiche in einer entkoppelten Systemumgebung ist aber auch die Verknüpfung von fachlichen Schlüsseln zu Prozess- und Service-Aufrufen notwendig. Damit der Betrieb über die zeitliche Abfolge und vor allem über die Ursache der konkreten Klärungsfälle auskunftsfähig ist, müssen alle mit diesem fachlichen Schlüssel im fachlichen Prozess ausge-führten Aktionen zentral abrufbar sein, ohne hierzu explizit alle beteiligten Systeme nach dem fachlichen Schlüssel durchsuchen zu müssen.

Nicht nur der Betrieb der Integrationsinfrastruktur bietet Optimierungspotential. Die bestehende Integrationsinfrastruktur bietet die Basis für die Steuerung und Optimierung von Geschäftspro-zessen. Das fachliche Monitoring kann auf Geschäftsprozessebene ausgebaut werden und ist somit die Grundlage für eine Schwachstellenanalyse im Geschäftsprozessablauf.

2.4.3 Neue Versionen der Integrationsinfrastruktur von Produktherstellern

Die führenden Hersteller von Integrationsinfrastruktur-Komponenten erneuern ihre Produktpa-lette kontinuierlich. Neue Releases der Produkthersteller versprechen zusätzliches Potential. Spätestens wenn die Supportverträge der Basis-Software auslaufen, muss eine Migration ein-geplant werden.

IT-Abteilungen, die Service-orientierte Infrastrukturkomponenten schon jahrelang erfolgreich produktiv einsetzen, stehen jetzt vor der Fragestellung, wann sie auf neue Versionen der Pro-dukthersteller aktualisieren sollen. Bei der Frage, ob Open Source Software eine Alternative zu den angestammten Produkten der großen Hersteller sein kann, spielt neben den Kosten für Software-Lizenzen und Wartung auch der Migrationsaufwand eine nicht zu unterschätzende Rolle.

Je leichter die Migration bestehender Services auf eine neue Integrationsinfrastruktur ist, desto leichter fällt die Entscheidung für das neue Release der Produkthersteller. Umgekehrt gilt auch, dass für den Fall, dass die Migration auf ein neues Release große Probleme bereitet, der Um-stieg auf Open Source Lösungen eine ernstzunehmende Alternative darstellt.

Positiv ist, dass die möglichen Optionen für die Auswahl der Komponenten für zukünftige Integ-rationsinfrastruktur mannigfaltiger geworden sind. Um die Optionen zu bewerten, sind Experten gefragt, die sowohl die Lösungen führender Produkthersteller als auch die Lösungen der viel-versprechendsten Open-Source-Projekte beherrschen. Mit deren Hilfe gilt es einen Auswahlka-talog zu definieren, der sicherstellt, dass die Zielplattform tatsächlich zum Unternehmen passt. Hierbei ist nicht nur der finanzielle Aspekt zu betrachten, sondern vor allem auch die Unterneh-mensphilosophie und mittel- und langfristige IT-Strategie des Unternehmens.

Unabhängig von der Auswahl der Komponenten muss sich die neue Integrationslösung nahtlos in die bestehende Systemlandschaft integrieren. Ist eine Migration notwendig, so ist das ein Projekt mit besonderen Herausforderungen, für die es praxiserprobte Lösungen für unterneh-menskritische Migrationsprojekte gibt. Ein tragfähiges und erprobtes Migrationskonzept ist hier-für aber unabdingbar.

2.4.4 In welchen Fällen bringt eine neue Infrastruktur wenig Nutzen

Die Einführung einer modernen Integrationsinfrastruktur ist nicht immer notwendig oder gar sinnvoll. Geht es darum, Daten nahezu in Echtzeit zu übertragen, dann wird man die Systeme nicht über eine zusätzliche Integrationskomponente entkoppeln. Hier sind enge, hochperfor-mante Kopplungen gefragt.


Beispiele für solche Systeme, die aus Performance-Gründen eng gekoppelt sind, gibt es viele. Im Telekommunikations-Bereich ist das beispielsweise die Verarbeitung von Verbrauchsdaten wie Call Data Records.

Aber auch die Stammdatensynchronisation in größerem Umfang ist nicht unbedingt ein Kandi-dat für eine prozessgesteuerte Automatisierung. Wenn es nur darum geht, Änderungen an Stammdaten in andere Systeme zu verteilen, ist eine Prozesssteuerung sicher machbar und auch schon erfolgreich umgesetzt. Problematisch wird dieser Weg, wenn es um die erstmalige Übertragung der Stammdaten geht. Auch die häufig notwendige Batch-gesteuerte Aktualisie-rung der Stammdaten, z.B. bei Einführung der internationalen Bankkontonummer (IBAN) ist kein Kandidat für eine Prozess-gesteuerte Übertragung. Es handelt sich bei diesen Beispielen um einmalige Aktionen in großen Datenbeständen. Der Kommunikationsoverhead ist in diesen Fällen viel zu hoch, so dass die Daten nicht in einem ausreichenden Zeitfenster aktualisiert werden können.

Für Datenbank-basierte Stammdatensynchronisationen eignen sich performance-optimierte Datenbankmechanismen - z.B. Bacht gesteuerte SQL Loader oder einfache Update-Skripts - deutlich besser. Für eine Massendatenverarbeitung ist der Verarbeitungsaufwand pro Daten-satz einfach zu hoch.

Klassische ETL (extract, transform, load) Verarbeitung wird durch SOA also nicht obsolet, viel-mehr ist sie eine sinnvolle und notwendige Ergänzung zu Service-orientierten Architektur.

2.4.5 Innovationsprojekte und der Fachbereich

Eine Modernisierung der Integrationsinfrastruktur ist immer dann sinnvoll, wenn bestehende Infrastrukturen den Anforderungen an eine moderne Enterprise-Architektur nicht mehr genügen. Wie so oft unterscheidet sich hier die IT-Sicht von der Sicht der Fachbereiche. Projekte, die die Modernisierung der Integrationsinfrastruktur zum Ziel haben, werden im Allgemeinen immer niedriger priorisiert, da der direkte Nutzen für die Fachbereiche nicht unmittelbar offensichtlich ist.

Bei der Einführung eines Enterprise Service Busses wurden Kosten-/Nutzenanalysen durchge-führt. Die Nutzenseite fiel bei diesen Analysen oft zu positiv aus, da der Aufwand und die Lern-effekte für die Einführung einer modernen Integrationsinfrastruktur und für die Entwicklung und den Betrieb der Software unterschätzt wurden. Häufig wurde nach der Einführung eines ESB keine nachgelagerte Kosten-/Nutzenanalyse durchgeführt und so blieb der tatsächliche Nutzen für die Fachbereiche eine vage Hoffnung.

Beim nächsten Schritt in Richtung Prozessautomatisierung ist es leichter, die Fachbereiche ins Boot zu holen. Der Nutzen lässt sich an Kennzahlen belegen, die den Fachbereichen einen direkten Vorteil bringen und die Verbesserungen unmittelbar zeigen. An diesen Kennzahlen kann der Projekterfolg direkt gemessen werden.

2.5 NTT DATA Praxisbeispiel einer erfolgreichen Prozessautomatisierung

Oftmals werden ganze fachliche Prozesse weitgehend automatisiert, z.B. der Order Manage-ment Prozess. Dass eine Einführung von Service-orientierten Architekturen auch auf Abtei-lungsebene sinnvoll sein kann und Prozessoptimierung auch von Teilprozessen einen messba-ren Vorteil für den Fachbereich bringen kann, zeigt das folgende Beispiel bei einem Telekom-munikationsunternehmen.

Eine Studie zu den Potentialen der Einführung einer SOA-Infrastruktur und ein engagierter Chef-Architekt gaben den Ausschlag zur Einführung eines BPM/ESB Systems. In einem ersten Schritt wurde ein Pilot-Service zur Provisionierung von Telefonanschlüssen eingeführt.


ESB-Services und die Service-Orchestrierung wurden parallel umgesetzt. Obwohl in diesem ersten Schritt nur Services mit Fokus auf den Pilotprozess umgesetzt wurden, entstanden be-reits einige wiederverwendbare Services.

In einem zweiten Schritt wurde ein Prozess zur automatisierten Verarbeitung von Portierungs-rückmeldungen automatisiert. Dieser konnte bereits auf die benötigten Basis-Services zugrei-fen, was den Implementierungsaufwand in diesem Fall bereits merklich reduzierte.

Als KPI wurde die Prozentzahl der automatisiert verarbeiteten Portierungsrückmeldungen fest-gelegt und überwacht. Der Automatisierungsgrad lag anfangs bei knapp 80 %, was in etwa dem erwarteten Ergebnis entsprach. Die Bedingungen, die dazu führten, dass eine Rückmeldung nicht automatisch verarbeitet werden konnte, wurden mit Hilfe entsprechender Sensoren im ausführbaren Prozessmodell überwacht. Die Auswertung der Sensoren erfolgte aggregiert über Business Activity Monitoring.

Das Monitoring wurde nicht über eine BAM-Oberfläche, sondern über dynamische Wiki-Seiten implementiert, da eine Korrelation dieser Information mit anderen Ereignissen und Datenquellen nicht notwendig war.

Das Business Activity Monitoring zeigte deutlich, dass der überwiegende Teil der nicht automa-tisierbaren Fälle auf eine fachliche Bedingung zurückzuführen war. Die Bedingung besagte, dass kein IP-Serviceauftrag länger als 3 Monate offen sein darf. Das Portierungsdatum bei ca. 80 % der Fälle, die nicht automatisiert verarbeitet werden konnten, lag jedoch über 3 Monate in der Zukunft.

Die manuelle Bearbeitung sah für diese Fälle vor, dass sie auf Wiedervorlage gelegt wurden und erst 10 Tage vor der tatsächlichen Portierung ein IP-Serviceauftrag eingestellt wurde. Das Optimierungspotenzial wurde dadurch umgesetzt, dass die Schnittstelle Richtung des CRM-Systems so ausgebaut wurde, dass für den Fall, dass das Portierungsdatum mehr als 3 Monate in Zukunft liegt, diese Portierungsaufträge automatisiert auf Wiedervorlage gelegt wurden. Der fachliche Prozess musste ebenfalls geringfügig angepasst werden. Das wurde durch den nun erzielten Automatisierungsgrad von mehr als 95 % mehr als wettgemacht.

Auch der Betrieb der Service-orientierten Infrastruktur über eine Administrationsoberfläche und mit Hilfe von dynamischen Wiki-Seiten, die betriebliche Informationen aggregierten, wird sehr erleichtert. Durch das betriebliche Monitoring, das u.a. den aktuellen Durchsatz und die Statistik der letzten 30 Tage sowie die Anzahl der technischen Fehler visualisiert, können technische Probleme aktiv angegangen werden.

Fälle, die über den Second-Level-Support zum SOA-Betrieb kommen, werden schnell bearbei-tet, da die entsprechende Prozessinstanz über fachliche Schlüssel gefunden und der Ablauf der Instanz in der Administrationsoberfläche grafisch dargestellt wird. Mit einem Blick ist die Ursa-che für das Problem bei diesem Fall gefunden und aus der Position im Prozessablauf lassen sich leicht die notwendigen Folgeaktionen ableiten.


3 NTT DATA Praxiserfahrungen mit Integrationsinfrastrukturen

Ein detaillierter Überblick der auf den Markt befindlichen Suiten der führenden Produkthersteller und Open-Source-Projekte würde den Rahmen dieses Whitepapers bei weitem sprengen. Des-halb sind in den folgenden Kapiteln NTT-Data-Praxiserfahrungen mit BPM-/ESB-Systemen be-schrieben, die aus erfolgreich bei unseren Kunden umgesetzten Projekten stammen. Bei diesen Erfahrungsberichten stehen nicht Funktionen der eingesetzten Systeme im Vordergrund, son-dern der praktische Nutzen, der sich beim Einsatz der Systeme in NTT-Data-Projekten als be-sonders wertvoll gezeigt hat.

Neben den wesentlichen Eigenschaften der Produkte führender Hersteller und vielversprechen-der Open-Source-Lösungen soll auch der richtige Weg zur Auswahl der passenden Software-Komponenten aufgezeigt werden.

3.1 Integrationsinfrastrukturen führender Produkthersteller

Die Funktionalität und Charakteristiken von Integrationsinfrastrukturen führender Produkther-steller soll am Beispiel der „Oracle SOA Suite 11g“ und „TIBCO Active Matrix“ dargestellt wer-den. Diese Hersteller sind mit einem umfangreichen Portfolio an Integrationsinfrastrukturen am Markt vertreten und gehören mit ihrer Strategie in diesem Bereich zu den führenden Herstellern.

3.1.1 Oracle SOA Suite 11g

Oracle war einer der ersten Produkthersteller, der 2006 mit einem kompletten Software-Paket für den Aufbau von Service-orientierten Architekturen auf den Markt kam. Neben der zu diesem Zeitpunkt schon bewährten BPEL Engine wurde ein Enterprise Service Bus und weitere wichti-ge Komponenten wie Business Rules, eine Service Registry und das Business Activity Monito-ring Teil einer integrierten Suite. Die Software-Komponenten hatten unterschiedliche Herkunft und die Integration der Komponenten war nur rudimentär gegeben.

Mit der Übernahme von BEA im Anfang 2008 kam unter anderem ein in Europa weit verbreite-ter Application Server und ein moderner Enterprise Service Bus in das Produktportfolio von Oracle. Damit war die Grundlage für eine komplett neue SOA Suite gelegt. Oracle legt, wie die folgende Grafik zeigt, mit der SOA Suite ab der Version 11g großen Wert auf die Integration der einzelnen Komponenten. Das gilt für die Infrastruktur genauso, wie für die Entwicklung und den Betrieb der Infrastruktur.


Abbildung 3: Oracle 11g Service Infrastructure (www.oracle.com)

Oracle hat mit den neu hinzugekommenen Komponenten aus dem BEA Lager einen sehr mächtigen Softwarestack für Integrationsprojekte auf den Markt gebracht. Der Fokus bei der Oracle SOA Suite liegt nicht nur in der Integration der unterschiedlichen Komponenten, sondern auch in der durchgängigen Unterstützung des Architekturprinzips Service Component Architec-ture (SCA).

Der zugrunde liegende Oracle Weblogic Server bietet eine enge Integration in Oracles Daten-Grid-Lösung Oracle Coherence zur Skalierung und Performance-Optimierung. Neue Integrati-onsumgebungen z.B. für Test und Produktion lassen sich einfach über parametrisierte Skripts innerhalb kürzester Zeit komplett neu aufsetzen. Das ist eine wichtige Voraussetzung für die Skalierbarkeit der Integrationsinfrastruktur. Das gilt im besonderen Maße auch für den Betrieb der Infrastruktur in einer Cloud.

Für die Administration und das Monitoring der SOA Suite gibt es nur noch eine zentrale Konsole mit der Möglichkeit über Composite-Sensoren gezielt nach Instanzen zu einem frei definierba-ren fachlichen Schlüssel zu suchen. Das erleichtert den 2nd Level Support der Anwendungen, die auf dieser Integrationsinfrastruktur laufen, erheblich.

Das Fault Handling Framework erlaubt die aspektorientierte Konfiguration von Aktionen, die bei Auftreten von fachlichen oder technischen Fehlern ausgeführt werden sollen. Damit lassen sich flexible Fehlerbehandlungsmechanismen implementieren, die für einen unterbrechungsfreien Betrieb der Infrastruktur, auch im Fall der Nichtverfügbarkeit eines Backend-Systems, sorgen.

Mit der Oracle SOA Suite sind seit der Version 11g zusätzliche Produkte wie z.B. Complex Event Processing, Business Rules und Business Activity Monitoring lizensiert. Wichtige funktio-nelle Erweiterungen sind der Metadata Service (MDS) für gemeinsam genutzte Artefakte (ge-cached im Applicationserver) und das Event Delivery Network zur Event-basierten Kommunika-tion.


Aus Entwicklungssicht nicht zu unterschätzen ist das SCA-Testframework, das automatisierte Tests der Software-Artefakte für alle Testszenarien ermöglicht. Es ermöglicht Testfälle zu gene-rieren, die für den Test nicht auf konsistente Daten in allen beteiligten Systemen angewiesen ist.

Die Vielzahl der Komponenten in der Oracle SOA Suite 11g stellt aber auch eine große Heraus-forderung dar. Trotz der gelungenen Integration der Bausteine stellt der Umfang der Suite hohe Anforderungen an die Enterprise-Architektur sowie die Entwicklung und Betrieb der Software. Wer die Vorteile einer auf Services basierenden modernen Integrationsinfrastruktur vollumfäng-lich ausnutzen möchte, erhält alle Komponenten weitgehend integriert aus einer Hand. Für ei-nen ersten Prototypen einer modernen Integrationsinfrastruktur ohne klare Strategie die lizen-sierten Komponenten sinnvoll einzusetzen, ist die von Oracle gelieferte Toolbox in vielen Fällen überdimensioniert.

Für die erfolgreiche und zielgerichtete Einführung der Oracle SOA Suite macht sich die Unter-stützung von Enterprise-Architekten, die die einzelnen Komponenten genau kennen, mehr als bezahlt.

3.1.2 Die TIBCO Integrationsplattform

TIBCO ist seit 25 Jahren ein führender Software-Anbieter im Bereich Integrations-Middleware. Die Firma bietet aktuell eine sehr große Produktpalette an, die nicht nur Enterprise Application Integration oder Business Process Management umfasst. Durch Zukäufe wurde die Produktpa-lette in den letzten Jahren beispielsweise um das Master Data Management, Business Intelli-gence, Business Process Analysis, Pattern Matching und auch Cloud-Lösungen sinnvoll er-gänzt.

Hinzu kommen eigene Entwicklungen wie Memory-Grid-Technologie in Form von TIBCO Acti-veSpaces und Enterprise Social Media mit TIBCO TIBBR. Auch im Bereich Complex Event Processing bietet TIBCO schon seit 2005 mit TIBCO Business Events eine erprobte Lösung.

Abbildung 4: TIBCO ActiveMatrix Service Grid (http://www.tibco.com)

TIBCO Software sehen wir sehr oft bei unseren Kunden im Finanz- und Telekommunikation Sektor, in beiden Branchen war TIBCO schon immer gut vertreten. Neben den Produkten bietet


TIBCO zusätzliche vertikale Lösungen auf Basis der Standardprodukte an, die auf Anforderun-gen einzelner Branchen zugeschnitten sind.

Soll eine Service-orientierte Integrationsinfrastruktur mit TIBCO Produkten realisiert werden, kann dies mittels des klassischen TIBCO Stack (TIBCO Runtime Agent, TIBCO RV /TIBCO EMS, TIBCO BusinessWorks) oder mit der neuen TIBCO Active Matrix Plattform realisiert wer-den. Je nach Anforderung können beide Ansätze erweitert werden, indem vorhandene Systeme mit TIBCO Adaptern angebunden werden. Die so aufgebaute Integrationsinfrastruktur kann je-derzeit um Bussiness Process Management (BPM) und um Komponenten zur Unterstützung der SOA Governance ergänzt werden.

TIBCO setzt mit der TIBCO Active Matrix 3.X Plattform ebenfalls auf den Service Component Architektur-Standard (SCA) für die Modellierung und Entwicklung von Komponenten. Die Lauf-zeitumgebung der Komponenten wird in einem OSGI Application Container bereitgestellt. Vor-teil hierbei ist die Unterstützung von verschiedenen so genannten Implementation Types (IT). Dazu zählen bei der TIBCO Actvie Matrix Plattform auch .NET, Java, C++ und TIBCO Busi-nessWorks. Das bedeutet für den Kunden, dass vorhandener Code egal ob in .NET, Java oder C++ unverändert weiter verwendet werden kann und auf der TIBCO Integrationsinfrastruktur ausführbar ist. Die Plattform bietet für alle Komponenten Service-Virtualisierung und einen ein-heitlichen Deployment-Prozess.

Sehr beliebt ist die Bereitstellung eines Communication Backbones auf Basis von TIBCO Mes-saging Middleware, um dezentrale Standorte robust, hochverfügbar und mit hohem Durchsatz anzubinden und darauf aufbauend einen Service- und/oder Event-basierten Integrationsbus bereitzustellen. Zudem geht der Trend bei Kunden mit Integrationsbus oft in Richtung Erweite-rung der Architektur um Business Process Management (BPM).

TIBCO bietet mit TIBCO iProcess und TIBCO AMX BPM zwei BPM-Systeme. TIBCO iProcess bewährt sich bei vielen Kunden schon seit Jahren und leistet sehr gute Dienste.

TIBCO AMX BPM ist TIBCOs Next Generation BPM und wurde von TIBCO komplett neu entwi-ckelt. Das System selbst läuft auf der TIBCO AMX 3.X Plattform, verwendet also die eigenen Konzepte und Laufzeitumgebungen. Daraus ergeben sich unter anderem die Vorteile, dass nun auch Services direkt aus dem BPM System aufgerufen werden können und Prozesse im BPM per Service-Aufruf startbar sind. TIBCO AMX BPM ist in Version 1.3 noch relativ neu und die Weiterentwicklung bleibt spannend.

Auch für die TIBCO-Welt gilt, gute Entwickler und Consultants mit tiefen Produktkenntnissen sind für eine erfolgreiche Einführung von TIBCO-Systemen unabdingbar.

3.2 Open Source Lösungen als Bausteine moderner Integrationsinfrastrukturen

Die Komponenten der Open-Source-Szene haben längst das Experimentierstadium verlassen und nähern sich funktional den Produkten der großen Produkthersteller an. Sie lassen sich schon jetzt problemlos in Hochverfügbarkeitssystemen betreiben.

Es kann als weiterer Pluspunkt bei Open-Source-Komponenten gewertet werden, dass weitge-hend anerkannte Standards und Schnittstellen zur Anwendung kommen.

Wenn bei der Einführung neuer Integrationskomponenten oder bei der anstehenden Migration auch noch der Kostenfaktor mit ins Spiel kommt, kommen auch Open-Source-Software-Komponenten als Migrationskandidaten in Frage.

Oft sind allerdings die Kosten für eine Open-Source-Lösung im Vergleich zu einem kommerziel-len Produkt schwer zu beziffern. Die Lizenzkosten eines Produktherstellers stellen gewöhnlich eher eine Einstiegshürde dar, weil trotz Teststellung des kommerziellen Paketes zunächst die


vertraglichen Bedingungen geklärt werden müssen, bevor man tief in die Entwicklung einstei-gen kann. Bei Open-Source-Komponenten kann man sich dagegen leichter für oder gegen den Einsatz einer bestimmten Komponente entscheiden und so einmal getroffene Entscheidungen revidieren.

Bei Open-Source-Lösungen muss man die Bausteine unterschiedlicher Open-Source-Projekte zu einer Integrationsinfrastruktur verbinden. Dafür ist in den IT-Abteilungen viel Eigeninitiative gefragt und die Bereitschaft, Verantwortung für die Softwareentwicklung und den Betrieb der Software zu übernehmen. Genau an dieser Stelle etablieren sich neue Open-Source-Geschäftsmodelle, die dazu beitragen, diese Lücke zu schließen.

Zusätzlich ist es beim Einsatz von Open-Source-Lösungen ratsam, sich in den Communities der verwendeten Komponenten zu engagieren und deren Weiterentwicklung zu beobachten. Diese zusätzlichen Aufwände sind zu berücksichtigen, wenn es um den Vergleich mit Lizenzkosten kommerzieller Anbieter geht.

3.2.1 Neue Geschäftsmodelle erleichtern den produktiven Einsatz

Wenn Unternehmen Open-Source-Lösungen einsetzen wollen, dann gibt es eine Reihe von Gründen, die immer wieder die Entscheidung für Open Source erschweren. Einerseits gilt es die lizenzrechtlichen Fragen zu klären. Andererseits ist der professionelle Support der Software für den produktiven Einsatz von Open-Source-Lösungen sicher zu stellen.

Hier setzen neue Geschäftsmodelle im IT-Dienstleistungsbereich ein. Diese IT-Dienstleister bieten professionellen Support von Open-Source-Lösungen mit vereinbarten SLAs an. Oftmals werden eigene Releases voneinander abhängiger Open-Source-Projekte erstellt, die bereits auf Kompatibilität geprüft wurden. Damit werden die schnellen Release-Folgen im Open-Source-Bereich beherrschbar.

Die IT-Dienstleister bieten Erweiterungen für die Open-Source-Komponenten an, die den Soft-ware Lifecycle mit diesen Lösungen unterstützen. Das beginnt bei grafischen Editoren zur Ent-wicklungsunterstützung über Lösungen für den Regressionstest bis hin zu spezialisierten Moni-toring-Lösungen.

Ein weiterer Aspekt ist, dass mitunter auch mehrere Anbieter Support für dieselben Open Source Stacks anbieten. Für den Einsatz im Unternehmen bietet das natürlich den Vorzug einer breiteren Auswahl und damit einer höheren Flexibilität und Investitionssicherheit.

Bei manchen Vertretern dieser Dienstleister findet man auch eine Haftungsfreistellung vor li-zenzrechtlichen Regressansprüchen für den Einsatz der Open-Source-Lösungen – damit ist dann auch die notwendige Rechtssicherheit gegeben.

Als Vertreter dieser Geschäftsmodelle sind hier exemplarisch FuseSource und camunda kurz dargestellt. FuseSource hat das Geschäftsmodell um Open-Source-Komponenten aus dem Apache-Lager für Integrationslösungen aufgebaut. camunda bietet mit camunda fox eine auf dem Open-Source-Projekt Activiti basierende BPM-Lösung an.

3.2.2 FuseSource

FuseSource entstand, als das Unternehmen Progress Software 2010 seine Open-Source-Aktivitäten in eine separate Organisation auslagerte. Das zentrale Produkt von FuseSource ist der Fuse ESB. Er basiert auf Komponenten aus dem Apache ServiceMix ESB, dem Apache Camel Integrationsframework, dem OSGi Container Apache Felix, dem Apache ActiveMQ mes-sage broker und dem Apache CXF Webservices Framework. Das Ganze wird abgerundet durch eine integrierte Benutzeroberfläche basierend auf Eclipse. Des Weiteren befinden sich auch


Komponenten zum technischen Monitoring, zum automatischen Deployment und zum Configu-ration Management im Paket.

Abbildung 5: Der Fuse-ESB

Tatsächlich enthält der Stack nicht nur die oben erwähnten Komponenten, sondern beruht in-tern auf einer weit größeren Anzahl von Open-Source-Bausteinen, und fügt sich damit in die vorhandene Infrastruktur in Entwicklungsprozess und Betrieb ein. Herauszuheben sind:

Die Entwicklung basierend auf Eclipse und damit die nahtlose Einbindung in die Versi-onskontrolle (SCM),

automatisierte Erzeugung von Entwicklungsartefakten, basierend auf maven,

automatisierbares Rollout und Deployment von entwickelten Komponenten mit Hilfe von ant,

Laufzeitüberwachung und Monitoring mittels JMX.

ServiceMix basiert auf dem OSGi Container Apache Karaf und nutzt das Web Service Frame-work CXF sowie das Routing Framework Camel, um einen Mediation Layer bzw. Enterprise Integration Patterns abzubilden. Diese Komponenten sind inzwischen ausgereift und es kann auf Erfahrungen und Blueprints aus Community-Foren zurückgegriffen werden. Zusätzliche Komponenten wie z.B. ein Error Handling Framework können als individuelle Entwicklung hin-zugefügt werden.

Die Nutzung offener Standards gewährleistet aus Nutzersicht, dass das System gut und stabil an andere Komponenten, z.B. JMS Messaging angeschlossen werden. Gleichwohl muss Ei-genverantwortung für die Architektur im Unternehmenskontext übernommen werden, das gilt insbesondere für Anforderungen an Hochverfügbarkeit und Skalierbarkeit.


3.2.3 camunda fox BPM-Plattform

Die camunda fox BPM-Plattform ist Basis für die Entwicklung und den Betrieb von Human-Workflow-basierenden Anwendungen. Zudem sind die Integration von externen Systemen und der Aufbau Service-orientierter Systeme möglich.

Die camunda fox BPM-Plattform basiert auf dem Open-Source-Projekt Activiti. Activiti stellt eine performante und stabile BPMN 2.0 kompatible BPM Engine zur Verfügung. Über Java API Calls ist die Integration in Java-Anwendungen leicht möglich. Über JUnit-Tests ist die Anwendung vollständig Regressionstest-fähig. Damit sind auf Activiti basierende Anwendungen hervorra-gend für eine Continous Integration geeignet.

camunda fox bietet ein Web-basiertes BPMN 2.0 kompatibles Modellierungstool, das für Ana-lysten das geeignete Tool der Wahl ist, um die fachlichen Prozesse zu modellieren. Auf der an-deren Seite gibt es mit dem fox designer ein Plugin für die Java-Entwicklungsumgebung zur Modellierung der technischen Prozessmodelle. Der fox cycle sorgt für ein Round-Trip Engine-ring zwischen dem fox modeller und dem fox designer.

Der Betrieb der auf Activiti basierenden Anwendungen wird durch das fox cockpit erleichtert. Es bietet die Möglichkeit, Prozessinstanzen zu administrieren. Zudem liefert camunda mit der camunda fox Suite vorkonfigurierte EE 6 Container (z.B. JBoss 7).

Die einzelnen Komponenten sind eine sinnvolle Ergänzung zur Open Source BPM 2.0 Engine Activiti. Das eclipse Plugin zum Design von Activiti Prozessen ist frei verfügbar. Im produktiven Umfeld ist ein Cockpit zur Administration von Prozessinstanzen unabdingbar. Die Alternative zu diesem Produkt ist eine auf die kundenspezifischen Gegebenheiten angepasste Eigenentwick-lung.

camunda Abbildung 6: Die camunda fox BPM-Platform (http://www.camunda.com)


camunda bietet einen professionellen Support mit zugesicherten SLAs. Außerdem umfasst das Angebot von camunda Training und Projektunterstützung sowohl von BPMN 2.0 als auch zu den fox Produkten.

Das Tooling kann sich insgesamt nicht mit den Produkten großer Produkthersteller messen. Insbesondere bei der Entwicklung ist man zu großen Teilen auf eine XML-Implementierung an-gewiesen, die sehr tiefgreifendes Java, XML und Webservice-Know-How erfordert. Allerdings kommen erfahrene Java-Programmierer in dieser Umgebung leicht zurecht. Wie bei den großen Produktherstellern ist die Lernkurve für die Entwicklung von prozessgesteuerten Java Anwen-dungen aber nicht zu unterschätzen.

Was anfangs nicht so offensichtlich ist, aber durchaus interessante Möglichkeiten bietet: Man kann BPMN Engines gesteuert über einen API Aufruf in beliebigen Anwendungen starten. Das bedeutet, dass unterschiedliche Instanzen gleichzeitig aus unterschiedlichen Anwendungen und Services auf den gleichen Datenbestand operieren. Nachteilig an diesem Konstrukt ist, dass alle Java-Klassen, die in Service Tasks der einzelnen Prozesse verwendet werden in allen En-gine-Instanzen zur Verfügung stehen müssen. Das trägt nicht zur Entkopplung der einzelnen Prozesse bei. Deshalb bietet sich hier ein Einsatz in einem Java EE 6 kompatiblen Container und die Verwendung von REST Webservices an.


4 Wie wählt man die passenden Integrationskomponenten aus?

Nun stellt sich die Frage, wie man die zu den fachlichen und technischen Anforderung an die neue Infrastruktur passenden Software-Komponenten auswählt. Es reicht nicht, dass die Her-steller eine Vielzahl von Komponenten bereits mitliefern, oder dass die Vertreter der unter-schiedlichen Open-Source-Lager ausreichend Projekte pflegen, die man zu einer komplexen Integrationslösung verbinden kann.

Nicht jeder Kunde hat dieselben Anforderungen an Integrationskomponenten. Dass die Grund-lage einer Suite immer ein ESB ist, der sinnvollerweise durch eine Orchestrierungskomponente wie z.B. eine BPEL- oder eine BPMN-Engine ergänzt wird, ist offensichtlich. Natürlich ist es auf den ersten Blick verlockend, wenn eine SOA Suite z.B. bereits auch eine Komponente für Busi-ness Activity Monitoring oder Complex Event Processing mitbringt. Wenn aber seitens des Un-ternehmens hierfür noch keine Anforderungen oder gar keine Pläne für den Einsatz bestehen, dann läuft man Gefahr, für etwas im Vorfeld zu bezahlen, das nie verwendet wird.

Die eingesetzten Komponenten müssen zur Strategie des Kunden, der dort vorherrschenden IT-Systemlandschaft und nicht zuletzt zum geplanten Einsatzzweck passen. Für ein allgemei-nes Vorgehen zur Auswahl für die passenden Integrationskomponenten haben wir eine Check-liste mit den wichtigsten Schritten erstellt.

Vorauswahl mit Hilfe aktueller Reports bekannter Analysten wie Forrester oder Gartner

Zusammenführung der Analysen und ein Abgleich der Ergebnisse mit dem geplanten Einsatzzweck der Suiten

Nutzung von Kriterienkatalogen führender IT-Dienstleister

Prüfung der Kandidaten auf funktionale und nicht-funktionale Anforderungen

Klärung, ob Open Source Software zum Unternehmen passt

Prüfung der Entwicklungsumgebung und des gesamten Software Lifecycles der Kandi-daten

Prüfung der Strategie und der Marktpräsenz der Hersteller im Bereich Integrationsinfra-strukturen

Prüfung, ob professioneller Support bei der Entwicklung und im Betrieb der Infrastruktur mit entsprechenden SLAs zur Verfügung steht.

Die Auswahl der Kandidaten beginnt mit einer groben Vorauswahl von Software-Herstellern und Open-Source-Lösungen mit Hilfe von aktuellen Analysten-Reports, wie z.B. von Gartner und Forrester. Oftmals kommen die Analysten in der Bewertung einzelner Suiten oder derer Komponenten zu unterschiedlichen Ergebnissen. Hier ist eine Zusammenführung der Analysen und ein Abgleich der Ergebnisse mit dem geplanten Einsatzzweck der Suiten notwendig. Da-nach sollten die vielversprechendsten Kandidaten für den geplanten Einsatzzweck feststehen.

Zur Konkretisierung der zu untersuchenden Lösungen ist es ideal, wenn man Kriterienkataloge führender IT-Dienstleister nutzen kann, die bereits fundierte Erfahrung bei der Auswahl und Bewertung von Integrationsinfrastrukturen haben. NTT DATA hat einen bereits in mehreren SOA-Einführungsprojekten bewährten Kriterienkatalog zur Auswahl von BPM/ESB Infrastruktu-ren erstellt, der nicht nur die Feature-Listen der Hersteller und der Open-Source-Lösungen auf-bereitet, sondern auf eigenen belastbaren Projekterfahrungen beruht. Dieser Kriterienkatalog wird ständig weiterentwickelt und spiegelt den aktuellen Stand der Technik wider.


Mit der Erfahrung aus Integrationsprojekten unterschiedlicher Branchen können die für den ge-planten Einsatzzweck relevanten Kriterien projektspezifisch bestimmt und sinnvoll gegeneinan-der abgewogen werden.

Auch bei der Auswahl von Integrationskomponenten werden die klassischen Auswahlkriterien für Software-Komponenten angewendet. Wichtige Kriterien sind neben allgemeingültigen funk-tionalen und nicht-funktionalen Anforderungen an ein Integrationssystem die Systemarchitektur und die Laufzeitumgebung der Lösung. Weitere wichtige Punkte sind die Unterstützung des gesamten Software Lifecycles. Hier gilt besonderes Augenmerk auf den Entwicklungswerkzeu-gen mit entsprechenden grafischen Editoren und die Testbarkeit der einzelnen Komponenten und des Gesamtsystems zu legen. Mindestens genauso wichtig ist die Betriebsunterstützung für den IT-Betrieb und den 2nd Level Support. Hier ist die Möglichkeit nach fachlichen Schlüs-seln zu suchen und darüber gefundene Instanzen grafisch darstellen zu lassen ein wichtiges Thema.

Was bei der Suche nach einer passenden Integrationsinfrastruktur nie außer Acht gelassen werden darf, ist die Strategie und Marktpräsenz der Hersteller. Nur wenn der Hersteller eine klare Strategie in Bezug auf den Einsatz und der Weiterentwicklung seiner Komponenten ver-folgt, ist das ein eindeutiges Kaufkriterium für seine Integrationslösung. Im Open-Source Be-reich ist es gefährlich auf technologisch sehr interessante Projekte zu setzen, die bislang nur eine geringe Zahl von aktiven Unterstützern hat. Sobald das Interesse der Open-Source Ent-wickler an einem Projekt nicht mehr gegeben ist, kann es sein, dass bald kein ausreichender Support für das Projekt erhältlich ist.

Ein wichtiger Teil des Auswahlprozesses ist auch die individuelle Analyse der Kandidaten auf die konkreten Projektanforderungen und die Kompatibilität zur Unternehmensphilosophie.

Weiterhin ist zu klären, ob die für die Integration von Bestandssystemen notwendigen Adapto-ren in ausreichender Funktionalität und Qualität zur Verfügung stehen. Wie passt die Lösung in die bestehende Systemlandschaft? Ist ausreichend Know-How in der Entwicklung, dem Test und Betrieb der Softwarelösung vorhanden? Steht qualifizierter Support bei der Entwicklung und dem Betrieb der Software in ausreichendem Umfang zur Verfügung? Gibt es professionel-len Support für den Betrieb der Software mit garantierten Reaktionszeiten, so dass die produkti-ven Systeme mit der notwendigen Verfügbarkeit betrieben werden können?

Das sind Fragen, die man üblicherweise erst im Rahmen von Proof of Concepts mit den viel-versprechendsten Kandidaten beantworten kann.

Wenn es um die Entscheidung für Open-Source-Lösungen oder Lösungen führender Pro-dukthersteller geht, dann zeigen unsere Erfahrungen bei unterschiedlichen Kunden, dass Open-Source-BPM/ESB-Systeme vor allem bei denjenigen Kunden im Einsatz sind, die ein Team von In-House-Entwicklern haben, die bereit sind, ein gewisses Maß an Eigenverantwortung für die eingesetzten Softwarekomponenten zu übernehmen. In diesem Fall profitiert man besonders von der Offenheit des Quelltextes und der daraus resultierenden Erweiterungsmöglichkeit. Rat-sam ist hier ein enger Schulterschluss mit den wichtigsten Open Source Communities, über die unmittelbarer Einfluss auf die Roadmap für die Weiterentwicklung genommen werden kann. Natürlich ist dies über die im Kapitel 3.2 erwähnten Dienstleister für komplette Open Source Suites am einfachsten realisierbar.

Werden Integrationsprojekte vornehmlich extern vergeben und sind zudem vor allem Standard-Software-Komponenten im Einsatz, so trifft man vermehrt auf Software-Komponenten führender Produkthersteller. Hierbei sind oft Produkte von Herstellern im Einsatz, die mit denen entweder bereits gute Erfahrungen gemacht wurden, oder die von der Strategie her in das Unternehmen passen. Sind viele IBM-Produkte im Einsatz, so sind auch für die Integrationslösung IBM-


Produkte die ersten Kandidaten der Wahl. Sind Oracle Systeme die zentralen Komponenten, die es in einen Prozess zu integrieren gilt, dann ist sicherlich die Oracle SOA Suite ein geeigne-ter Kandidat. Das gilt insbesondere, da Oracle ein klares Bekenntnis zu ihren Integrationskom-ponenten abgibt, indem sie ihre Fusion Apps auf Basis der Oracle SOA Suite integriert.


5 Cloud Computing und Integrationsarchitekturen

5.1 Cloud Computing im Unternehmen

Cloud Computing verspricht durch seine standardisierten und weitgehend automatisierten Pro-zesse eine außergewöhnliche Kostenersparnis in Betrieb und Wartung der Anwendungen. Die wachsende Anzahl mobiler Endgeräte sorgt dafür, dass der Zugriff auf Unternehmensressour-cen extrem skalierbar sein muss.

Im Bereich B2C muss sichergestellt werden, dass Lastspitzen, wie sie z.B. bei Rabattaktionen auftreten können, ohne Ressourcenengpässe zur Zufriedenheit der Endanwender abgefangen werden können. Allerdings soll den Rest des Jahres nicht 80% der IT-Infrastruktur brach liegen.

Das war im Übrigen auch einer der Auslöser für Cloud Computing. Amazon wollte die Ressour-cen an Speicherplatz und Server-Kapazitäten, die vor allem für das Weihnachtsgeschäft benö-tigt werden, während des Jahres gleichmäßig auslasten. Das hat letztendlich zu dem bekannten Geschäftsmodell Amazon S3 und Amazon Elastic Cloud (EC2) geführt.

Aber auch Hersteller klassischer Enterprise-Applikationen bauen mit ihren Lösungen verstärkt auf Applikationen in der Cloud. Oracle hat z.B. im Oktober 2011 RightNow übernommen, einen Provider für Cloud-basierende Dienstleistungen. RightNow unterstützt Organisationen im Be-reich Customer Contact Center, Kunden z.B. auch über Social Media besser an das Unterneh-men zu binden.

Oracle bestätigt hierbei die Strategie, Cloud Computing in Unternehmen weiter massiv voranzu-treiben und die (potentiellen) Kunden vermehrt auch über mobile Devices in Unternehmenspro-zesse zu integrieren.

Beim Cloud Computing gilt es den Spagat zwischen unbegrenzten Infrastrukturkosten zu nied-rigem Preis und Datenschutz und Datenverfügbarkeit zu schaffen. Das Potenzial an Kunden, die mit Mobilgeräten aufgewachsen sind und die immer und überall Internet-Zugang haben, muss genutzt werden. Der positive Effekt, der sich auch aus der Integration sozialer Netzwerke ergibt, muss für die Kundenbindung weiter genutzt werden.

Aber auch innerhalb des Unternehmens ergeben sich z.B. über Salesforce, Chatter oder tibbr ganz neue Möglichkeiten zur Zusammenarbeit in einer sozialen Cloud.

Um den Anforderungen der Kunden zur Flexibilisierung ihrer IT-Systeme zu genügen, gibt es unterschiedliche Ausprägungen von Cloud Computing. Die Schlagworte hierbei sind „Infrastruc-ture as a Service” (IaaS), „Platform as a Service“ (PaaS) und „Software as a Service” (SaaS).

Die zugehörigen Cloud-Infrastrukturen können öffentlich bereitgestellt werden (Public Cloud), oder nur für ein einzelnes Unternehmen betrieben werden (Private Cloud). Auch die Vermi-schung beider Infrastrukturen in einer Hybrid Cloud ist ein gängiger Ansatz beim Thema Cloud Computing.

5.2 Cloud Computing und Integrationsinfrastrukturen

Wenn es um die Erneuerung von Integrationsinfrastrukturen geht, ist das Thema Cloud Compu-ting in jedem Fall mit zu betrachten. Für die Systemarchitektur bedeutet das, dass die lose Kopplung der Systeme und die Integration der verschiedenen Eingangskanäle, vor allem aber der mobilen Endgeräte, vorrangiges Ziel sein muss.

Die Bereitstellung von fachlich motivierten Services für die B2B- und B2C-Integration und die Orchestrierung dieser Services sowie die Automatisierung von Geschäftsprozessen sind wichti-ge Bausteine auf diesem Weg.


Bei der Auswahl von Integrationsinfrastrukturen ist die Skalierbarkeit ein Kriterium, das vor die-sem Hintergrund noch weiter an Bedeutung gewonnen hat. Die Skalierung muss durch automa-tisierte Installation von Integrationskomponenten inklusive der benötigten Application Server, Adaptoren und fachlichen Services auf Knopfdruck funktionieren.


6 Fazit

Die Erneuerung der Integrationsinfrastruktur ist ein anspruchsvolles Vorhaben. Die Potenziale zur Steigerung der Effizienz müssen analysiert und umgesetzt werden. Potenziale ergeben sich auf unterschiedlichen Ebenen:

Beim Aufbau und der Nutzen von entkoppelten Systemen als Basis für die Geschäfts-prozess Automatisierung

Bei der Auswahl einer neuen Integrationsinfrastruktur mit der Entscheidung für eine Sui-te führender Produkthersteller oder von Open Source Komponenten

Bei der optimalen Nutzung der Cloud-Technologie.

Automatisierung von Geschäftsprozessen

Viele SOA Projekte haben schon einen großen Beitrag zur Entkopplung von eng gekoppelten Systemen geleistet. Das volle Potential einer Service-orientierten Architektur lässt sich aber erst nutzen, wenn auch Geschäftsprozesse automatisiert werden.

Geschäftsregeln und Prozesse werden direkt in ausführbarer Software abgebildet. Dadurch ist sichergestellt, dass alle Fälle gleichartig in optimaler Geschwindigkeit und Qualität ausgeführt werden.

SOA Suiten von Produktherstellern oder Open Source

Open Source SOA Lösungen sind in Unternehmen immer häufiger anzutreffen und haben be-reits einen hohen funktionalen Reifegrad erreicht.

Neue Geschäftsmodelle bieten professionellen Support für Open Source Software mit vereinba-ren SLAs. Die Integration unterschiedlicher Open Source Komponenten zu einer Tragfähigen SOA Infrastruktur erfordert jedoch viel Eigeninitiative in den IT-Abteilungen und die Bereitschaft Verantwortung für die Integration und den Betrieb der Softwarekomponenten zu übernehmen.

Die Lizenzkosten sind hierbei nicht die wichtigsten Kriterien. Viel wichtiger ist, dass die einge-setzte Suite zum Unternehmen und zur vorherrschenden IT-Infrastruktur passt.

Cloud Computing

Das Konzept Cloud Computing bietet ein großes Einsparungspotential bei der Infrastruktur und dem Betrieb der IT-Landschaft. Mit der richtigen Strategie und der passenden Cloud-Lösung lassen sich große Optimierungspotentiale auch bei unternehmenskritischen Anwendungen mit hohen Anforderungen an Verfügbarkeit, Datenschutz und Datensicherheit erfolgreich nutzen.


7 NTT DATA Projektbeispiele

Kunde Referenzprojekt

Führendes Deut-sches Telko-Unternehmen

Für die Einführung einer Service-orientierten Architektur wurde das Telko Unternehmen bei der Herstellerauswahl in einem Proof of concept unter-stützt.

NTT DATA wurde mit dem Design und Implementierung einer auf Stan-dards basierender automatisierter Schnittstelle zur Kopplung des CRM Systems mit der Service Plattform (OSS) für die Provisionierung von Tele-fondiensten beauftragt.

Der Nutzen dieser Lösung zeigte sich durch Kosteneinsparungen im Be-trieb und in der Kundenzufriedenheit durch Transparenz des Aktivierungs-prozesses. Folgeprojekte konnten durch Wiederverwendung bestehender Basisservices und der Service Infrastruktur schneller und kostengünstiger abgewickelt werden.

Führender deutscher Fi-nanzdienstleister

Der Finanzdienstleister beauftragte die NTT DATA mit der Auswahl einer neuen SOA Infrastruktur für die Ablösung einer bestehenden SOA Platt-form. Die bestehende Plattform entsprach funktional nicht mehr den Anfor-derungen und der Aufwand für die Weiterentwicklung und Modernisierung des bestehenden Systems wurde zu hoch.

Die neue SOA Infrastruktur wurde auf Basis von Open Source Produkten realisiert. Der Finanzdienstleister betreibt nun eine hochmoderne, kosten-günstige und vor allem performante EAI- und SOA Umgebung.

Durch die erhöhte Flexibilität der neuen Open Source Umgebung ergab sich nicht nur eine Ersparnis von Lizenzkosten, sondern auch eine Erspar-nis von ca. 50% bei der Entwicklung von neuen Schnittstellen.

Führendes welt-weit tätiges Unter-nehmen mit füh-renden Marken von Kinderspiel-zeugen

Der Konzern ist ein Hybrid Cloud Kunde, der eine „managed hosting“ Lö-sung nutzt, um die auf physikalischer Hardware laufende Oracle Daten-banken zu betreiben. Der Betrieb der Datenbanken erfolgt durch Oracle DB support services von der Cloud Business Unit.

Um Lastspitzen an benötigter Serverkapazität abzufangen nutzt der Kon-zern die Dimension Data Public Cloud. Damit die saisonale Nachfrage auf den e-commerce Websites führender Marken von Kinderspielzeugen be-friedigt werden kann, werden bei Bedarf dynamisch hunderte virtuelle Ser-ver zu- oder abgeschaltet.

Da der Konzern Daten von und über Kinder sowie Geschäftsdaten spei-chert, musste die Cloud-Lösung die höchsten Anforderungen an Sicherheit und den entsprechenden strikten gesetzlichen Vorgaben erfüllen.


8 Über NTT DATA Deutschland

Der japanische IT-Konzern NTT DATA hat weltweit über 57 000 Mitarbeiter in 35 Ländern. In Europa, dem Mittleren Osten, Afrika, Argentinien sowie Brasilien ist NTT DATA unter der Lei-tung von Thomas Balgheim mit mehr als 6 000 Experten präsent. In den beiden weltweit ein-heitlichen Business Units „Financial & Public Sector“ und „Enterprises“ bietet NTT DATA inno-vative Business- und IT-Lösungen, die Unternehmen und Organisationen einen messbaren Mehrwert verschaffen. Fokusthemen von NTT DATA sind Business & IT Consulting, Customer Management, IT Security und Business Intelligence und Analytics & Performance Management. Einen klaren Schwerpunkt hat NTT DATA im Outsourcing. Hier bietet das Unternehmen das gesamte Dienstleitungsspektrum – angefangen von Application Development & Management und Enterprise Application Services über Infrastructure Management bis hin zu Business Pro-cess Outsourcing – vor Ort oder über Global Delivery.

Whitepaper Kosteneffizienz durch Innovation von - NTT Data

Documents

Transcript of Whitepaper Kosteneffizienz durch Innovation von - NTT Data