Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

03.11.2000 - 

Application on Demand/Integration entscheidet über Qualität

Bei gemieteten Applikationen liegt die Herausforderung im Frontend

Inwieweit sich beim Application-Service-Providing der Leistungsumfang einer Software nutzen lässt, hängt wesentlich von deren Architektur ab. Laut Richard Nußdorfer und Dimitrios Kouros* spielen Integrationskomponenten dabei eine entscheidende Rolle, denn eine Neuprogrammierung der Software stößt schnell an technische und wirtschaftliche Grenzen.

Kaum ein Thema hat in den vergangenen Jahren die Phantasie von Softwareanbietern und -anwendern so beflügelt wie Application-Service-Providing. Die Unternehmen versprechen sich eine Entlastung von aufwändiger Implementierung und Pflege ihrer IT-Systeme, von mühsamer Suche nach qualifiziertem Personal. Letztendlich hoffen sie auf erhebliche Kosteneinsparungen. Die Anbieter entwickeln neue Geschäftsmodelle: Zusätzlich zur Übernahme des IT-Betriebs für die Anwenderfirmen können Servicepakete geschnürt werden, die den kompletten Benutzersupport ebenso wie Beratung umfassen.

Gerade für mittelständische Firmen könnten die IT-Anbieter ihre auch heute schon zentrale Rolle als Mitgestalter der betriebswirtschaftlichen Prozesse noch kompakter und effizienter erfüllen. Voraussetzung dafür ist allerdings, dass die Basis für diese Geschäftsbeziehung, sprich die Technik, stimmt. Das heißt, die Bereitstellung von Software über das Internet darf keine wesentlichen Abstriche, weder bei Funktionalität noch bei Verfügbarkeit und Komfort, zur Folge haben.

Um gegenüber den intern installierten Anwendungen konkurrenzfähig zu sein, müssen ASP-Angebote aus technischer Sicht folgende Anforderungen erfüllen:

- Die Funktionalität muss vollständig zur Verfügung stehen;

- das Frontend, mit dem der Anwender das System bedient, muss Internet-fähig sein;

- die Anwendungen müssen mandantenfähig sein, das heißt die Daten getrennt für jeden Kunden in einer eigenen Datenbank gespeichert werden;

- die Verfügbarkeit der Anwendungen muss vom Netzwerk sowie von der Soft- und Hardwareseite garantiert werden;

- durch Sicherheitsmechanismen muss Schutz vor unberechtigtem Zugriff und vor Datenverlust gewährleistet sein;

- es muss technisch sichere (und wirtschaftlich interessante) Abrechnungsmöglichkeiten geben;

- ein Installationsplan und eine Fall-Back-Lösung müssen die Rückkehr zur individuellen Installation ermöglichen.

Viele dieser Punkte wie etwa die Fragen nach der Netzverfügbarkeit, der Sicherheit und der Abrechnung sind Grundsatzthemen, die generell mit dem Internet zusammenhängen und unabhängig vom ASP-Modell gelöst werden (oder vielleicht auch ungelöst bleiben, wie zum Beispiel der Schutz vor krimineller Energie). Auf der Hardwareseite ist es selbstverständlich, dass Systeme mit hoher Verfügbarkeit bevorzugt werden sollten. Um die Ausfallsicherheit zu erhöhen, kann auch auf Clustertechnik zurückgegriffen werden. Für die anderen der genannten Punkte wie die Mandantenfähigkeit oder die Fall-Back-Möglichkeit verfügen viele Softwarehersteller bereits über bewährte Lösungen. Die entscheidende ASP-spezifische Frage lautet somit, ob die vorhandenen Funktionen eines ERP-Systems über eine Internet-taugliche Oberfläche zugänglich gemacht werden können.

Die Antwort auf diese Kernfrage liefert eine Architektur, die sich auf drei Säulen stützt: das Internet-Frontend-System, die Komponenten für Enterprise Application Integration (EAI) sowie die ERP-Anwendung selbst. Für eine Umsetzung des ASP-Modells sind vor allem die beiden ersten Säulen relevant, da eine vorhandene ERP-Anwendung, die als Backend-System funktional unverändert bleibt, nur der Integration durch ein API (Application Programming Interface) bedarf. Die beiden neuen Säulen haben die Aufgabe, die vorhandenen ERP-Masken ohne Programmierarbeit ins Internet zu stellen und die Integration der Geschäftsprozesse mit dem Frontend-System herzustellen. Das Frontend steht dabei vor dem Problem, die Optik der Oberfläche und das Navigieren in den Masken so zu gestalten, dass die Benutzer den neuen Client akzeptieren.

Komponente 1: ERP-AnwendungDas ERP-Backend-System beinhaltet die betriebswirtschaftlichen Funktionen, die unverändert beibehalten werden. Um diese ERP-Funktionen ASP-fähig zu machen, bedarf es einer Schnittstelle, über die alle erforderlichen betriebswirtschaftlichen Transaktionen aufgerufen und die Daten ausgetauscht werden können. Beispiel: Wer eine bestimmte Rechnung sehen möchte, muss die Auftragsnummer (oder andere eindeutige Kennzeichen) eingeben und bekommt die Rechnung zurück. Die Transaktion heißt also "Auf Basis des Auftrags die Rechnung suchen und in der Internet-Maske anzeigen". Die dafür erforderliche Schnittstelle ist ein Event-API, über das im Real-Time-Modus alle Anforderungen hereinkommen, im ERP-System in Form von Transaktionen betriebswirtschaftlich bearbeitet werden und als Ergebnis am API zur Verarbeitung in Fremdsystemen wieder zur Verfügung gestellt werden. Das ERP-System ist der passive Teil, der auf Events reagiert, die vom Endbenutzer über das Internet erzeugt werden. Dieses API arbeitet bidirektional, nimmt Events entgegen und stellt die Antworten bereit.

