Enterprise Application Integration

Pischke, Peter Lutz

Enterprise Application Integration

Prototypentwicklung mit DirXML

von Peter Lutz Pischke (Autor:in)

Informatik - Software

Zusammenfassung

Inhaltsangabe:Einleitung:
Das Thema Enterprise Application Integration (EAI) ist nach eBusiness ein neuer Hype der Softwareindustrie, allerdings mit einer wesentlich erhöhten Komplexität. Diese Ausarbeitung verfolgt dazu, einen entgegen dem Markt üblichen, eigenständigen Ansatz, der aus einem Prototypen und dessen Positionierung mit durchgängiger Dienstleistung besteht.
Der Schwerpunkt der Dienstleistung und der verwendeten Technologie, ist die nonintrusive, strukturelle Integration von Systemen und Anwendungen auf der Ebene der Anwendungsschnittstellen mittels nativer C++ bzw. Java-Treiber, was eine, lediglich von der zu integrierenden Anwendung abhängige Projektierung ermöglicht und die bestehenden IT-Strukturen auf niedriger Ebene bereinigt und somit für zukünftige Anforderungen vorbereitet.
Den typischen Risiken der Veränderungen von gewachsenen Strukturen wird durch den integrativen Lösungsansatz, unter Zuhilfenahme der bestehenden Leistungsbereiche der Firma begegnet. Es besteht eine hohe Variabilität des Vorgehens mit Standards auf der Metaebene (Modellebene), mit hoher Priorität auf die Einhaltung international vereinbarter Standards, wie XML.
Anforderungen an den Leser:
Als übergeordnete Methodik wurde Systems Engineering und der prinzipielle Aufbau von Businessplänen genutzt. Die Programmtechnische Detailierung wird auf den im Haupttext dargestellten XML-Codes beschränkt. Somit ist die Thematik auch für Nicht-ITler verständlich gehalten. Um der hohen Komplexität Rechnung zu tragen, wurde ein umfangreiches Glossar, das vertiefende und ergänzende Informationen enthält, hinzugefügt.

Inhaltsverzeichnis:Inhaltsverzeichnis:
KAPITEL 1: Einleitung1
Vorstellung der Firma1
Überblick1
Leistungsbereiche1
Kunden (Auszug)2
KAPITEL 2: Systemgestaltung3
Vorgaben3
Zielbeschreibung3
Zielobjekt3
Zieleigenschaft3
Zielausmass3
zeitlicher Bezug3
Restriktionen3
Beachtung der gegebenen Rahmenbedingungen3
DirXML als zu verwendende Technologie4
Bearbeitungshinweise4
Verlässlichkeit der Informationen4
Verwendete Methodik4
Systemgestaltung und -abgrenzung4
Begriffsdefinition4
KAPITEL 3: Umfeldbetrachtung EAI7
Das Produkt EAI7
Motivatoren für EAI7
Technisch begründete Motivatoren7
Betriebswirtschaftlich begründete Motivatoren8
EAI als fundamentale Basis für ebusiness9
Die Vision9
Begriffe11
Anforderungen von E-Business an die IT11
Die Realität12
Die Realisierung13
Zusammenfassung14
Ursachen gegenwärtiger […]

Leseprobe

Inhaltsverzeichnis

ID 5650

Pischke, Peter Lutz: Enterprise Application Integration: Prototypentwicklung mit

DirXML / Peter Lutz Pischke - Hamburg: Diplomica GmbH, 2002

Zugl.: Esslingen, Fachhochschule, Diplomarbeit, 2002

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die

der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen,

der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der

Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung,

vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im

Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der

Bundesrepublik Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich

vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem

Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche

Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten

wären und daher von jedermann benutzt werden dürften.

Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können Fehler nicht

vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die Autoren oder

Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.

verbliebene fehlerhafte Angaben und deren Folgen.

Diplomica GmbH

http://www.diplom.de, Hamburg 2002

Printed in Germany

Prototypentwicklung mit DirXML

Diplomarbeit

Lutz Pischke

N T E R P R I S E

P P L I C A T I O N

N T E G R A T I O N

Inhalt

Das Thema Enterprise Application Integration (EAI) ist nach eBusiness ein neuer

Hype der Softwareindustrie, allerdings mit einer wesentlich erhöhten

Komplexität. Diese Ausarbeitung verfolgt dazu, einen entgegen dem Markt

üblichen, eigenständigen Ansatz, der aus einem Prototypen und dessen

Positionierung mit durchgängiger Dienstleistung besteht.

Der Schwerpunkt der Dienstleistung und der verwendeten Technologie, ist die

nonintrusive, strukturelle Integration von Systemen und Anwendungen auf der

Ebene der Anwendungsschnittstellen mittels nativer C++ bzw. Java-Treiber, was

eine, lediglich von der zu integrierenden Anwendung abhängige Projektierung

ermöglicht und die bestehenden IT-Strukturen auf niedriger Ebene bereinigt und

somit für zukünftige Anforderungen vorbereitet.

Den typischen Risiken der Veränderungen von gewachsenen Strukturen wird

durch den integrativen Lösungsansatz, unter Zuhilfenahme der bestehenden

Leistungsbereiche der "Firma" begegnet. Es besteht eine hohe Variabilität des

Vorgehens mit Standards auf der Metaebene (Modellebene), mit hoher Priorität

auf die Einhaltung international vereinbarter Standards, wie XML.

Anforderungen an den

Leser

Als übergeordnete Methodik wurde Systems Engineering und der prinzipielle

Aufbau von Businessplänen genutzt. Die Programmtechnische Detailierung wird

auf den im Haupttext dargestellten XML-Codes beschränkt. Somit ist die

Thematik auch für Nicht-IT´ler verständlich gehalten. Um der hohen

Komplexität Rechnung zu tragen, wurde ein umfangreiches Glossar, das

vertiefende und ergänzende Informationen enthält, hinzugefügt.

Stichworte

Enterprise Application Integration, Prozessintegration, Novell DirXML,

eBusiness-enabling, Infrastrukturlösung, Produktentwicklung

ROTOTYPENTWICKLUNG

MIT

XML

U R Z F A S S U N G

content

The topic Enterprise Application Integration (EAI) is after eBusiness a new hype

of the software industry however with a substantially increased complexity. This

elaboration pursues an independent beginning usual against the market with an

own prototyp and services.

The emphasis of the services and the used technology is the nonintrusiv structural

integration of systems and applications on the level of the application interfaces

by means of native C++ or Java drivers. This allows a project engineering that ist

only application dependent and prepares the IT structures on low level for further

requests.

The typical risks of the modifications of grown structures are avoided by the

integrative solution, with help by the existing performance areas of the "firm".

The solution insists a high variability of the procedure with standards on the

Metalevel (model level), with high priority on the adherence to internationally

agreed upon standards like XML.

reader requirement

As superordinate methodology system engineering and the structure in principle

of businessplans were used. The technical part is marked out with XML code-

fragments represented in the main text. Thus the topic is understandably held also

for Non-IT-people. In order to carry for the high complexity an extensive glossary

deepening and completing information.

keywords

Enterprise Application Integration, processintegration, Novell DirXML,

eBusiness-enabling, infrastructure solution, product-development

ROTOTYPENTWICKLUNG

MIT

XML

B S T R A C T

Inhalt

KAPITEL 1

Einleitung

Vorstellung der "Firma" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Überblick ... 1

Leistungsbereiche ... 1

Kunden (Auszug) ... 2

KAPITEL 2

Systemgestaltung

Vorgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Zielbeschreibung ... 3

Zielobjekt ... 3

Zieleigenschaft ... 3

Zielausmass ... 3

zeitlicher Bezug ... 3

Restriktionen ... 3

Beachtung der gegebenen Rahmenbedingungen ... 3

DirXML als zu verwendende Technologie ... 4

Bearbeitungshinweise ... 4

Verlässlichkeit der Informationen ... 4

Verwendete Methodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Systemgestaltung und -abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Begriffsdefinition ... 4

KAPITEL 3

Umfeldbetrachtung EAI

Das ,,Produkt" EAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Motivatoren für EAI ... 7

Technisch begründete Motivatoren ... 7

