Modernisierung von Legacy-Anwendungen

[TigerLilly]

Gibt es hier noch jemanden, dem eine Modernisierung einer Legacy-App ins Haus steht?
- Datenbank Single User/Multi User
- Multi Platform (jedenfalls Windows/Mac)
- Teilbereiche Mobile

Ich würde mich gern zu den Themen austauschen, vielleicht können wir einander da ja unterstützen + von unterschiedlichen Blickwinkeln profitieren?

Hat jemand Interesse?

[Uwe Raabe]

Zitat von TigerLilly:

Gibt es hier noch jemanden, dem eine Modernisierung einer Legacy-App ins Haus steht?

Nicht, dass mir das selbst ins Haus steht, aber daraus besteht der weitaus größte Teil meiner Aufträge.

[freimatz]

Mobile - da gibt es schon Legacy?

Ansonsten habe ich es jeden Tag mit Legacy-Anwendungen zu tun. Sie sind 15-30 Jahre alt.

Empfehle dazu auch Discord.

[Uwe Raabe]

Zitat von freimatz:

Mobile - da gibt es schon Legacy?

Ich hatte das so verstanden, dass die drei Punkte das Ziel darstellen.

[freimatz]

Scheint mir plausibel. Der Istzustand wäre auch interssant.

[Bernhard Geyer]

Zitat von freimatz:

Mobile - da gibt es schon Legacy?

Unsere erste Mobile Anwendung/Lösung hatten wir Unverkauft in die Rundablage entsorgt...
Also ja. Auch beim Mobil dürfte sich sehr viel getan haben (und nicht nur auf HW-Ebene mit den Erstgeräte auf Windows CE-Basis).

[Phoenix]

Zitat von TigerLilly:

Gibt es hier noch jemanden, dem eine Modernisierung einer Legacy-App ins Haus steht?
Ich würde mich gern zu den Themen austauschen, vielleicht können wir einander da ja unterstützen + von unterschiedlichen Blickwinkeln profitieren?
Hat jemand Interesse?

Also nicht, das es bei uns ins Haus stehen würde, aber wir begleiten seit etlichen Jahren viele Kunden in der DACH-Region bei der Modernisierung von Altlasten und auch bei der Neu-Entwicklung von Software im Bereich "Modern Business Applications".

In den allermeisten Fällen geht das in die Richtung von Ver-Service-fizierung von Businesslogik und Datenzugriff, so daß ein weiterer On-Premise Betrieb möglich ist, sich das ganze Gebilde aber in aller Regel deutlich besser in Richtung Cloud bewegt sowie von Plattformübergreifenden und teilweise auch Offlinefähigen Client-Anwendungen.

Die Ver-Service-fizierung ist dabei allerdings in aller Regel der Knackpunkt, denn sobald die Kunden sinnvolle APIs anbieten können, tun sich auf einmal neue Welten an Integrationsszenarien und damit auch neuen Geschäftsmöglichkeiten auf.

Allerdings ist bei uns der Technologiestack ein anderer als Delphi.

[Maliko]

Wir haben vorletztes Jahr unsere Software von Delphi 7 auf Delphi 10.3 geupdatet. Das war zwar ein ganz schöner Krampf, aber inzwischen läuft es einigermaßen rund. Wenn ihr das wirklich vor habt, stellt euch auf viel Ärger ein (zumindest wenn ihr ein so altes Projekt updatet). Mir fliegen immer noch 100te Deprecated-Meldungen beim Compilieren um die Ohren, weil wir einfach nicht dazu kommen alle Programmteile so zu updaten, dass aktuelle Componenten dafür genutzt werden. Einige Komponenten mussten wir sogar komplett ersetzen, da sie unter Delphi 10.3 nicht mehr lauffähig waren. Also nehmt euch gut Zeit wenn ihr ein so altes Projekt updaten wollt. Das wird dauern. Wir haben gut 3 Monate dafür gebraucht, bis alles wieder lief.

[TigerLilly]

