1. Modernisierung: Vom OpenText WebTop zu D2
2. Entwicklung eines eigenen Administrationsclients
3. Ausphasung des OpenText WebTops
4. Schnittstelle zu anderen Systemen
5. Change Management / Kommunikation (demnächst verfügbar)

Hintergrundfakten

• Mehr als 100.000 Anwender
• Mehr als 70 Millionen Dokumente
• Einsatz in zahlreichen Ländern und Gesellschaften

• Eine moderne und schicke Oberfläche – bestehend aus unterschiedlichsten Widgets
• Alle nötigen Funktionen für Normal- und Power-User stehen zur Verfügung
• Schnelle Dokumentanzeige zahlreicher Formate
• Individualisierbare Oberfläche
  • Anwender kann zwischen verschiedenen Oberflächen (Arbeitsbereichen) wechseln, je nach Arbeitsweise- und Schwerpunkt
  • Anwender kann einzelne Oberfläche nach seinen Wünschen und Bedürfnissen durch Auswahl relevanter Widgets anpassen

 Weitere Informationen finden Sie hier: OpenText Documentum D2

Teil 2: Entwicklung eines eigenen Administrationsclients

Wieso ein eigener Client für die Administration?

Wesentliche Gründe waren die bereits erwähnte veraltete Technologie des OpenText Documentum Webtops sowie die fehlende Möglichkeit, die benötigten Funktionen mit der neuen Standardlösung abzubilden. Darüber hinaus waren beim Webtop sowohl die Anwender- als auch die Administratorenfunktionalitäten in einem Client abgebildet. Dies führte zu einer hohen Komplexität des Releasemanagements sowie zu Einbußen bei der Performance und der User Experience. Insbesondere für die administrativen Power User stellte dies ein enormes Problem dar und sorgte für Frustration. Daher meldeten sie den Bedarf an, ihre Use Cases von denen des „normalen“ Anwenders zu separieren, um zum einen die Performance wieder zu verbessern als auch schnellere Anpassungen zu ermöglichen. Auch konzernseitig gab es Spezialanforderungen, z.B. im Bereich Compliance, die nicht als Standard angeboten wurden.

Custom Software Solution – Berücksichtigung individueller Bedarfe und Entwicklung mit Spaß

Aufgrund der speziellen Anforderungen war schnell klar, dass eine komplett eigene Entwicklung erforderlich war, um eine funktionale und anwenderfreundliche Ergänzung für den Anwenderclient umzusetzen.

Um möglichst effektiv voranzukommen und den agilen Spirit der direkten Zusammenarbeit zu nutzen, mietete sich ein Entwicklerteam eine Woche in einem Ferienhaus in Dänemark ein. Schon bald darauf konnte eine erste Version beim Kunden ausgerollt werden. Es folgte eine große Erweiterung, mit der schließlich alle relevanten Funktionen der alten Oberfläche abgedeckt wurden.

Kurz: Das Ergebnis war eine moderne und ansprechende Webapplikation basierend auf State-of-the-Art Frameworks.

Weitere Informationen finden Sie hier: Custom Software Entwicklung

Alles ist möglich

Durch Änderungen in den Vorgaben bzw. Erweiterungswünsche von Kunden- sowie Anwenderseite kommen regelmäßig neue Anforderungen auf den Administratorclient zu. Und genau hier liegt die Stärke von Custom Software Solutions: Die hohe Flexibilität ermöglicht eine schnelle und maßgeschneiderte Anpassung bei der Umsetzung der Anforderungen.  Zusätzlich sorgt die kontinuierliche Verbesserung der Anwendung durch funktionale Erweiterungen und Performanceoptimierungen dafür, dass die Arbeit der Power User und auch neuer Administratoren erleichtert wird.

Mit dem Go-Live des Administrationsclients und der Verfügbarkeit aller notwendigen Funktionen für die Administratoren, waren nun alle Voraussetzungen erfüllt, den alten Webtop auszuphasen. Was dabei beachtet werden musste? Hierauf wollen wir im nächsten Teil unserer Serie einen kurzen Blick werfen.

Teil 3: Alte Zöpfe abschneiden – Ausphasung des OpenText Webtop

Nachdem mit der D2-Oberfläche (für die Anwender) sowie dem individuell entwickelten Administrationsclient alle notwendigen Funktionen für die Nutzung und Administration bereitstanden, war es an der Zeit, die alte Webtop-Oberfläche vollständig abzulösen und letztendlich abzuschalten. Dabei gibt es neben der reinen Modernisierung noch weitere Vorteile, die nicht unerheblich sind und die besonders auf technischer Ebene relevant sind:

• Kosteneinsparungen durch Reduzierung bzw. langfristig Wegfall von Wartungsaufwand
• Einsparungen durch freiwerdende Ressourcen wie CPU, Hauptspeicher und Tomcats

Für den Anwender steht natürlich insbesondere das Handling im Vordergrund. Hierbei war es einerseits wichtig, die technische Umstellung ohne Instabilitäten und Performanceeinbußen auf Serverseite sicherzustellen, als auch den Übergang für die Anwender grundsätzlich so unkompliziert wie möglich zu gestalten, um gleich zu Beginn Akzeptanz für die neuen Oberflächen zu schaffen.

