Bestehende Software modernisieren / Umstieg

[361]

Hallo liebe Forumsmitglieder.

Ich arbeite in einer Firma, welche ein ERP-System mit Delphi entwickelt hat. Das Ganze ist sehr umfangreich, 13 Jahre alt und basiert auf PostgreSQL, sowie Delphi 10.2. Es kommen mittlerweile immer häufiger Anforderungen von Kunden, die Software im Web/in der Cloud nutzen zu können. Nun gibt es noch weitere interne Anforderungen, die sich über die Jahre entwickelt haben und ebenfalls für eine Web-Anwendung sprechen. Also wurde nun entschieden, für dieses Jahr einen kompletten Neuanfang zu machen. Von Seiten des Managements, sollte mit einem Umstieg die Produktivität deutlich steigen und stärker der Inhalt des Produkts im Vordergrund stehen. Ich hatte mich deshalb mal mit Low-Code-Plattformen beschäftigt: u.a. Mendix, OutSystems und diese vorgeschalgen. Nun hat sich jedoch herausgestellt, dass die Kosten hierfür deutlich zu hoch lägen. Es ist nicht vergleichbar mit einer Delphi-Subscription. Auch scheint die Abhängigkeit an den Hersteller deutlich stärker zu sein.

Könnt Ihr mir vielleicht Empfehlungen oder Anregungen geben, womit man sich mal beschäftigen sollte? Gibt es vielleicht ebenbürtige Open Source Low-Code-Plattformen? Welchen Weg würdet Ihr einschlagen, wenn das Know-How der letzten 15 Jahre Delphi ist (einige Entwickler beherrschen auch .NET und JAVA aber kein Web) und nun eine Web-Anwendung von Grund auf neu geschrieben werden soll mit Fokus auf Produktivität? Der Neuanfang ist mit Sicherheit notwendig, da auch Architekturgrenzen erreicht wurden. Was sind Eure Erfahrungen und Tipps?

[Rollo62]

Zitat von 361:

Nun hat sich jedoch herausgestellt, dass die Kosten hierfür deutlich zu hoch lägen. Es ist nicht vergleichbar mit einer Delphi-Subscription

Hört, hört

ich verstehe nicht ganz wie Du 15 Jahre Codebase mit LowCode zusammenbringen willst.
Ich denke (ok, schlagt mich), das VCL/FMX eigentlich ideal sein sollte,
mann kan alte Teile VCL mit neuen Teilen FMX gut koppeln.
Dann kannst Du deinen existierenden VCL Business Code weiternutzen, oder zumindest einfach prtieren.

Wenn es mehr in Richtung Web gehen sollte, dann kämme wohl auch TMS WebCore in Frage.

Ich würde jedenfalls nicht 15 Jahre einfach über Bord werfen, es sei denn das Ihr vollkommen unzufrieden damit seid.

[Der schöne Günther]

Als erstes würde ich klären wo die Manpower herkommen soll das bestehende Produkt weiterhin zu supporten, Bugs zu beheben und kurzfristigen Kundenanforderungen zu entsprechen (wie heute auch) und parallel dazu jetzt noch ein völlig neues Produkt von Null an hochzuziehen.

Wenn auch in einem etwas anderen Kontext, aber Uwe Raabe kann ich da nur zustimmen:

Zitat:

Experience shows that this usually never happens - and if, it will not happen in the expected time frame, cost and functionality. The first barrier is usually the lack of documentation what the Delphi software does, how it does it and why it does it that way.

I personally have seen a couple of such endeavors going down the drain. They could as well have burned the money in the first place.

(Quelle)

Hatten wir hier genauso. Man war der Meinung mit einem sauberen Cut noch einmal von vorne anfangen würden sich viele Anforderungen viel besser oder überhaupt erst umsetzen lassen. In der Theorie richtig, aber gescheitert sind wir vor allem auch wirklich an der fehlenden Dokumentation was die Software eigentlich kann, und warum man manche Dinge so und nicht so lösen muss. In den ersten Monaten hätten viele Dinge gefehlt die Kunden über die Jahre ans Herz gewachsen waren, aber man im ersten Wurf für nicht notwendig erachtet hatte. Im Endeffekt war es gut dass wir lieber die Arschbacken zusammengekniffen haben und das Produkt durch und durch aufgearbeitet haben.