Die Software läuft gut + wird aktiv vertrieben. Ich würde gern ca 2/3 binnen Jahresfrist erneuert haben, das lässt sich gut abgrenzen. Weil da stellenweise noch Code aus dem letzten Jahrtausend :- ) drin ist, würde ich alles, was allgemeiner Basiscode ist kübeln + neu machen. Ich würde auch alles, was mit Ausgabe etc zu tun hat, kübeln. Da gibt es viel zu viel neues und besseres (bzw gibt es manches jetzt eben auch nicht mehr). Ich würde wirklich nur den Kern der Businesslogik mitnehmen. Viele Anforderungen haben sich geändert und vieles weiß ich mittlerweile besser, bzw würde ich anders machen, weil ich weiß, wo in der Praxis Probleme auftauchen.

Aber vorher sind halt ein paar Grundsatzentscheidungen zu treffen:
- Als Web-Anwendung umsetzen? Native Anwendungen je Plattform? Saas?
- Welche Datenbank bei Stand-Alone bzw bei MultiUser
- Deployment und Installer bei Multiplatform
- Reporting und Ausgabe
- Import/Export/Replikation/Cloud
- Aktualisierung großer Datenmengen beim Kunden draußen

Und ja. Die Punkte waren als Ziele gedacht.

[Phoenix]

Zitat von TigerLilly:

Aber vorher sind halt ein paar Grundsatzentscheidungen zu treffen:
- Als Web-Anwendung umsetzen? Native Anwendungen je Plattform? Saas?
- Welche Datenbank bei Stand-Alone bzw bei MultiUser
- Deployment und Installer bei Multiplatform
- Reporting und Ausgabe
- Import/Export/Replikation/Cloud
- Aktualisierung großer Datenmengen beim Kunden draußen

Und ja. Die Punkte waren als Ziele gedacht.

Datenbank: Für standalone / Single-User reicht in aller Regel Sqlite. Andernfalls kommts drauf an was an Lizenzkosten bezahlt werden soll
Im Falle von OpenSource geht schon seit Jahren sehr vieles in Richtung PostgreSQL.

Oberfläche: Wir machen Grundsätzlich nur Web-basierte Anwendungen. Läuft wirklich problemlos überall: Link öffnen und App benutzen. That's it. In einigen Fällen installierbar als PWA (Progressive Web App), in den allerwenigsten Fällen und nur wenn es wirklich sein muss gewrapped in sowas wie Corodova.
Der Grund ist dass man mit einer einheitlichen Code-base wirklich alle Plattformen und vor allem auch alle Form-Faktoren (kleine hochkant Screens auf Smartphones über Tablet-Layouts bis hin zu Ultra-Wide Screens am Desktop) bedienen kann.
Schaut man sich z.B. Spotify an, Slack, MS Teams, Discord, Google Office, O365, Whatsapp, an (und viele viele andere Anwendungen), merkt man in den meisten Fällen noch nichtmal das das hintendran eigentlich alles nur Webseiten sind. Selbst 3D-Animationen mit 60FPS bekommt man damit problemlos hin.
Und wenn man ehrlich ist: Bei Geschäftsanwendungen ist es in aller Regel auch vollkommen egal wenn es Web-ig aussieht, hauptsache der Benutzer hat überall ein einheitliches Look & Feel und findet sich schnell zurecht.
Bei Consumer-Anwendungen sieht das allerdings ggf. anders aus, hier mag es unter Umständen sinnvoll sein, das man für eine möglichst breite Akzeptanz Plattform-Nativ aussehen will.

PWA's kann man bei Android auch einfach von der Webseite aus installieren. Will man das auf iOS in den Appstore bringen bleibt leider nichts anderes über als es zu Wrappen (z.B. Cordova), aber auch das ist in aller Regel kein Problem.

Die logische Schlussfolgerung daraus ist: Wenn man das Backend für das Web-Frontend sinnvoll ver-API-fiziert, ist es ein superkleiner Schritt das als SaaS bereitzustellen.

Sync-Thematiken mit lokalen Installationen sind meistens nur ein kleines technisches Detail (das haben wir auch schon etliche male gebaut).