Betriebswirtschaftlich begründete Motivatoren ... 8

EAI als fundamentale Basis für ebusiness ... 9

Die Vision ... 9

Begriffe ... 11

Anforderungen von E-Business an die IT ... 11

Die Realität ... 12

Die Realisierung ... 13

Zusammenfassung ... 14

Ursachen gegenwärtiger Schwierigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . 15

Technologiebezogene Ursachen ... 15

Gegenbewegung ... 16

Ursachen in der Art der IT-Beschaffung ... 16

Inhalt

Verantwortung der Architektur ... 16

Grad des Einbezugs des Managements in IT-Entscheidungen ... 16

Ursachen in der Softwareindustrie ... 17

Schneller-Besser-Billiger-Philosophien ... 18

Kundenbindungsorientierte vs. standardisierte Lösungen ... 18

Gegenbewegung ... 18

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

KAPITEL 4

EAI-Markt

EAI-Software Marktklassifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Grobklassifizierung ... 20

Differenzierung nach Herkunft ... 20

Differenzierung nach der Systemarchitektur der Lösung ... 20

Feinklassifizierung ... 21

Differenzierung nach der Integrationsmethode ... 21

Differenzierung nach der Schnittstellen-Architektur ... 21

Marktportfolio EAI-Software ... 22

Marktentwicklung EAI-Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Marktanteile - Gesamtmarkt ... 23

Aktienindizes ... 23

Lizenzumsatz - Gesamtmarkt ... 24

Umsatz mit Dienstleistungen ... 24

Markttrends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Integration von EAI-Fähigkeiten in Standardsoftware ... 25

B2B-Fähigkeit ... 25

Prozessintegration ... 25

Adapter ... 26

Harmonisierung der Standards ... 26

Skalierbarkeit ... 26

Hybride Produkte. ... 26

Marktstabilisierung und Konsolidierung. ... 26

Outsourcing der IT-Infrastruktur ... 27

Abwendung von Microsoft-zentrischer IT im IT-Backbone ... 27

Markthemmnisse ... 28

Gründe für den Mißerfolg bei der Vermarktung von Technologieprodukten .. 29

EAI-Auftragnehmer/Vertriebswege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Vertriebskanäle der vertriebenen EAI-Software ... 30

Kunden im EAI-Markt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Kundenbeispiele ... 31

Südwestdeutsche Genossenschaftszentralbank ... 31

Deutsche See ... 32

Spectratech International ... 32

Weitere EAI-Implementierungen ... 33

Kundenanforderungen und Kundenverhalten ... 34

Kundenanforderungen ... 34

Kundenverhalten ... 34

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

KAPITEL 5

Arbeitsmodelle

Anforderung an Arbeitsmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Kompetenzfindung ... 37

Ort der Entstehung der Erfahrungen ... 37

Inhalt

III

Präzisierung der Wissensträger von Spezialkenntnissen ... 37

Zuordnung von Kosten ... 38

Methode oder Wahnsinn ... 38

Strategieorientierter Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Durchführung ... 39

Level 1: Point-to-Point-Integration (P2P) ... 40

Nachteile ... 40

Technologien ... 40

Level 2: Strukturelle Integration ... 40

Technologien ... 42

Durchführung ... 42

Level 3: Intra-Enterprise-Integration (Prozessintegration) ... 42

Level 4: Inter-Enterprise-Integration (B2B Integration/B2Bi) ... 43

Schnittstellenorientiertes Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

User-Interface-Ebene ... 44

Application Interface-Ebene (API) ... 44

Daten-Ebene (Kohäsive/nonintrusive Integration))) ... 45

Methoden-Ebene (intrusive Integration) ... 45

Technologien ... 46

Eignung der Integration auf Methodlevel ... 46

Middleware-orientiertes Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Ebenen des Middleware-orientierten Modells ... 47

Patterns und Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Patterns ... 47

Frameworks ... 48

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

KAPITEL 6

Strukturelle Integration mit DirXML

Vorgehensweise bei Entwicklung und Design des Prototyps . . . . . . . . . . 50

Aufgabenstellung ... 50

Umfang der Arbeiten ... 50

Verwendete Entwicklungswerkzeuge ... 52

XML-Programmierung ... 52

DTD-basierte Entwicklung ... 52

C++-Programmierung ... 53

Dokumentation ... 53

Erstellte Dokumentenbasis für EAI ... 54

Novell DirXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Kernmerkmale ... 54

DirXML im Vergleich ... 56

Directory-orientierte Software ... 56

Directory-Kunden ... 57

Server Plattformen für Directory´s ... 57

Andere Directory-orientierte Lösungen ... 58

Anmerkung zur Positionierung von DirXML ... 58

DirXML Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Gesamtstruktur des Systems ... 59

Kernkomponenten der DirXML-Technologie ... 59

DirXML Engine ... 59

DirXML-Driver ... 60

Eigenschaften der DirXML-Technologie ... 61

XML-Technologie, XDS ... 61

Publish-Subscribe-Verfahren ... 61

Inhalt

Associations ... 61

Autorisierte Datenquellen ... 61

Zu integrierende Daten ... 61

Datentransformationen ... 62

Driver-spezifische Regel: Schema Mapping ... 62

Verwendung für den Prototypen ... 62

Channelspezifische Regeln ... 64

Matching Rules (Übereinstimmungsregeln) ... 64

Create rules (Erstellungsregeln) ... 65

Placement rules (Plazierungsregeln) ... 65

Eventfilterung (Ereignisfilter) ... 65

Graphischer Überblick im XML-Entwicklungswerkzeug ... 66

Graphischer Überblick in der ConsoleOne ... 66

Stand der Entwicklungsarbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Analyse der beteiligten Systeme ... 67

Abgeschlossen (Aufwand: 4 Wochen): ... 67

Zu bearbeiten (mit erfahrenem C-Programmierer): ... 68

Interne Kosten der Entwicklung (Prototyp) ... 69

Pionierkunden ... 69

KAPITEL 7

Positionierung "Firma"-EAI mit DirXML

Leserkreis ... 70

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Key of Success ... 71

Die Herausforderung im EAI-Umfeld ... 72

Charakteristik der Lösung ... 73

Vorteile von DirXML für die "Firma" ... 74

Unterschied zu anderen Anbietern/Paradigmawechsel ... 74

Wettbewerbsvorteile "Firma"-EAI ... 75

Weitere Möglichkeiten der Erweiterung des Leistungsangebotes ... 75

Leistungsspektrum "Firma"-EAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Mögliche Produkte/Dienstleistungen/KnowHow ... 75

Analysen der IT-Strukturen/Umgebungs-/Schwächenanalyse ... 76

Vermittlung von Grundlagen-KnowHow im EAI-Szenario (Schulung) ... 76

Etablierung von Infrastrukturen zur strukturellen Integration ... 77

Kurz- und Langfristiger Kundennutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Integration und Migration der Daten ... 77

Investitionsschutz und Kosteneinsparungen ... 77

Ausbauoptionen ... 77

Ermöglichung und Förderung von E-Business (eBusiness-enabling) ... 78

Technische und administrative Faktoren ... 79

IT-Positionierungsdiagramm ... 79

Kennzahlen ... 79

Produkt-/Programmpolitik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Die ersten Schritte im Markt ... 80

Erfahrungssammlung mit DirXML in EAI-Projekten ... 80

Integrativer Lösungsansatz/Erfahrungsaustausch ... 80

Propagieren des eBusiness-enabling ... 80

Ausbau der Allianzen und Produkte ... 81

Mittel- und Langfristige "Firma"-EAI-Strategien ... 81

Technologiegebundene Strategie ... 81

Personengebundene Strategie ... 81

Firmengebundene Strategie ... 81

Nischenmarktgebundene Strategie ... 81

Inhalt

Externe Kooperationen/Partnerschaften ... 82

Preisgestaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Risikoabschätzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Gewählte Einflußfaktoren ... 84

Allgemeine Risiken ... 84

Projektgröße ... 84

Strukturelle Risiken ... 84

Technologische Risiken ... 84

Risikoportfolio ... 85

ANHANG 1

Glossar

A-1

ANHANG 2

Soziotechnisches System: Beispielunternehmen A-28

Zweck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-28

