Wir alle tragen eine Vorstellung davon im Herzen, wie die ideale Architektur einer ISIS-Installation aussehen sollte – sei es mit oder ohne Papyrus Objects.

Die Systemdiagramme der realen Welt weichen von diesen Vorstellungen mitunter erheblich ab.

Zum einen wurde oft eine neue Technologie eingeführt, ohne die alte komplett abzulösen – das System verbleibt in einem permanenten „Interimszustand“, weil der Aufwand für eine vollständige Umstellung als zu ressourcen- und zeitintensiv empfunden wird. Zum anderen kann ein sukzessiver Übergang zu einer neuen Technologie – auch wenn er abgeschlossen wird – dazu führen, dass im Transformationsprozess Kompromisse gemacht werden müssen, um den Betrieb aufrecht zu erhalten. Die Konsequenzen dieser Kompromisse trägt das neue System auch nach Abschaltung des alten in sich. Und dann gibt es da auch noch den dritten möglichen Grund: Durch Eigenentwicklungen sollen Lizenzen gespart werden. Die Eigenentwicklungen übernehmen Aufgaben, die im „idealen“ System beispielsweise durch Papyrus Objects abgedeckt worden wären. Und natürlich gibt es viele Konstellationen, in denen zwei oder alle drei dieser Gründe eine Rolle spielen. So ist in der „realen Welt“ jedes System ein individuelles – mal mehr, mal weniger.

Ist das ein Problem? Ich meine: nicht zwangsläufig.

Einer der Vorteile von ISIS Papyrus ist seine Modularität und die damit verbundene Flexibilität. Es ist möglich, nur die Module zu verwenden, die man benötigt, es ist möglich, die ISIS-Produkte mit Eigenentwicklungen zu koppeln und es ist möglich, vorhandene Lösungen in eine neue zu integrieren. Das ist etwas Gutes. Mit und durch ISIS Papyrus kann ein modernes Outputmanagement in eine vorhandene Systemlandschaft integriert werden: was Sie nicht brauchen, lassen Sie weg – mit der Option, das System später zu erweitern. Klar ist aber auch: Die Verwundbarkeit eines Systems (oder eines Menschen, was das angeht) ist oft eben die Eigenschaft, die auch seine Stärke ausmacht. Der Preis der Flexibilität kann Komplexität sein. Hier kommt es auf eine exakte Voranalyse und eine genaue Abstimmung mit der Firma ISIS an. Die Methode „Wir fangen mal an und dann sehen wir schon“, ist bei einem System, das von sich aus wenig Grenzen setzt, noch gefährlicher, als sie es ohnehin schon ist. Wird das aber beherzigt, hat man mit ISIS Papyrus ein mächtiges Werkzeug an der Hand und die Welt ist um eine interessante Systemkonstellation reicher.

Im Folgenden sehen Sie Beispiele individueller Systeme, die Sie so in der Beschreibung des „idealen“ Systems eher nicht finden werden. Vielleicht ähnelt eine davon Ihrem eigenen?

Papyrus Objects (XOM-Adapter und File-Adapter)

Papyrus Objects (REST Adapter und Interface Layer)

Stand-Alone DocEXEC, Java Service und Perl

Stand-Alone DocExec und Papyrus Objects

Stand-Alone DocEXEC, UC4 und Perl

Sah eines dieser Bilder vertraut aus? Oder geht Ihr System noch einen anderen ganz eigenen Weg? Eins ist klar: viele Wege führen nach Rom!

Kennen Sie bereits Consulting-as-a-Service?


Wir freuen uns darauf, Sie kennenzulernen. Hinterlassen Sie uns kurz
Ihre Kontaktdaten, damit wir Sie gleich anrufen können.

    Ja, ich stimme der Speicherung meiner Daten zur weiteren Verarbeitung gemäß der Datenschutzerklärung zu und bestätige, diese gelesen und verstanden zu haben.

    Autor: Irmela Heinscher
    Tel.: +49 5605 93349‐12
    Mail: irmela.heinscher@pohlgmbh.de