Dabei wurde die Applikationsfunktionalität in Form loser Dienste für einen geschäftsprozessbezogenen Ansatz konzipiert. Diese lassen sich über XML, SOAP, Web-Services oder höhere Schnittstellenspezifikationen wie JSR 170 in eine bestehende Prozesskette einbinden. Vorteilhaft ist insbesondere, dass - anders als bei den früheren Punkt-zu-Punkt-Verbindungen und bei der Nutzung klassischer Programmierwerkzeuge - kein Expertenwissen über realisierte Schnittstellen erforderlich ist.
Mit der erweiterten SOA-Funktionalität soll die Modellierbarkeit der Geschäftsprozesse stark vereinfacht werden. Geschäftskritische Daten lassen sich somit bezogen auf den Geschäftsprozess in einem zentralen Repository verwalten, Wildwuchs wird unterbunden.
Die neue Strategie forciert die Konsolidierung von Insel-Applikationen und gibt dem mehr und mehr prozessbezogenen Denkansatz Nahrung. Erhofft man sich doch, mit Hilfe von SOA die Informationstechnologie einfacher und besser in bestehende Geschäftsprozesse einbinden zu können. Bisherige Realisierungskonzepte beinhalteten zwar die Fachlogik im Einzelnen, ließen sich jedoch nur schwierig in Prozessabläufe im Ganzen integrieren. Komplexe Schnittstellen, schlecht zu wartende und wenig flexible Einzellösungen waren die Folge. Außerdem hohe Projektkosten und unzufriedene Fachbereiche.
Integration von Repository und Applikations-Server-Diensten
Einen leistungsfähigen SOA-Ansatz erhält man nicht per se. Dieser ist vielmehr Bestandteil des Architekturmodells der jeweiligen Applikation. Daher können bestehende Applikationen einer ernsthaften SOA-Strategie kaum gerecht werden. So kaschieren Zusatzentwicklungen wie Applikationslayer oder Schnittstellen nur das Problem: Mangelnder Datendurchsatz, geringe Performance und umständliche Lösungskonzepte, die nicht selten sogar schlechter als die bisherigen Punkt-zu-Punkt-Applikationsverbindungen funktionieren, sind die Folge.
Aus diesem Grunde wurde schon in der Planungsphase ein Architekturkonzept zu Grunde gelegt, das die optimale Integration des Repositories, dem Archiv- und Content-Bereich, mit den Applikations-Server-Diensten gewährleistet. Dabei bilden die Applikations-Server-Dienste das Herzstück einer leistungsfähigen SOA-Strategie. Sie umfassen zum einen die Applikationslogik wie z. B. Strukturinformationen, Prozesszugehörigkeiten oder Verarbeitungsregeln. Zum anderen stellen sie dem Prozessablauf aber auch Geschäftsinformationen aus dem zentralen Repository, bestehende Fachapplikationen oder selbst programmierte Lösungsbausteine bereit.
Gefährlich bei standardisierten Lösungsansätzen und damit auch bei SOA ist, dass diese Lösungsansätze für die Praxis zu träge und zu wenig performant sind. Dieses Risiko umgeht ELO mit Hilfe von leistungsfähigen Befehlsstrukturen. In der Praxis hat sich die Einbindung der Dienste über das SOAP-Protokoll mehr als ausreichend performant gezeigt, so der Hersteller.
Gerade für die interaktiven Benutzeroperationen, die ein schnelles Antwortzeitverhalten voraussetzen, hat es sich bei der Nutzung der Applikationsdienste als Protokoll der Wahl durchgesetzt. Die Anzahl der Applikationsdienste wurde nochmals um ein Vielfaches erweitert. Insbesondere für die Verzahnung bestehender Applikationen hat sich die XML- und Web-Service-Technologie bewährt. Sie verbindet ELOenterprise auf einfache Weise mit bestehenden Fachapplikationen, um so einen durchgängigen Ablauf der Unternehmensprozesse sicherzustellen. Der große Vorteil liegt aber nicht nur in der raschen und stabilen Implementierung, sondern auch in der Wartungsfähigkeit bei sich ändernden Geschäftsanforderungen, ist man bei ELO Digital Office überzeugt,




7/2011
6/2011
5/2011


Dr. Eric Scherer ist Geschäftsführer des anbieterunabhängigen Beratungs- und Marktforschungsunternehmens i2s. Er gilt als einer der führenden ERP-Experten und ist Initiator der ERP-Zufriedenheitsstudie. 