Konstrukt des Fallbeispiels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-28

EDV-Ausgangssituation ... A-29

Verantwortung für EDV ... A-29

IT-Struktur ABC KG ... A-29

Soziale Komponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-29

ANHANG 3

EAI-Software-Anbieter

A-32

ANHANG 4

Referenzen

A-35

Bücher und Artikel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-35

Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-35

Einzelne Artikel aus unterschiedlichen Quellen ... A-35

Mehrmals genutzte Quellen aus denen Artikel bezogen wurden ... A-37

Abbildungsverzeichnis

ABBILDUNG 1. ... Vorkonfigurierte Synchronisierungsfunktionen in

webmethods 13

ABBILDUNG 2. ... EAI-spezifische Marktanteile 2001 23

ABBILDUNG 3. ... Tech-Index zum 26.10.2001 (http://

stocks.ittoolbox.com/ITtoolbox/) 24

ABBILDUNG 4. ... Schritte der Integration 39

ABBILDUNG 5. ... P2P-Integration 40

ABBILDUNG 6. ... Integration Hub 40

ABBILDUNG 7. ... Prozessintegration 43

ABBILDUNG 8. ... Beispiel eines OMT/UML-Werkzeuges (ObjectPlant/

Macintosh) 49

ABBILDUNG 9. ... Der TNG - Klassenassistent mit den verwaltbaren

Objekten 51

ABBILDUNG 10. ... Die Eigenschaften auf Instanzebene (Eigenschaften

vererbt aus oberster Ebene) 51

ABBILDUNG 11. ... Gesamtansicht der obersten Ebene des TNG-Drivers

ABBILDUNG 12. ... Auszug des XML-Elementes <add-assoziation> in der

nds-dtd 53

ABBILDUNG 13. ... Resultierendes Hilfsfenster im XML-IDE 53

ABBILDUNG 14. ... Novell eProvisioning 56

ABBILDUNG 15. ... Kunden von Directory´s, in Anzahl der Mitarbeiter

(Radicati Group) 57

ABBILDUNG 16. ... Serverplattformen für Directory´s (Radicati) Group)

ABBILDUNG 17. ... Grundkonzept der DirXML-Technologie 59

ABBILDUNG 18. ... Regeln und Transformationen im Kontext der

DirXML Engine 64

ABBILDUNG 19. ... Die Rules des Publisher-Channels des TNG-Drivers in

der Tree-Ansicht des Entwicklungswerkzeuges 66

ABBILDUNG 20. ... Ansicht des TNG-Drivers in der Novell ConsoleOne

Abbildungsverzeichnis

VII

ABBILDUNG 21. ... Aktion/Reaktion auf die erarbeiteten Informationen

ABBILDUNG 22. ... Novell eProvisioning 78

ABBILDUNG 23. ... Informatik-Positionierungs-Diagramm (in Anlehnung

Systems Engineering, Methodik und Praxis, Daenzer/

Huber), Seite 397 79

ABBILDUNG 24. ... n-Tier-Architektur (Apple) A-2

ABBILDUNG 25. ... Applikationsserver/Integrationsserver A-11

ABBILDUNG 26. ... P2P-Struktur A-16

ABBILDUNG 27. ... Hub-and-Spoke-Struktur A-16

ABBILDUNG 28. ... Bus/Pipeline-Struktur A-16

ABBILDUNG 29. ... Multihub/Snowflake-Struktur A-16

ABBILDUNG 30. ... EAI im Mittelpunkt aller IT- und Organisations-

bemühungen A-23

ABBILDUNG 31. ... Überbetonung des technischen Aspektes A-30

ABBILDUNG 32. ... Auswirkungen von Reorganisationsmaßnahmen A-31

VIII

Tabellenverzeichnis

TABELLE 1. ... Systemgestaltung und -Abgrenzung

TABELLE 2. ... Marktportfolio EAI-Software (Herkunft/

Technologie)

TABELLE 3. ... Geschätzter Lizenzumsatz (in Mrd. US$)

TABELLE 4. ... Gründe für den Mißerfolg bei der Vermarktung von

Technologieprodukten

TABELLE 5. ... EAI-Auftragnehmer in Europa (Auszug)

TABELLE 6. ... Beispielrechnung einer EAI-Implementierung

TABELLE 7. ... Traditional Client/ Server/ Platform vs. Verastream/

Linux

TABELLE 8. ... Vergleich DirXML mit anderen Directory-orientierte

Lösungen

TABELLE 9. ... Beispiel einer Umgebungs-/Schwächenanalyse

TABELLE 10. ... Markteintritt

TABELLE 11. ... Risiko-Wahrscheinlichkeitsportfolio

TABELLE 12. ... n-Tier-Architektur

A-3

TABELLE 13. ... traditional sales versus evangelism

A-6

TABELLE 14. ... OSI-Modell nach DIN ISO 7498

A-19

TABELLE 15. ... Typologie der Projektorganisation evolutionärer

Sprünge

A-20

TABELLE 16. ... Ausgewählte EAI-Tools

A-32

Einleitung

KAPITEL 1

Einleitung

1.1. Vorstellung der "Firma"

1.1.1. Überblick

Die "Firma" wurde zum 1.4.2001 gegründet, in der zum Startpunkt der

Diplomarbeit 25 Mitarbeiter in den Leistungsbereichen arbeiten.

1.1.2. Leistungsbereiche

· Strategische Unternehmensberatung

IT-Strategie Beratung

Machbarkeitsstudien

Architekturberatung

· Organisationsberatung

Management Informationssysteme

Geschäftsprozesse

Projektmanagement

· Enterprise Systems Management

Service Management

Desktop Management

Systems Management (Anwendungen/Datenbanken, Netzwerk, Remote-

Control, Help Desk, Inventarisierung, Softwareverteilung,

Desktop&Server, Datensicherung/Backup)

· Security Consulting

Business Continuity Konzepte

Security Policies

Security Audits

· Facility Management

Gebäudeplanung

Gebäudesicherheit

Optimierung Gebäudeverwaltung

· Application Integration (EAI

)

Vorstellung der "Firma"

Einleitung

Dieser Leistungsbereich (Arbeitsgruppe), ist gegenwärtig mit der

Entwicklung des Prototypen beschäftigt. Mit ein Ziel dieser

Diplomarbeit soll sein, den Leistungsbereich EAI und das Produkt so zu