Und: So billig es klingt, aber lass dich doch auch mal direkt von Embarcadero beraten. Was man da mit DataSnap und EMS alles machen kann können die einem sicher am besten erklären.

[jsheyer]

Gerade was die Web Entwicklung betrifft und Multiplattform hat sich sehr viel getan in den letzten Jahren.
Bzgl. Web Oberfläche werfe ich da gerne mal UniGui in den Raum, wie ich finde ein sehr gutes Framework und die Entwicklung findet wie gewohnt in Delphi statt

[361]

Hallo Rollo62,

vielen Dank für Deinen Beitrag. Das finanzielle mit den LowCode-Herstellern wird aktuell geklärt, aber die initialen Aussagen waren preislich wohl eher etwas für große Firmen.

Also ich habe mir bereits mal angeschaut, wie schnell man mit Low-Code entwickeln kann und das beeindruckt, wenngleich man auch im Hinterkopf hat, dass es auch genug Probleme oder Schwachstellen geben wird. 13 Jahre Entwicklungszeit sind mit Delphi dahingehend recht viel, wenn man jedoch produktiver entwickeln kann (generiert Code etc), dann kann man es mit Sicherheit nicht vergleichen.

Mit FMX habe ich mich noch nicht beschäftigt. Primär soll eine Web-Anwendung entstehen, wenn das mit FMX geht und man Code behalten kann, wäre das gut. Wir haben allerdings auch Schwachstellen in der Architektur, weshalb ein Neuanfang Vorteile bieten würde.

Hast Du Erfahrung mit TMS WebCode? Ich werde mich gleich hierzu belesen.

Das mit den über Bord werfen ist richtig, allerdings gab es schon zwei Re-Designs. Abgesehen von der Kundenanforderung, es soll Web-tauglich sein, stört mich der Verwaltungsaufwand und auch einige Schwächen wie UI-State-Handling (viel Code) oder das Erstellen neuer Forms/Frames, das geht mit Low-Code weit besser. Laut Kunden und Sales muss die Anwendung vom Desktop weg.

[Uwe Raabe]

Zitat von 361:

Hast Du Erfahrung mit TMS WebCode? Ich werde mich gleich hierzu belesen.

Da ist wohl gerade was ausführlicheres in der Pipeline...

[Bernhard Geyer]

Ich würde erstmal Grundsätzliche Entscheidungen klären:

- Welche Frontend-Bibliothek soll es sein? Es mit "Dephi-Background" oder lieber doch gleich 100% Cut und auf Bibliotheken wie Angular oder React setzen?

- Welche Backend soll es werden? Weiter mit Delphi und "nur" eine passende API gegen die Front-End-Bibliothek?
Oder gleich alles "wegschmeißen" und auch am Server sowas wie Node.js einsetzen?

Ein wichtiger Punkt wenn man jetzt auf Web umbaut ist das dies gleich auf allen Geräten nutzbar ist.

Und nicht sagen das ein ERP nur am PC benutzt wird. Teilinformationen will man auch gerne unterwegs am Smartphone haben.

[361]

Zitat von Bernhard Geyer:

Ich würde erstmal Grundsätzliche Entscheidungen klären:

- Welche Frontend-Bibliothek soll es sein? Es mit "Dephi-Background" oder lieber doch gleich 100% Cut und auf Bibliotheken wie Angular oder React setzen?

- Welche Backend soll es werden? Weiter mit Delphi und "nur" eine passende API gegen die Front-End-Bibliothek?
Oder gleich alles "wegschmeißen" und auch am Server sowas wie Node.js einsetzen?

Ein wichtiger Punkt wenn man jetzt auf Web umbaut ist das dies gleich auf allen Geräten nutzbar ist.

