Vorurteile sind unverzichtbar. Schließlich können wir nicht ständig alles von allen Seiten betrachten. Manchmal genügen Bauchgefühle, erste Eindrücke und das, was die anderen sagen.
Doch je folgenreicher die Entscheidung, desto lohnender ist es, die Türen im Kopf wieder zu öffnen. IT-Entscheidungen haben immer große Konsequenzen.
Hier finden Sie zum Thema EGL neue Sichtweisen und Impulse für kritische Gespräche.
Ich wünsche Ihnen die beste Entscheidung.

Vorurteil 1: EGL bietet keinen Investitionsschutz

Das stimmt – wenn man Software an der Ewigkeit misst. Wem es aber um die absehbare Zukunft geht: IBM hat EGL vor allem deshalb entwickelt, um bestehende Investitionen noch lange nutzen zu können. Wenn das Alte noch taugt, neue Ufer aber nicht mehr erreichbar sind, dann kann eine gute Brücke beides verbinden und Neues schaffen. EGL ist diese Brücke.
Wer sie nutzt, schont seine Ressourcen, denn:
Ihre bestehenden Assets lassen sich integrieren.

Ihre RPG- und COBOL-Entwickler lernen leicht und schnell, mit EGL umzugehen.
Ihrer Entwicklungsmannschaft erschließen sich neue Möglichkeiten, aber deren Knowhow über Business-Prozesse schafft weiterhin Wert.
Kennen Sie einen besseren Weg, um bestehende IT-Investitionen zukunftstauglich zu machen?

Vorurteil 2: EGL ist proprietär

Was sind die obersten Prioritäten bei Business-Anwendungen? Wir denken, es sind:
•Stabilität
•Sicherheit
•und eine einfache, effektive Handhabung.

Stößt hier der reine Open-Source-Ansatz nicht an seine Grenzen? Braucht es hier nicht jemand, der verlässlich filtert, wartet, vereinfacht? Java ist nur auf den ersten Blick nicht-proprietär. Man ist abhängig von diversen Open-Source-Frameworks, die sich ständig verändern und teilweise nicht zueinander passen. Mit den Problemen, die daraus entstehen, steht man dann alleine da. Was also ist besser: Lauter volatile Abhängigkeiten oder eine Bindung an IBM, die die Verantwortung übernimmt?

Vorurteil 3: EGL hat keine Entwickler

EGL ist so einfach, dass jeder schnell ein Entwickler wird. RPG und COBOL Entwickler brauchen gerade mal vier Wochen Schulung, um EGL zu beherrschen. Ähnlich ergeht es allen anderen Business-Entwicklern, seien es Fans von Natural, CSP, VAGen oder ähnlichen Anwendungen.
Java-Entwickler haben sowieso kaum Probleme mit der Umstellung, denn die EGL-Syntax lehnt sich an die Java-Syntax an. Zugegeben: Java-Puristen mögen beim Gedanken an EGL erschaudern. Aber wer tagtäglich fachliche Probleme lösen will und nicht Java-Probleme, der wird EGL als Hilfe zu schätzen lernen.
Außerdem bringt EGL zwei Entwicklergenerationen zusammen: Es wirkt wie ein Dolmetscher zwischen den traditionellen Gemeinde und der jüngeren Java-Gemeinde. Das erleichtert nicht nur den Generationenwechsel im Unternehmen – es macht ihn produktiv.

Fazit

Mittlerweile haben so viele Unternehmen die Modernisierung auf Basis von EGL gewagt. Denn sanfter als mit EGL geht’s nicht: Für jede Betriebsanforderung finden sich die passenden kleinen Schritte – ob vertikal in Form von Geschäftskomponenten oder horizontal in Form von technischen Schichten. So ermöglicht die horizontale Migration bereits zu Anfang eine einheitliche, moderne Benutzeroberfläche – und er-füllt so den Hauptwunsch vieler Kunden innerhalb kürzester Zeit. EGL ist ein Meister der Integration. So bleibt alles sicher erhalten. Parallelbetrieb ist möglich. Das Neue kommt schrittweise und erst dann, wenn es die Anforderungen perfekt erfüllt.