Welche Schritte aus unserer Sicht zu einem erfolgreichen Übergang (Ausphasen des Webtop) beigetragen haben, möchten wir im Folgenden übersichtsartig skizzieren.

Parallelität und stufenweises Vorgehen

Wichtig war es uns, eine stufenweise Ausphasung vorzunehmen. Dies bot die Möglichkeit, jederzeit zu reagieren und falls notwendig Korrekturen bei dem Vorgehen vorzunehmen.

Was haben wir nun aber konkret getan?

• Die Anwendungen wurden parallel installiert. Die Anwender konnten sich so bereits langsam mit den neuen Oberflächen vertraut machen und diese nutzen.
• Schulungsmöglichkeiten zur Unterstützung der Anwender wurden bereits zu diesem Zeitpunkt angeboten sowie diverse Hilfedokumente und Informationen im Wiki zur Verfügung gestellt.
• Die Anzahl der Webtop-Anwender wurde kontinuierlich gesenkt, die der D2-Anwender kontinuierlich gesteigert. Dies erfolgte in einer festen Anzahl von Schritten, bei denen ganze Abteilungen zusammen vom Webtop ausgeschlossen und den D2-Anwendern hinzugefügt wurden. Um Anwender vom Webtop auszuschließen, wurden sie aus einer Gruppe entfernt. Nur Mitglieder dieser Gruppe durften den Webtop benutzen. Sofern es Mitarbeiter gab, die noch länger Zugriff auf den Webtop benötigten, blieben diese so lange wie notwendig in der Gruppe.
• Transparenter Ausphasungsplan im Wiki, so dass sich die Anwender bereits frühzeitig darauf einstellen konnten, ab wann sie nicht mehr mit dem Webtop arbeiten können. Zusätzlich wurden die Anwender vorab per E-Mail informiert.
• Bei jedem Schritt wurde die Auslastung der Server geprüft. Auf Applikationsserver-Seite (Tomcat auf Linux) und auf Documentumserver-Seite (Linux).
• Linkhandler-Entwicklung um alte Links, die auf den Webtop zeigten und in bestehenden Excel-Dateien etc. existierten, funktionsfähig zu halten (Umleitung der alten Links auf den D2-Client).
• Am Ende des Prozesses waren alle Mitarbeiter aus der oben genannten Gruppe entfernt.

Das Ergebnis: Alle Anwender nutzen nun die D2-Oberfläche, alle Administratoren den Custom-Administrationsclient. Der Webtop wurde daraufhin abgeschaltet. Dessen Ressourcen (CPU, Hauptspeicher, Tomcat) wurden wieder freigesetzt.

Screenshots Oberfläche OpenText Documentum D2

Goodbye Webtop und Zukunftsmusik

Die Ausphasung des Webtop verlief ohne größere Herausforderungen – niemand wurde überrascht und alle Anwender konnten in einem gewissen Rahmen selbst die Geschwindigkeit des Umstiegs bestimmen. OpenText D2 und der Custom-Administrationsclient sind nun die alleinigen Frontends für die Documentum-Anwender – der Webtop ist Geschichte. Einige trauern ihm nach, der Großteil jedoch nicht. Und auch wenn nun eine zeitgemäße und vom Hersteller dauerhaft supportete Plattform zur Verfügung steht – die Zeit dreht sich bereits weiter und weitere Modernisierungsmaßnahmen werden unter die Lupe genommen. OpenText bietet D2 beispielsweise mittlerweile auch in einer neuen kachel-orientierten Version – dem D2-Smartview – an. Eine solche Oberfläche ist beispielsweise attraktiv für Anwender, die ein dieses Handling vom Tablet her kennen und sich dies auch in anderen Systemen wünschen. Was ist unser Fazit? Nach dem Wandel bleibt vor dem Wandel.
Weitere Informationen zu unserem OpenText Documentum Portfolio

Ausblick

Neben der regelmäßigen Aktualisierung der Frontend Technologie (Angular), die die Release- und Anpassungsfähigkeit fortwährend gewährleistet, werden in naher Zukunft insbesondere die Themen Continuous Integration und auch Continuous Delivery eine hervorgehobene Rolle spielen. Diese Themen werden zu einem späteren Zeitpunkt und in einem gesonderten Blogpost – außerhalb dieser Serie – näher vorstellen.

Teil 4: Integration zur effizienten Nutzung und Automatisierung: Schnittstellen zu anderen Systemen