Als Schnittstelle zu allen denkbaren Frontends ist dieses API die Voraussetzung für die ASP-Fähigkeit. In der Windows-Welt kann es zum Beispiel als DCOM-Interface entwickelt sein. Die Event-Schnittstelle ist die Basisausstattung, die jeder ERP-Hersteller seiner Software mitgeben muss; sie hat generellen Charakter und kann für viele Anwendungsfälle benutzt werden. Die ERP-Funktionalität selbst muss für den ASP-Einsatz nicht umgeschrieben werden. Es ist auch nicht von Belang, in welcher Sprache die Software geschrieben ist.

Komponente 2: Enterprise Application IntegrationDer EAI-Komponente kommt die Aufgabe zu, das Frontend mit dem ERP-System zu verbinden. Dafür stehen inzwischen generische Lösungen zur Verfügung. Das heißt, es ist nicht mehr notwendig, Integrationsfunktionen individuell zu programmieren. EAI-Tools liefern diese Funktionalität als Kauflösung (Informationen zu den Anbietern gibt es im EAI-Forum des CW Infonet unter www.computerwoche.de).

Durch den Einsatz dieser Technologien wird erreicht, dass auch die Integration schnell und wirtschaftlich realisierbar ist. Der Aufwand besteht in der Definition, welche Geschäftsprozesse im ERP-System aufgerufen und welche Daten zum Aufrufzeitpunkt am API übergeben werden. Der Informationsaustausch erfolgt auf Basis der Extensible Markup Language (XML). Da im ASP-Fall - anders als etwa bei Marktplatz-Lösungen - alle Beteiligten untereinander von Anfang an bekannt sind, lässt sich die Semantik der XML-Dokumente (Definition der Inhalte von Rechnungen, Lieferscheinen etc.) leicht regeln.

Weitere Definitionen umfassen die so genannten Business Objects wie Kunde, Auftrag oder Rechnung. Damit wird festgelegt, bei welchem Geschäftsprozess welche Business Objects zwischen Frontend und ERP-Anwendung ausgetauscht werden müssen und welches Aussehen, bezogen auf die Datenstrukturen, diese Business Objects haben.

Eine weitere Funktion ist die Definition des Security-Levels und der dazugehörenden Funktionalität sowie die Organisation des physischen Datentransports vom Frontend zur EAI-Komponente und weiter zum ERP-System beziehungsweise zurück. Für die Umsetzung dieser Middleware gibt es eine Reihe von technischen Möglichkeiten, vom Remote Procedure Call (RPC) bis zum Messaging-System.

Komponente 3: Internet-FrontendEine Umstellung der vorhandenen ERP-Masken zu Internet-Masken ist ohne generisches Internet-Frontend-System aus wirtschaftlicher Sicht nicht sinnvoll. Der Grund liegt in der Tatsache, dass es kaum machbar ist, Hunderte von vorhandenen Masken per Hand umzustellen, damit sie den Internet-Anforderungen genügen, und den erforderlichen Code maskenspezifisch zu programmieren. Die einzige akzeptable Antwort ist der Einsatz einer generischen Komponente, bei der einige generelle Grundmuster für die Internet-Masken bereitgestellt werden.

Diese Masken-Schablonen werden zum Ablaufzeitpunkt auf Basis der in einem Repository abgelegten Definitionen sowie der Daten, die am API bereitgestellt werden, dynamisch mit Inhalt gefüllt. Dies ist ein generischer Prozess, der einmal zu programmieren ist und dann wirtschaftlich für Hunderte von Masken immer wieder genutzt werden kann.

*Richard Nußdorfer ist Geschäftsführer der CSA Consulting GmbH, Dimitrios Kouros ist Leiter neue Technologien bei der Soft M AG, beide in München.

AlternativeEine zum Internet- und Browser-Konzept alternative Architektur für den ASP-Betrieb stellt der Windows Terminal Server (WTS) da. Ein Vorteil dieser Variante besteht darin, dass bestehende Client-Server-Architekturen, sofern sie WTS-fähig sind, unverändert in den ASP-Betrieb gehen können. Die Benutzer arbeiten - wie im lokalen Netzwerk - remote über das Web mit den gewohnten Windows-Clients. Die PC-Server mit der Frontend-Software stehen beim ASP-Anbieter. Allerdings muss in diesem Fall - anders als bei der Internet-Architektur, die auf der User-Seite nur einen Web-Browser erfordert - auf den Benutzer-PCs die Client-Komponente des WTS installiert werden. Ein weiterer grundsätzlicher Vorteil der Internet-basierenden Architektur gegenüber dem WTS-Konzept besteht darin, dass sich nicht nur die Anforderungen des ASP-Betriebs erfüllen lassen, sondern die sämtlicher Internet-basierenden Anwendungen wie Marktplätze, Web-Shops oder Supply Chains.

Abb: Mit EAI-Komponenten und einem Repository-gesteuerten Frontend lassen sich komplette ERP-Systeme auch für den ASP-Betrieb im Web zur Verfügung stellen. Quelle: Soft M