positionieren, daß es für das Unternehmen ideal ist (siehe auch

,,Systemgestaltung" auf Seite 3)

1.1.3. Kunden (Auszug)

(In dieser Dokumentenversion nicht enthalten)

1. In dieser Ausarbeitung als EAI beschrieben, um Verwechslungen mit Artificial

Intelligence (AI) zu vermeiden. Der Begriff EAI ist geläufig für Enterprise Application

Integration

Systemgestaltung

KAPITEL 2

Systemgestaltung

2.1. Vorgaben

2.1.1. Zielbeschreibung

Zielobjekt.

· Entwicklung eines, daß Umfeld berücksichtigenden, Prototyps für EAI/

Directory-basierte Dienstleistungen, der in das Portfolio der "Firma"

einzupassen sind.

Zieleigenschaft.

· Erarbeiten von KnowHow

· Entwickeln des Prototyps

· Entwickeln des Produktes

Zielausmass.

· Erfassen und bearbeiten der für das Eingriffssystem definierter Themen

zeitlicher Bezug.

· Im Zeitrahmen einer Diplomarbeit ist die Bearbeitung aller relevanten

Unterpunkte der Systemgestaltung vorgesehen.

· Der Referenzzeitraum dieses Dokumentes basiert auf Informationen bis

Oktober 2001 (time freeze)

2.1.2. Restriktionen

Beachtung der gegebenen Rahmenbedingungen.

· vorhandene Manpower

· Finanzrahmen

· Systemlandschaft des Kunden

· Passend in das Leistungsspektrum der "Firma"

Verwendete Methodik

Systemgestaltung

DirXML als zu verwendende Technologie. Als Basis für den Prototypen

dient Novells DirXML-System.

Begründung:

· Support, Direkte Ansprechpartner

· Schulung innerhalb Deutschland

· Niederlassung in Deutschland, und nicht nur eine

Vertriebsniederlassung, wie bei anderen Lösungen

· Vorhandenes KnowHow in Form von Certified Engineer innerhalb der

"Firma"

Das diese Restriktionen für die Prototypenphase korrekt ist, bestätigt sich

unter ,,Novell DirXML" auf Seite 54

2.1.3. Bearbeitungshinweise

Verlässlichkeit der Informationen. Die Verlässlichkeit der hier

aufgestellten Informationen sind hoch. Es wurden mehrere Quellen als

Quer-Referenzen genutzt - aufgeführt wird jeweils die mit der höheren

Reputation.

Die Referenzen wurden als weiteres zur Stützung der aufgestellten Thesen

genutzt, da das Thema innerhalb der EAI-Szene bereits kontrovers

diskutiert wird und als Bestätigung des objektiven Charakters dieser

Ausarbeitung dienen sollen. Zusätzlich wurde das bereits vorhandene

fundamentale und praktische Wissen des Entwicklungsteams zu diesem

Thema mit integriert.

2.2. Verwendete Methodik

Die Ausarbeitung bedient sich mehrerer Hilfsmodelle: Systems

Engineering für die Abgrenzung der Gesamtarbeit (Umsystem, Umfeld,

Eingriffssystem) und zur Hilfestellung bei der zu wählenden

Ausarbeitungstiefe (Detaillierung). Als weiteres wurde der Aufbau von

Businessplänen als Strukturvorlage für Umfeld und Eingriffsystem

angewendet.

2.3. Systemgestaltung und -abgrenzung

Begriffsdefinition.

· Systeme die auf das betrachtete System Einfluß nehmen bezeichnet man

als Umsystem

· Das ,,Umfeld" beschreibt den für die Systemuntersuchung und --

gestaltung relevanten Teil des Umsystems.

Systemgestaltung und -abgrenzung

Systemgestaltung

· Das ,,Eingriffssystem" umfaßt jenes Gebiet oder jenen Realitätsbereich,

in welchem Eingriffe und Veränderungen im Rahmen einer

Problemstellung möglich sind.

· Die notwendige Tiefe der einzelnen Unterthemen ergibt sich in der

Relevanz für das Thema. Der hohen Komplexität und der

Interdependenzen der Einzelthemen, wird durch die Verknüpfung

miteinander Rechnung getragen. Technische Details sind nur dort von

Belang, wenn sie einen unmittelbaren Wert darstellen, was in diesem

Fall der Prototyp ist. Andere Technologien werden für den interessierten

Leser im Glossar behandelt.

· Die in den Systemen definierten Themen sind offen

, dynamisch

und

teilweise auch vernetzt

. Komplexe

Größen wurden keine festgestellt.

Dem wird durch interne Verweise der Themen aufeinander Rechnung

getragen.

1. offene Beziehungen zum Umfeld

2. einzelne Systeme und die entsprechenden Umfelder sind einer zeitlichen Veränderung

unterworfen, die sich durch die technischen Änderungen und Marktgegebenheiten

ergeben

3. Rückkoppelungen auf das System

4. hinsichtlich ihrer Struktur nicht vollständig beschreibbare Größen - dazu gehören

multistabile Zustände, Selbstorganisation von Mustern und Entstehung von Chaos

TABELLE 1.

Systemgestaltung und -Abgrenzung

Umsystem

Umfeld

Eingriffssystem

Ergebnis

Unternehmen

Kunden

Ausgangssituation

Ziele

Restriktionen

Vorstellung des

Unternehmens

EAI

EAI allgemein

Motivatoren

Ursachen

Verdeutlichen

von EAI im

Gesamt-

zusammenhang

der Thematik

Markt

Situation

Hemmnisse

Anbieter und

Konkurrenz

(Technik/

Consulting)

Marktentwicklung

Marktsituation/

Analyse

Trends

Zahlen

Kunden

Festgestellte Größen mit

Auswirkung auf die

Positionierung:

Marketing

Vertrieb

Strategien

Portfolio

Dienstleistung

Techn. KnowHow

Marktbezogenes

Lösungskonzept

Systemgestaltung und -abgrenzung

Systemgestaltung

Modelle

Anforderungen

verschiedene

Modelle zur

Veranschaulichung

des Vorgehens

(Strategien,

Schnittstellen,

Middleware

Festgestellte Größen mit

Auswirkung auf die

Positionierung:

Angebotspalette der

"Firma"-EAI

Vorgehen/Schnittstellen

Einkreisen auf

Gesamtkonzept

für DirXML.

Auch für Nicht-

IT´ler

verständliche

Vorstellung der

Vorgehensweise

DirXML

Grundkonzept der

DirXML-

Technologie

Vergleich mit

anderen derartigen

Lösungen

Selbstentwickeltes

Beispiel eines Unicenter

TNG-Treibers

Darlegung

Vorgehensweise bei

Entwicklung und Design

Bewertung (Tech/BWL)

Stärken/Schwächen

Dokumentation

Festgestellte Größen mit

Auswirkung auf die

Positionierung:

Dienstleistungsangebot

Erkenntnisse

KnowHow

Detailkonzept

für die

Positionierung

Das Produkt

Kapitalbedarf/

Mittelverwendung

Chancen/Risiken

Organisation der EAI

Produkt- und

Programmpolitik

Strategie

Vorschläge oder

Vorgaben

TABELLE 1.

Systemgestaltung und -Abgrenzung

Umsystem

Umfeld

Eingriffssystem

Ergebnis

Umfeldbetrachtung EAI

KAPITEL 3

Umfeldbetrachtung EAI

3.1. Das ,,Produkt" EAI

Integrationsbemühungen von Anwendungen und Systemen gibt es bereits

seit den 50er Jahren

und stellt eine der wichtigsten Aufgaben der IT-

Abteilungen dar (Anpassung an interne Abläufe, Leistungsfähigkeit der

Systeme, Verfügbarkeit). So wird zunächst, bei oberflächlicher Betrachtung

von EAI, auch mancher Systembetreuer behaupten, daß EAI im Sinne der

Schnittstellenentwicklung an sich nichts Neues ist. EAI ist allerdings

dadurch eigenständig, da diese Art der Integration über

unternehmensinterne Point-to-Point-Verbindungen traditioneller

Middleware hinausgeht, was auch erst durch die Nutzung von XML für die

Systemkommunikation und den Datenaustausch ermöglicht wird.

3.1.1. Motivatoren für EAI

Technisch begründete Motivatoren.

· Die Anpassung von Anwendungen an Geschäftsabläufe wird immer

langwieriger und mit der Schnittstellenentwicklung mittels Point-to-

Point-Verbindung (sog. Spagettiarchitektur) auch schnell unbeherrschbar

aus administrativer Sicht. Gleichzeitig steigt die Anforderung an die

Systeme hinsichtlich Verfügbarkeit und Performance. Der Zeitaufwand

für diese Form der Integration ist enorm und bindet die personellen

Ressourcen.

· Systeme und Datenformate aus verschiedenen Generation, die jeweils

für sich gesehen für das Unternehmen z.B. zur Umsetzung von Data-

Warehouse-Projekten wichtig sind, lassen sich nicht austauschen.

· Investitionsschutz, da sog. Legacy-Systeme weitergenutzt werden

können, wobei sich schätzungsweise mindestens 70% der

Unternehmensdaten auf derartigen Systemen befinden

. Applikationen

auf diesen Systemen nehmen unternehmenswichtige Aufgaben wahr, so

dass Ausfallzeiten bis zur Erstellung neuer Applikationen nicht

hinnehmbar sind und deren Quellcode nicht oder nur unzureichend

1. eaijournal: A brief history in integration, William H. Inmon (http://www.eaijournal.com/

Applicationintegration/BriefHistory.asp)

2. IT-Research: Internet Legacy Connectivity, Schmieder / Pfau (http://www.IT-

Research.net/de/reports/desc/itrlegac.html)

Das ,,Produkt" EAI

Umfeldbetrachtung EAI

dokumentiert ist. Der Grund im Weiternutzen dieser Systeme ist der

hohe getätigte Investitionswert und deren starke Verankerung in den

Kernprozessen des Unternehmens. Sie sind sehr stabil und sicher.

Diese Systeme lassen sich mittels EAI dann aber zu moderneren

Systemen und Architekturen migrieren, da Legacy-Systeme auch

Nachteile haben, wie hoher Administrations- und Wartungsaufwand

wozu auch die Anpassungsarbeiten hinzuzählen.

· Forderung nach Systemen, die Informationen jederzeit auf Knopfdruck

und in aktueller Form zur Verfügung stellen, ganz gleich, wo sie sich

befinden und wie schwierig der Zugriff auch sein mag, ohne von

anderen abhängig zu sein oder durch umständliche Prozeduren

(Informationshirarchien) behindert zu werden.

· Die EDV macht nicht das, wofür sie ursprünglich gedacht ist -

Routineaufgaben automatisieren. So müssen beispielsweise Mitarbeiter

die Bestellungen manuell aus dem Webshop in das ERP-System (z.B.

SAP) übertragen, da keine Verbindung zwischen diesen beiden

Systemen realisiert wurde.

,,Computers make it easier to do a lot of

things, but most of the things they make it

easier to do don´t need to be done"; Andy

Rooney

Betriebswirtschaftlich begründete Motivatoren.

· Befreiung von Routinetätigkeiten

Diese Punkt geht bereits in Richtung Prozessintegration mit dem

Rückgriff auf graphisch orientierter Tools zur Modellierung und

Steuerung von Prozessen. Gegenwärtige EAI-Projekte basieren

nachwievor auf roher Hirnleistung - hierzu sind neue Werkzeuge zu

entwickeln, um diese Aufgaben auf der Prozessebene abzubilden und

somit auch Nicht-IT´lern neue Verknüpfungen zu ermöglichen (siehe

auch ,,Level 3: Intra-Enterprise-Integration (Prozessintegration)" auf

Seite 42, ,,Middleware-orientiertes Modell" auf Seite 46,

,,Näherungsdefinition von Sterling, Aufschlüsselung" auf Seite A-17

und ,,Processware" auf Seite A-24)

· Unternehmen, die die Mammutaufgabe der Einbindung eines

,,Enterprise Ressource Planning - Systems (ERP) wie SAP R/3 in ihr

Unternehmen bewältigt haben, müssen feststellen, daß diese Systeme

noch immer nicht alle Geschäftsmodelle und -dimensionen abbilden

können. So werden weitere Systeme für Supply Chain Management

(SCM) und Customer Relationship Management (CRM) zusätzlich

genutzt. Um jedoch die Reaktionsgeschwindigkeit des gesamten

Unternehmens zu erhöhen, müssen diese Systeme innerhalb von

Rechner-Rechner-Systemen miteinander agieren können

3. attachmate: Ansätze zur Enterprise Application Integration (EAI) unter Einbeziehung

traditioneller Anwendungen (http://de.attachmate.com/article/0,1012,3163_14,00.html)

4. David S. Linthicum, Enterprise Application Integration: The elusive Enterprise API, S.

291, Addison-Wesley

Das ,,Produkt" EAI

Umfeldbetrachtung EAI

3.1.2. EAI als fundamentale Basis für ebusiness

Die Möglichkeiten des EAI werden angesichts der Fusionswellen und des

stärkeren Zusammenwachsens zu immer größeren Unternehmen

zunehmend wichtiger, wenn nicht sogar die notwendige solide Basis für

eBusinessiness-Projekte. Aber die angestrebten Ziele des EAI gehen

wesentlich weiter, als die unternehmensinterne Koppelung von

Anwendungen.

,,Bei der Implementierung von Technologien

zur Anwendungsintegration geht es im

wesentlichen darum, das Unternehmen

effizienter und profitabler zu gestalten und es

als Geschäftspartner für die Vielzahl

verschiedener Kunden besser aufzustellen

und besser zugänglich zu machen." Gartner

,,Total Business Integration", R. Altman,

Februar 2001

Die Vision. Der visionäre Ansatz für EAI-Lösungen sieht die Abbildung

kompletter Geschäftsprozesse vor (Prozessintegration), die vollautomatisch

über Unternehmensgrenzen, Anwendungen und Systeme hinweg ablaufen

(Workflow), indem die bisher einzeln laufenden Anwendungen, wie

Customer Relationship Management (CRM), Enterprise Ressource

Procurement (ERP) und Supply Chain Management (SCM)

miteinander

kommunizieren. Dem zugrunde liegen verschiedene theoretische Modelle,

die in der Literatur als ,,Event-driven-Enterprise"

, oder wie das von

Gartner definierte ,,Zero Latency Enterprise"

auf Basis von ,,Enterprise

Nervous Systems (ENS)

9)10)

- Middleware, indem jede Transaktion oder

Applikation Zugang zu jeder anderen Anwendung ohne Limitierung und

augenblicklich [in Echtzeit zur Wahrung der Datenintegrität] hat,

erscheinen. Dies vermischt sich mit B2B

-Projekten (ebusiness) in

Erwartung zusätzlicher Ertragsquellen, weiterer Kostenersparnisse, höherer

Kundenzufriedenheit und möglicher Produktivitätssteigerungen

, einfache

5. attachmate: Enterprise Application Integration: Erfolgreiche Schritte auf dem Weg zu

verknüpften Geschäftsprozessen, Mai, 2001 (http://de.attachmate.com/article/

0,1012,3613_14,00.html)

6. ,,In anderen Worten bezeichnet EAI den technischen Unterbau eines sich radikal

verändernden Supply-Chain-Managements", Computerwoche Nr. 30 vom 28.07.2000

7. The Power of Now: How Winning Companies Sense & Respond To Change Using Real-

Time Technology, Vivek Ranadive, MCGraw-Hill, 1999

8. David S. Linthicum, Enterprise Application Integration: The elusive Enterprise API, S.

55, Addison-Wesley

9. Gartner: ENS: Middleware Best Practices in the E-Business World, Y. Natis, 11.4.2001,

(http://www3.gartner.com/resources/97300/97341/97341.pdf)

10.Wobei sich das Naturmodell nur für selbstlernende Systeme unter Berücksichtigung

komplexer Dynamik und Rückkoppelung in diese Systeme anbieten würde. Nur weil

etwas schnell reagiert, könnte man es auch ,,Jet, Realtime, o.a." nennen.

11.Business to Business

Das ,,Produkt" EAI

Umfeldbetrachtung EAI

Umsetzbarkeit von Unternehmensallianzen

, einem schnellerem Time-to-

Market und Flexibilität

, die aus betriebswirtschaftlicher Sicht, auf die

Grundlagen des Supply Chain Management

zurückzuführen sind (siehe

,,Prozessintegration" auf Seite A-21). Durch diese Vermengung von

Betriebswirtschaft und Technik ist die klassische Trennung von BWL- und

IT-motivierten Themen auf lange Sicht nicht mehr möglich und wird

Auswirkungen bei zukünftigen Prozessmodellierungen und der IT-

Beschaffung haben und wird auch die Fixierung auf Kennzahlen bei IT-

Projekten ändern (müssen), denn die potentiellen Fähigkeiten von EAI sind

nicht nur mit finanz-orientierten Kennzahlen, wie dem Return of Investment

(ROI) erfassbar, sondern erfordern auch die Berücksichtigung nicht direkt

monetarisierbarer Kennzahlen, wie den Erwartungswerten (Return of

Opportunity/ROO).

,,Im Rahmen von E- und C-Commerce sowie

Supply-Chain-Management entsteht bei

Anwendern nun zunehmend der Zwang,

diese Anwendungsinseln zu integrieren.

Schinzer: "Nur wer Prozesse innerhalb des

Unternehmens durchgängig gestaltet hat und

darüber hinaus seine Partner IT-technisch

und organisatorisch einbindet ist im E-

Business erfolgreich." EAI-Plattformen

könnten dabei helfen"

Ein Resultat dieser Bemühungen ist die mögliche enge Verbindung von

Frontoffice und Backoffice, um hierdurch einen durchgängigen

Informationsfluß über eine vernetzte Wertschöpfungskette (siehe

,,Prozessintegration" auf Seite A-21) zu erreichen und hierbei nicht nur

interne, sondern auch externe Partner spontan mit einzubeziehen (was von

XML addressiert wird, der ältere Standard hierzu ist in Form von Electronic

Data Interchange (EDI) gegeben, siehe auch ,,EDI vs XML" auf Seite A-

9). Diese Systeme ermöglichen nicht nur die zeitechte und straffe

Bearbeitung von Vorgängen (Beschaffung, Lagerhaltung usw.) und der

Erledigung von Routineaufgaben innerhalb von Workflows, sondern

können, unter Nutzung neuronaler Agenten und Datawarehouses, auch

zuverlässige Vorhersagen bzw. Simulationen über zukünftige

12.attachmate: Ansätze zur Enterprise Application Integration (EAI) unter Einbeziehung

traditioneller Anwendungen (http://de.attachmate.com/article/0,1012,3163_14,00.html)

13.eai Journal: The Molecular Economy, Tony M. Brown, Mai 2000 (http://

www.eaijournal.com/PDF/Molecular%20Economy.pdf)

14.eai Journal: The Molecular Economy, Tony M. Brown, Mai 2000 (http://

www.eaijournal.com/PDF/Molecular%20Economy.pdf)

15.ITtollbox: Leveraging Your Legacy Systems In Pursuit of Customer Relationship

Management, Luis Delahoz, ClientSoft (http://eai.ittoolbox.com/

browse.asp?c=EAIPeerPublishing&r=http%3A%2F%2Fdelahoz%2Ecrmproject%2Eco

m%2F)

16.Computerwoche: EAI entwächst der Bastelstube, Bernd Seidel, 28.05.2001(http://

www.computerwoche.de/index.cfm?pageid=254&artid=21980)

Das ,,Produkt" EAI

Umfeldbetrachtung EAI

Entwicklungen machen wobei EAI für die Bereitstellung der Daten genutzt

werden kann.

Wenn die Daten sich mittels eines handelsüblichen html-Browsers abrufen

lassen, ist die Verbindung hergestellt zu einem sog. ,,Enterprise

Information Portal" (EIP), der die Darstellung von Inhalten (Dokumente,

personalisierte Informationen) ermöglicht und die Schnittstelle zum Nutzer

darstellt. Das Prinzip des ,,Single Point of Access" ist nicht neu und wurde

bereits in den späten 80er Jahren versucht mit ,,Executive Information

Systems" (EIS) umzusetzen, stieß damals jedoch an die Grenzen des

technisch Machbaren. Wenn innerhalb dieser Portale auch der aktive

Zugriff auf Daten und Methoden stattfindet, wurde hierfür der Begriff

,,Enterprise Application Portal" (EAP) definiert, wobei dann der Schritt

zum ,,Application Service Provider" (ASP) gestützten ,,Internet Application

Integration" (IAI

) nicht mehr weit ist (zumindest von der Vision her).

Begriffe. Bei Gartner wird in diesem Zusammenhang der umfassenden

Geschäftsintegration von ,,Total Business Integration" gesprochen, was an

der Problematik vorbeigeht - ein reines Schlagwort, daß abzulehnen ist, da

es auch nicht definiert, ob hiermit die Integrationsbreite (nur Teile eines

Unternehmens, oder die komplette Wertschöpfungskette mit IT und Non-

IT-Einheiten) oder Integrationstiefe (die zu integrierenden Ebenen, siehe

,,Schnittstellenorientiertes Modell" auf Seite 44) gemeint ist. Eine

Vorstellung, warum diese Begriffe falsch sind gibt die Abhandlung im

Anhang ,,Workflow vs. Prozesse" unter ,,Prozessintegration" auf Seite A-

21. Da ist die Definition von Pricewaterhousecoopers, die EAI als

,,eBusiness-enabling Technologies

" bezeichnet, schon ehrlicher und sagt

in diesem kurzen Begriff alles relevante aus.

Anforderungen von E-Business an die IT

· E-Business setzt integrierte Prozesse voraus, die einen Datenaustausch

zwischen Unternehmen gewährleisten.

· Datenintegration in Realtime anstelle von Datenaustausch und

Replikationsmechanismen bringt Geschwindigkeitsvorteile.

· Globale Vernetzung erfordert 24-Stunden-Verfügbarkeit der beteiligten

Systeme bzw. Daten.

· Ständige Veränderung der Geschäftsprozesse, die eine Integration in

neue oder bestehende Applikationen erfordern.

· Immer kürzere Realisierungszyklen: die funktionalen Anforderungen

müssen zeitnah umgesetzt werden.

· Der technologische Anspruch an Realisierungsvorhaben ist spürbar

angestiegen.

· Prozeß- und Systemlebenszyklen werden zunehmend verkürzt.

17.eaijournal: A market is born, Rich Seeley, Januar 2000 (http://www.eaijournal.com/

Applicationintegration/IAI.asp)

18.Pricewaterhousecoopers, Leitfaden E-Business: EAI: Die Pflicht vor der E-Business-Kür,

Seite 8

19.vgl. Pricewaterhousecoopers: Leitfaden E-Business: EAI: Die Pflicht vor der E-Business-

Kür, Seite 19

Das ,,Produkt" EAI

Umfeldbetrachtung EAI

· Neue technologische Trends müssen effizient integrierbar sein.

Die Realität. EAI ist innerhalb der USA schon länger ein Thema und so

sind die meisten Produkte auch amerikanischer Abstammung, wobei die

deutschen Anbieter nach deren eigener Meinung nachgezogen haben und

mittlerweile mit eigenen Entwicklungen gut mithalten können

, wobei

sich bei genauer Betrachtung diese jedoch zumeist auf die großen ERP-

Pakete konzentrieren - Killeranwendungen hat noch keiner und es gibt

keinen eindeutigen Marktführer (siehe ,,Marktentwicklung EAI-Software"

auf Seite 23).

Bis heute haben sich relativ viele Softwarefirmen und Dienstleister, die mit

dem Titel EAI werben, herausgebildet. Dutzende werden als sog. ,,leading

EAI vendors" bezeichnet, deren Produkte mit Superlativen beworben

werden, die teilweise eine point-and-click-Integration versprechen, bzw.

Möglichkeiten bieten sollen, womit sich das gesamte Unternehmen

automatisieren lassen soll. Allerdings besteht zwischen den Visionen und

der Realität, wie sie sich beim Kunden zeigt, eine starke Diskrepanz, denn

gegenwärtige EAI-Projekte verbinden maximal 3-4 Systeme

unter

Nutzung einer Vielzahl von Produkten

22)23)

, was eher einem aufgebohrtem

Workflow gleichkommt, als einer korrekten SCM basierten

Prozessintegration per Definition (siehe ,,Workflow vs. Prozesse" unter

,,Prozessintegration" auf Seite A-21) und wiederspricht prinzipiell

vollkommen der Vision des EAI (EINE standardisierte Schnittstelle

). Es

gibt kein universelles Tool, welches ohne Anpassung an die Umgebung und

schon gar nicht ohne Beratung, die in das Tool gesetzten Erwartungen

erfüllen kann, da diese nur sehr spezielle Aspekte adressieren und

bestimmte Umfeldbedingungen voraussetzen. Erschwerend kommt hinzu,

daß in einem Unternehmensprozeß, wie der Produktentwicklung (Design

Chain) durchaus 20 verschiedene Anwendungen zum Einsatz kommen

können, wenn man in die Integrationsbreite geht

Ebenso ist die wahre Leistungsfähigkeit bezüglich der Funktionen in den

EAI-Anwendungen einfach noch zu beschränkt, wie der Abbildung 1 zu

entnehmen ist

26)27)

. Dieses beschränkt sich auf die ERP-Anwendungen von

Clarify, JDEdwards, Oracle und SAP. Hierbei fehlt beispielsweise noch

Amdocs, Baan, Kenan, PeopleSoft, Remedy und Vantive.

20.Computerwoche Nr. 38 vom 22.09.00 Seite 24

21.Und auch hier nur ausgewählte Funktionen und Daten

22.eaiQ: Enterprise Evolution: Where EAI Meets B2B, Interview mit David Linthicum

(Saga Software), (http://eai.ebizq.net/enterprise_integration/linthicum_1.html)

23.Marc Buyens, Whitepaper: Enterprise Application Integration, Sterling Software,

September 1999; (http://eai.ittoolbox.com/

browse.asp?c=EAIPeerPublishing&r=http%3A%2F%2Fwww%2Expragma%2Ecom%2

Feai%5Fwp%2Ehtm)

24.David S. Linthicum, Enterprise Application Integration: The elusive Enterprise API, S.

55, Addison-Wesley

25.Dr. Michael Heimlich, Design Chain Management, EAI Journal, Februar 2001

26.Eine ähnliche, aber leistungsfähigeres Werkzeug dieser Art ist auf Apple-Plattform

mittels Applescript serienmäßig vorhanden, wobei Anwendungen gegenseitig Daten

,,abonnieren" können - und es kostet nichts extra.

Das ,,Produkt" EAI

Umfeldbetrachtung EAI

Die Realisierung. EAI (und somit auch ebusiness) ist kein rein technisches

Thema, sondern erfordert ,,die ganzheitliche Betrachtung von Technik und

Prozessen"

, wobei ,,die Vorraussetzung für ebusiness ein

prozesszentrisches und nicht ERP-zentrisches Denken"

erforderlich

macht. Die neuen Möglichkeiten beeinflussen die gesamte

Wertschöpfungskette und über lange Zeit gewachsene

Unternehmensstrukturen, welche sich nur langsam anpassen lassen. Hier

beginnt der Ansatz für die Dienstleister. Denn das EAI-Tool ansich, ist nur

ein Werkzeug - die eigentliche Integrationsaufgabe erfordert eine

umfassende Strukturanalyse und Modellierungen, womit sich EAI als ein

beratungsintensives Produkt darstellt, so daß die Umsätze mit der

Dienstleistung höher sein dürften, als mit dem eigentlichen Produkt. Dies

widerspricht dem oben bereits ausgeführtem Anspruch mancher EAI-Tools,

daß mit diesem Tool die Aufgabe bereits gelöst sei. Genauso bedenklich ist

anzusehen, daß seitens vieler betriebswirtschaftlicher

Entscheidungsinstanzen trotzdem geglaubt wird, daß mit

Standardprodukten diese Integration bereits erledigt sei. Weiter fehlt zum

Teil auch das Verständnis für diese Integrationsproblematik, so daß diese

Themen innerhalb des Managements zumeist erst innerhalb einer

ebusiness-Strategie Gehör finden, was auf den EAI-Symposien auch sehr

bemängelt wird.

Mit Rückblick auf die Fehler, die ebenfalls in den letzten

27.Die Art und Weise, wie solche Produkte am Markt erscheinen, ist in einem ähnlichen Fall,

in dem die Mängel von Outlook mittels eines DM 16.000.- Produktes auszugleichen

versucht wurde - das Produkt verschwand zunächst und erschien unter einem anderen

Namen wieder am Markt.

28.Ulrich Pappe, Anwendungszentrum Logistikorientierte Betriebswirtschaft am

Paderborner Fraunhofer-Institut, Computerwoche, Nr. 30 vom 28.07.2000

29.Wolfgang Martin, Meta Group, Computerwoche Nr. 30 vom 28.07.2000

30.Hans-Ulrich Breme, Solution Architect, Candle, Computerwoche, Nr. 30 vom 28.07.2000

ABBILDUNG 1.

Vorkonfigurierte Synchronisierungsfunktionen in webmethods

Das ,,Produkt" EAI

Umfeldbetrachtung EAI

Jahren innerhalb des SCM (Kausaler Zusammenhang zum Supply Chain

siehe im Kapitel ,,Prozessintegration" auf Seite A-21) gemacht wurde

(mangelhafte Modellierungen, fehlendes Prozessmanagement) ist bereits

jetzt abzusehen, daß die selben Fehler mit EAI wiederholt werden. Es liegt

zwangsläufig nicht an der Technologie, wenn komplexe Projekte scheitern

(aber je komplexer die Technologie wird, umso mehr verstärkt sie den

Effekt) (siehe auch ,,Risikoabschätzung" auf Seite 83). Die Fehler werden

mit EAI einfach wiederholt, die wenigsten haben ihre Hausaufgaben

gemacht und ihre Prozesse einmal intern durchgängig gestaltet.

,,Die Sünden der Vergangenheit holen die

Betriebe nun wieder ein. ,,Wer D2D

(D =Department/Abteilung) nicht

beherrscht, lernt B2B oder B2C nicht

mehr.

Darum darf ebusiness und in Folge auch EAI nicht als Trend gesehen

werden - es ist vielmehr eine Grundsatzentscheidung, die auf

Vorstandsebene zu treffen ist und bedeutet die zwingend gleichberechtigte

Zusammenarbeit von IT-Spezialisten und dem Management. Solche

Projekte sind von Anfang an als abteilungsübergreifende Projekte zu

verstehen. Die Aufgabe des Dienstleisters ist hierbei, auf Grundlage einer

fundierte Geschäftsprozessmodellierung, den Kunden auch dahingehend zu

beraten, ob ein solches Tool überhaupt und in welchem Maße für ihn

sinnvoll ist und definiert die zu realisierenden Meilensteine. Aus diesem

Grund ist es für den Berater wichtig, daß er als Systemanbieter (Technisch

und Organisatorisch) auftreten kann, um eine differenzierte/skalierbare

Lösung anbieten zu können, ohne das der spätere Lösungsweg durch die

Fähigkeiten des Tools bestimmt wird. Derzeit ist es allerdings so, daß EAI-

Projekte mit der Tool-Auswahl beginnen und sich auf deren Einsatz

beschränken

, ohne daß, wie gefordert, die Prozessmodellierung

vorausgeht, und die EAI-Produkte nur als Mittel zum Zweck zu sehen

sind

. Es ist abzusehen, daß mit Fortsetzung des ,,management by

magazines" bei IT-Projekten und in Folge aus organisatorischer Sicht,

erhebliche Schwierigkeiten auf die Firmen zukommen werden. Die

gegenwärtige ,,must have" Philosophie in den Unternehmen zeigt hierbei

wieder traurige Parallelen mit dem eBusiness-Hype.

Zusammenfassung.

· EAI ist kein Produkt, sondern eine Modellvorstellung, die auf der

Kombination mehrerer EAI-unterstützender Produkte beruht

· Keines der gegenwärtigen Anwendungen (Entwicklungswerkzeuge,

Middleware) erfüllt diese Anforderungen annähernd

31.Computerwoche, EAI entwächst der Bastelstube, Bernd Seidel, 28.05.2001

32.Ulrich Pappe, Anwendungszentrum Logistikorientierte Betriebswirtschaft am

Paderborner Fraunhofer-Institut, Computerwoche, Nr. 30 vom 28.07.2000

33.Herbert Sattler, Systemarchitekt Fujitsu-Siemens, Computerwoche, Nr. 30 vom

28.07.2000

Ursachen gegenwärtiger Schwierigkeiten

Umfeldbetrachtung EAI

· Eine Näherung daran, ist lediglich durch die fiktive Kombination

mehrerer EAI-Produkte möglich, wobei diese Pakete immer nur

spezielle Aspekte adressieren.

· Es ist mit realistischen Erwartungen an EAI-Projekte heranzugehen.

Aber auch ein Zögern bezüglich EAI ist falsch, da enorme Potentiale in

EAI im Sinne des ,,know-how" und ,,know-why (not)" stecken.

· EAI ist eine kontinuierliche Entwicklung, da nach Ablauf der

Implementierungsphase neue Anwendungen und Systeme ebenso in das

System integriert werden (und das EAI-Produkt auch diese unterstützen

können muss).

3.2. Ursachen gegenwärtiger Schwierigkeiten

Die gegenwärtigen Schwierigkeiten sind teilweise historisch begründet und

auch von der jeweiligen Firmenpolitik abhängig:

3.2.1. Technologiebezogene Ursachen

· Proprietäre ,,Standards"

· Universeller Einsatz von PC´s

· Technologie

Dies stellt ein trauriges Resultat des ,,management by magazine" dar. So

arbeiten praktisch autarke Systeme auf den Schreibtischen der Mitarbeiter,

die über mehr Rechenleistung verfügen, als eine Cray 1 von 1976 für

$700.000 zur Verfügung stellen konnte. Diese Investitionen verpuffen dabei

auf mehrere Arten innerhalb der Unternehmen, bereits bei ganz

oberflächlicher Betrachtung:

· Kosten (Wartung/Updates/Patches/Fixes)

· Unzugänglichkeit der Daten, wenn Mitarbeiter nicht am Platz bzw. im

Urlaub sind

· Standalone-Prinzip (Rechenleistung der Maschine steht anderen

Rechnern eines Standard-Windows-Netzwerkes nicht zur Verfügung).

Solche Systeme sind im Prinzip auf keinen Server angewiesen und im

Sinne des EAI eine Horrorvorstellung.

· Verschärfend kommt hinzu, daß diese Systeme sich nicht im geringsten

ähneln - der größte Hinderungsgrund bei der Eigenentwicklung eines

Enterprise Information Portals (EIP) auf Basis des Microsoft Digital

Nervous Systems war, daß Rechner, die sich eigentlich nicht

unterschieden, trotzdem unterschiedlich auf die entwickelte Software

reagierten, was zum Schluß in einer Workaround-Schlacht ausartete

34.(siehe ,,Kundenbindungsorientierte vs. standardisierte Lösungen" auf Seite 18 und

,,Standard (Definition/Eigeninterpretation)" auf Seite A-25)

35.Lutz Pischke, Entwicklung eines B2E-Portals auf Basis des Microsoft Digital Nervous

Systems, 08/2000

Ursachen gegenwärtiger Schwierigkeiten

Umfeldbetrachtung EAI

Gegenbewegung. Dem zu entgegnen, ist derzeit der positive Trend zur

Thin-Client-Architektur zu beobachten, deren Eigenschaften bereits unter

den Begriffen Net-PC, Diskless Workstation oder netboot-Funktion, mit

leichten Abwandlungen, aber im Prinzip gleichem Inhalt, in den letzten

Jahren umgesetzt wurden. Pate stand hierbei das Prinzip der Mainframe aus

den 60er Jahren, nur das diese im Gegensatz zu den gegenwärtigen

Computern lediglich über Text-basierte Befehlsoberflächen verfügten. Der

Vorteil dieser Architektur ist es, daß einfach der mittlerweile bei manchen

Unternehmen 2-jährige Neubeschaffungszyklus unterbrochen wird und die

vorhandenen Rechner weitergenutzt werden können, da die Rechenlast auf

einen Server übertragen wird - dies geschieht im Zuge des gegenwärtigen

Trends, die Microsoft-orientierten Systeme in den dafür geeigneten

Bereichen nicht mehr zu beschaffen (siehe ,,Abwendung von Microsoft-

zentrischer IT im IT-Backbone" auf Seite 27).

Diese Projekte sind zumeist OpenSource-orientiert. Bedenklich ist

lediglich der wiederholte ,,management by magazine" - getriebene

Rundumschlag, alles im Unternehmen auf Opensource umzubauen.

Hierbei ist der Ansatz, wie ihn diese Diplomarbeit verfolgt, ganz anders,

um nicht zu sagen ein Paradigmawechsel (siehe ,,Zusammenfassung" auf

Seite 71), wobei der Kunde seine bestehenden Anwendungen und Systeme

behalten und die Lösung mit seinen Bedürfnissen wachsen kann, wie die

noch folgenden Kapitel aufzeigen werden.

3.2.2. Ursachen in der Art der IT-Beschaffung

Verantwortung der Architektur. Bei Fehlen eines für die Architektur

Verantwortlichen IT-Managers ist die Gefahr groß, daß, neben der

,,management by magazine"-typischen Orientierung an Kennzahlen und bei

IT-Entscheidungen mit Konzentration auf Abteilungsebene (Stovepipes),

die IT-Beschaffung und Architektur (siehe ,,Level 1: Point-to-Point-

Integration (P2P)" auf Seite 40) lediglich die abteilungseigenen

Anforderungen berücksichtigt, so daß innerhalb des Unternehmens eine

Mischung aus miteinander unverträglichen und teilweise in kürzester Zeit

für eBusiness unbrauchbaren Systemen entsteht

Grad des Einbezugs des Managements in IT-Entscheidungen. Genauso

liegt eine Gefahr darin, einem Administrator ein System für Einzelaufgabe

vorzuschreiben, mit dem oberflächlichen Hintergrund der

Homogenisierung der Betriebssystemumgebung, von dem jedoch bekannt

ist, das in diesem speziellen Fall ein anderes Betriebssystem diese Aufgabe

wesentlich besser lösen kann. So setzt der Administrator seinen

Arbeitsplatz auf´s Spiel und setzt das angemessenere Betriebssystem für

diese Aufgabe ein - das Management ist zufrieden im Glauben seine

Forderungen durchgesetzt zu haben und preist sein durchgesetztes System

als gut. Das gleiche Management frohlockt dann, wenn der Trend zu einem

anderen Betriebssystem geht und erfährt, daß sie es bereits einsetzen, wofür

36.Beispiel: In einem ÖPNV-Unternehmen, war es unmöglich, nach Umstrukturierung einer

Abteilung mit einem spezialisiertem CAD-System die Arbeit fortzusetzen, da der

hauseigene Geometer mit diesem System keine Daten austauschen kann

Ursachen gegenwärtiger Schwierigkeiten

Umfeldbetrachtung EAI

ist Nebensache und fordert den Einsatz dieses Systems für alle anderen

Aufgabe auch, womit das Spiel von vorne los geht

. (Dies ist kein

Widerspruch zur Forderung nach einheitlicher Architektur - sie definiert

sich nicht über die Konzentration auf ein einziges Betriebssystems).

3.2.3. Ursachen in der Softwareindustrie

Das nachfolgende Zitat beschreibt das gesamte Dilemma und befreit diese

Arbeit von dem potentiellen Vorwurf, voreingenommen oder zu scharf

formuliert zu sein. Die zugrunde liegenden Theorien sind trotz

Namensgleichheit des Artikels (Spirit of the frontier) nicht mit denen der

Final Frontier Theorien zu verwechseln.

,, [...] Die grundlegende Feststellung, daß die

gesamte IT-Branche mit Software-Onanie

beschäftigt ist, können wohl viele von uns

unterschreiben. Auf die nützlichen, einfachen

Lösungen warten wir immer noch -

Programme, die jeder bedienen kann. [...]

Irgendwo auf dem langen Weg war eine

Abzweigung, die man leider verpaßt hat.

Wenige sind es, die sich jetzt auf den Weg

zurück machen, um nachzusehen, wo man

abbiegen hätte müssen. [...] Wieviele werden

es sein, die sich noch einmal um die

Vordenker zu scharen bereit sind? Dort ist

nicht das schnelle Geld zu machen, die

businessmen sitzen woanders, bei der

elektronischen Schwerindustrie (copyright

players. Der Rubel rollt in den Konzernen,

die nur mehr den Kadaver der

Computerrevolution verwalten. Tatsächliche

Erneuerung, die neue Benutzerschichten

erschliesen hilft und kreatives Potential

freisetzt, findet an anderer Stelle statt. Der

Geist von Xerox PARC ist verweht, die

Morgenluft der Gründerstimmung ist dem

37.Erfahrungswert: Windows gegen Linux, Ablehnung eines Betriebssystems das auf

OpenSource basiert; Ablehnung einer Hardwarefirewall, da diese von andere auch nicht

eingesetzt wird

Details

Seiten
Erscheinungsform: Originalausgabe
Erscheinungsjahr: 2002
ISBN (eBook): 9783832456504
ISBN (Paperback): 9783838656502
DOI: 10.3239/9783832456504
Dateigröße: 1.8 MB
Sprache: Deutsch
Institution / Hochschule: Fachhochschule Esslingen Hochschule für Technik Esslingen – Wirtschaftsingenieurwesen
Erscheinungsdatum: 2002 (Juli)
Note: 1,0
Schlagworte: novell dirxml infrastrukturlösung produktentwicklung prozessintegration
Produktsicherheit: Diplom.de

Autor

Peter Lutz Pischke (Autor:in)