Wenn wir über die Welt des Dokumentenmanagements sprechen, ist es wichtig, nicht nur die grundlegenden Funktionen zu betrachten, sondern auch die vielfältigen Anwendungsfälle, die darüber hinausgehen. Mit der Einführung von OpenText D2 und dem Custom-Administrationsclient haben Anwender und Administratoren Zugang zu den regulären Funktionen, die das Dokumentenmanagement bietet. Doch um Geschäftsprozesse nahtlos zu gestalten oder sogar zu vereinfachen, müssen wir auch über die Integration anderer Systeme und die Automatisierung von Prozessen nachdenken. Dies erfordert den Aufbau und die Integration von gut gestalteten Schnittstellen (APIs = application programming interface) zwischen den verschiedenen Komponenten, insbesondere bei stark angepassten Systemen, wie sie oft im Bereich des Dokumentenmanagements anzutreffen sind. In diesem Artikel werden wir uns genauer damit befassen, wie diese Schnittstellen zentral dazu beitragen, die Effizienz und Funktionalität von Dokumentenmanagementlösungen zu optimieren.

Entlastung durch Integration in die Systemlandschaft

Vor diesem Hintergrund wurden für ein Projekt im OpenText Documentum-Kontext die folgenden zwei Schnittstellen entwickelt, die auf anerkannten Standards basieren. Diese wurden erfolgreich beim Kunden integriert, wo sie seit Jahren stabilisiert und unterstützt werden. Ihr Zweck ist es, Anwender zu entlasten und die Geschäftsprozesse zu beschleunigen.

1. Anbindung von Individualsoftware: SOAP-Schnittstelle zum OpenText Documentum Content Server

Die Anbindung von Individualsoftware an das Dokumentenmanagementsystem ist eine häufige Anforderung. Der Vorteil für den Kunden liegt darin, dass ihre Partner ihre eigene Software nutzen können, um gleichzeitig mit dem OpenText D2 Client auf den Content Server zuzugreifen. So bieten sie ihren Nutzern reibungslose Abläufe. Eine Schnittstelle zum OpenText Documentum Content Server wurde über SOAP (Simple Object Access Protocol) umgesetzt, das den Austausch von XML-strukturierten Nachrichten ermöglicht. Dabei sind wichtige Sicherheitsmechanismen auf Transport-Ebene und Autorisierungsfunktionen auf Nachrichten-Ebene erforderlich, um die Geschäftslogik sicher zu übertragen. Obwohl für jede einzelne Individualsoftware ein einmaliger Setup-Aufwand erforderlich ist, ist der laufende Betrieb normalerweise weniger aufwendig und betrifft oft nur das LifeCycle Management. Wir haben auch darauf geachtet, die Modernisierung von Anfang an zu berücksichtigen, indem wir den Service in zwei Schichten aufgebaut haben: die Geschäftslogik und die SOAP-Protokollschicht. Dadurch lässt sich bei Bedarf problemlos eine moderne REST (Representational State Transfer)-Schnittstelle implementieren, was bereits diskutiert wird.

 2. Automatisierung von Prozessen: REST-Schnittstelle für ServiceNow

Eine weitere Anforderung des Kunden bestand darin, den Prozess der Erstellung, Änderung und Löschung von Documentum-Ablagen zu automatisieren. Dafür wurde eine REST-API entwickelt. Dank der hohen Flexibilität von maßgeschneiderten Softwarelösungen, ließ sich diese leicht in den Administrationsclient integrieren.

Dadurch hat die ServiceNow Instanz beim Kunden jetzt die Möglichkeit, Änderungswünsche für Documentum-Ablagen nicht mehr umständlich per E-Mail an den Betrieb zu senden, sondern direkt über REST-Aufrufe an die entsprechende API des Administrationsclients zu übermitteln.
Dem ServiceNow Team wurde eine automatisch generierte API-Dokumentation bereitgestellt, um die Integration effektiv zu gestalten. Die Schnittstelle entlastet den AMS (Application Middleware Support) des Kunden von wiederkehrenden Standardaufgaben und erfüllt dadurch die Kundenzufriedenheit.

Ein weiterer Vorteil ist, dass der Administrationsclient, ähnlich wie die zuvor beschriebene SOAP-Schnittstelle zum OpenText Documentum Content Server, aus mehreren Schichten besteht, die bereits per REST-Calls miteinander verbunden sind. Dadurch konnte die ServiceNow API problemlos integriert werden und liegt nun parallel zum Angular-Frontend auf einer Ebene, so dass keine redundanten und aufwändigen Neuentwicklungen in der Geschäftslogik erforderlich sind.

Fazit: Schnittstellen sorgen für optimierte Abläufe, mehr Effizienz und Reduzierung von Fehlerquellen

Insgesamt verdeutlichen diese Beispiele die vielfältigen Möglichkeiten der Integration und Automatisierung von Prozessen im Bereich eines Dokumentenmanagement-Systems. Die Implementierung von maßgeschneiderten Schnittstellen wie SOAP und REST-APIs optimiert nicht nur die Abläufe, sondern steigert auch die Effizienz und reduziert potenzielle Fehlerquellen. Die enge Zusammenarbeit zwischen den verschiedenen Systemen und die Bereitstellung automatisch generierter API-Dokumentationen tragen dazu bei, den Betrieb reibungsloser und kundenorientierter zu gestalten. Diese fortschrittlichen Ansätze zeigen, wie Unternehmen durch innovative Technologien ihre Geschäftsprozesse modernisieren und anpassungsfähiger werden können, um den sich ständig wandelnden Anforderungen gerecht zu werden.