Und nicht sagen das ein ERP nur am PC benutzt wird. Teilinformationen will man auch gerne unterwegs am Smartphone haben.

Hallo Bernhard,

vielen Dank für die Gliederung und Erklärung. Ich denke, es wäre besser einen kompletten Neuanfang zu machen, da es auch intern technische Anforderungen gibt, neue Technologien zu nutzen (z.B. Hibernate). Die Anforderung Web-Frontend vom Kunden ist essentiell. Ich sehe es auch, dass die Nutzung am Smartphone gewünscht ist (gab es Anfragen) doch womit könnte man das technisch realisieren? Stichwort wäre hier Layout-Manager. Wofür wäre node.js nutzbar, kannst Du dazu noch etwas schreiben? Für Input bin ich dankbar auch besten Dank an die Vorposter, belese mich hierzu auch gerade.

[Neumann]

Ich würde mir mal TMS-Webcore sowie die TMS-Business Tools ansehen. Damit kann man viel machen und den Delphi-Quellcode zum großen Teil weiterverwenden.

Alles neu machen für ein 13 Jahre gewachsenes Produkt ist gefährlich und teuer. Würde mal sagen mit gleicher Manpower braucht man dann mindestens 5 Jahre um den alten Stand wieder zu erreichen.

Solange müsste man auch das alte Produkt noch parallel weiter supporten.

Den Kunden ist es in der Regel egal ob der Quellcode schöner ist und womit programmiert wurde, Hauptsache das Programm macht was es soll.

[himitsu]

Wir selbst hatten mal bissl mit FMX für Android rumgespielt und auch mit anderen Dingen rumgespielt, aber mangels Zeit/Ressourcen wurde nichts draus.
Den Grundkern unseres Proguckts konnten wir auch schon teilweise relativ leicht so umstellen, dass er auch im Android kompiliert und für eine neue Testanwendung genutzt werden konnte.
Aktuell lassen wir von einer in der nähe lebenden Fremdfirma ein Webfrontend für gewisse Module entwickeln, die dann im Webbrowser und auch via Browser auf einem Smartphone mit Barcodescanner laufen sollen.
Da wir viel Logik in der Datenbank (Trigger und Funktionen) haben, gehen sie direkt auf die Datenbank, bzw. Teilweise auf Funktionen in einer eigenen Serveranwendung (z.B. Dateizugriff auf unser DMS).
Das große Projekt bleibt aber weiterhin erstmal Delphi. Mal für zwei/drei Jahre die Enwicklung des Projektes fast zu stoppen und alle Ressourcen in eine komplette Neuentwicklung zu stecken, mit Techniken, die auch noch niemand umfänglich beherrscht, war nicht so wirklich schön anzusehn.



FMX ist Multi-Plattform, aber Web gibt es nicht als Plattform. (die GUI nur für Windows, Apple und Android ... Linux und Web nur von Fremdfirmen)

Es gibt noch den HTML5 Builder, früher war's mal Delphi4PHP, dann RadPHP und vorher VCL for PHP oder wie es noch hieß, beim Originalentwickler.
https://www.embarcadero.com/de/products/HTML5-Builder
https://edn.embarcadero.com/article/34059

Das ist/war quasi eine "Kopie" der RTL/VCL nach PHP. (komplett neu, und komplett in PHP/JavaScript geschrieben)
Der Grundcode ist in PHP auf dem Webserver und es können Events zurück ins PHP oder auch lokal als JavaScript laufen.


Dann gibt es mehrere Frameworks, auch Eines von Borland/Embarcadero selbst, deren Namen ich immer vergesser (das alte langsame QC war damit geschrieben),
wo im Hintergrund Delphi-Code als Serveranwendung läuft und die HTML-Code generieren und rausgeben.

Es gibt auch ein Projekt, wo eine VCL-Anwendung auf dem Server ausgeführt wird, deren Oberfläche abgefangen und via Webbrowser anderswo angezeigt wird.
Kannst'e quasi grob mit RDP bzw. TeamViewer vergleichen, aber für einen großen produktiven Einsatz würde ich das nicht empfehlen.