Moltes empreses operen des de fa anys o dècades aplicacions Delphi estables que modelen el nucli dels seus processos: gestió de comandes, producció, servei, logística, facturació, administració d’equips, fluxos de documents. En aquests sistemes no hi ha només codi, sinó una interacció sòlida de regles de negoci, model de dades, conducció d’usuari i experiència d’explotació. Precisament això fa que la modernització sigui exigent: el valor real rarament résideix en la superfície, sinó en la lògica de negoci acumulada.
Quan la modernització s’entén com a «fer-ho de nou», la pèrdua està garantida. No perquè les noves tecnologies siguin intrínsecament dolentes, sinó perquè el coneixement implícit del sistema antic —casos especials, dades històriques, excepcions de procés, detalls regulatoris— sovint no es reconstrueix completament durant la migració. El resultat són errors de regressió costosos, canvis en els temps de procés, problemes d’acceptació i un projecte que s’allarga més del previst.
Tanmateix, Delphi es pot modernitzar molt bé sense perdre la lògica de negoci. La clau és un enfocament controlat i gradual: primer crear transparència (arquitectura, dades, riscos), després desacoblar (UI, accés a dades, lògica de domini), a continuació modernitzar (controladors de base de dades, Unicode/64 bits, APIs, serveis, multiplataforma) —i assegurar l’operació en curs. Aquest article descriu patrons de modernització pràctics, trencaments típics i una metodologia que funciona en entorns B2B amb alta criticitat de procés.
Per què la modernització de Delphi rarament és un „projecte tècnic“
En la pràctica, les modernitzacions no fallen per un flag de compilador que falta, sinó per suposicions equivocades sobre el comportament del sistema. Les aplicacions Delphi ampliades al llarg d’anys sovint contenen:
- Regles de negoci en esdeveniments de GUI (OnClick, OnExit, OnValidate), sovint distribuïdes per molts forms
- Sentències SQL «prop de la superfície» i optimitzades durant anys per una base de dades concreta
- Esquemes d’evitació per dades històriques, casos especials, variants de client o lògica de mandant
- Procés batch que en la pràctica s’executen a hores fixes i tenen dependències
- Integracions amb ERP, DMS, CRM o màquines que estan gairebé sense documentar
- Coneixement silenciós en forma de rutines d’explotació: «Si error X, primer comprovar Y»
Qui comença amb un reescriptura tipus Big-Bang ha de regenerar tot aquest coneixement —incloent-hi els errors que la solució antiga ja no comet. L’enfocament més encertat és tractar la lògica de negoci com un actiu: primer aïllar, després assegurar, i finalment modernitzar.
Modernització sense pèrdua de lògica: imatge objectiu i principis rectors
Una imatge objectiu viable per a sistemes B2B no és un «tot de nou», sinó una arquitectura que permeti canvis. Característiques típiques:
- Responsabilitats separades (UI, domini/lògica de negoci, accés a dades, integracions)
- Testabilitat i mesurabilitat (tests de regressió, logging, monitoring, builds reproduïbles)
- Intercanviabilitat gradual (modernitzar la UI sense reestructurar immediatament el model de dades; migrar la BD sense reescriure la UI)
- Capacitat d’API (REST-Server o capa de serveis per connectar portals, mòbil, integracions)
- Operabilitat (Windows- i Linux-Services, desplegaments clars, estratègia de rollback)
A Delphi això és especialment assolible perquè es poden reutilitzar les units i classes de domini existents mentre es modernitza l’entorn extern: accés a dades de BDE cap a BDE-Ablösung amb connexió nativa, nous endpoints REST, nous mòduls UI, nous desplegaments.
Inventari: què cal preservar realment?
Abans de «tocar» el codi, val la pena fer un inventari estructurat. L’objectiu no és una documentació exhaustiva, sinó una base de decisió fiable.
1) Mapa de lògica de negoci en lloc d’un marató de lectura de codi
Ha demostrat la seva utilitat un mapa de lògica de negoci amb les següents perspectives:
- Use-Cases: Quins processos centrals són crítics per al negoci? (p. ex. crear comanda, factura, estorn, devolució, servei de màquina, contracte de manteniment)
- Regles: Quines validacions, càlculs, autòmats d’estat existeixen?
- Variants: Mandants, configuracions de client, regles específiques de països
- Interfaces: Import/Export, ERP/DMS/CRM, dispositius/protocols
- Batch/Jobs: execucions nocturnes, informes, conciliacions de dades
A partir d’aquest mapa es dissenyen paquets de modernització prioritzats: què cal mantenir estable, què pot canviar i què pot quedar per més endavant.
2) Fer visibles els deutes tècnics
Deutes tècnics típics en sistemes Delphi antics:
- Borland BDE/Paradox-dependències
- Cadenes ANSI/falta de migració a Unicode
- Sistema exclusiu de 32 bits, components de tercers obsolets
- Lògica monolítica de formularis, variables globals, units amb efectes secundaris
- Límites de transacció poc clars i «SQL a tot arreu»
L’art consisteix a no «netejar» aquests punts de manera dogmàtica, sinó a ordenar-los per minimitzar el risc i maximitzar el valor per al negoci.
Desacoblament arquitectònic: la palanca contra la pèrdua de lògica
La raó més freqüent de pèrdua de lògica és la mescla de UI, accés a dades i regles de negoci. Per tant, la modernització comença amb desacoblament —no amb un «nou framework UI».
Arquitectura Layer-3 com a estat objectiu pragmàtic
Per a moltes aplicacions de llicència Delphi existents funciona molt bé una Layer-3 Architektur:
- Presentation Layer: VCL/FMX-Forms, ViewModels/Presenter, validació només pròxima a la UI (format, camps obligatoris)
- Business Layer: models de domini, serveis, regles, lògica d’estat, càlculs
- Data/Integration Layer: repositoris, parts SQL/ORM, adaptadors d’interfícies, clients REST, messaging
El benefici: la lògica de negoci esdevé testable i reutilitzable. Més endavant, un portal de client, un REST-Server o un servei Linux podran utilitzar exactament els mateixos serveis de domini. Això permet modernitzar la „pell exterior“ sense reinventar el nucli de lògica.
Strangulation Pattern: abraçar el sistema antic pas a pas
Un patró de migració provat és l’Strangulation Pattern: les noves funcionalitats es desenvolupen ja en l’estructura nova (p. ex. servei de domini + repositori), mentre els forms existents es transformen progressivament. El món antic continua operatiu, però és substituït a trossets per la nova implementació.
És important invertir les dependències activament: no «el form crida SQL», sinó «el form crida el Service», i el Service decideix. Aquesta petita inversió sovint aporta el guany més gran.
Modernitzar l’accés a dades: BDE-Ablösung i planificació neta de FireDAC
Un pas central de modernització és la BDE-Ablösung. Les empreses sovint subestimen que no es tracta només de controladors, sinó de la semàntica SQL, transaccions, bloquejos, tipus de dades i comportament d’errors. Els stacks moderns de Delphi solen recolzar-se típicament en BDE-Ablosung mit nativer Anbindung amb controladors natius (p. ex. per MariaDB/MySQL, PostgreSQL, SQL Server).
Què es decideix realment en la transició
- Objectiu de base de dades: Es manté la BD actual? Té sentit una reestructuració de la base de dades (p. ex. de Paradox/Firebird a MariaDB o PostgreSQL)?
- Model de transaccions: On comencen/acaben les transaccions? Quins casos d’ús han de ser atòmics?
- Concurrència/Bloqueig: Optimista vs. pessimista, tractament de deadlocks, estratègies de retry
- Dialecte SQL: funcions de data, comportament de cadenes, tractament de NULL, sensibilitat a majúscules/minúscules
- Rendiment: índexs, plans de consulta, paginació, insercions en lot
La lògica de negoci depèn íntimament del comportament de les dades. Qui migra «de passada» corre el risc d’aberracions subtils en la pràctica: aproximacions, ordenacions, límits de data, conflictes de bloqueig. Per això la capa de dades ha d’entrar aviat en el pla de modernització, incloent-hi el camí de migració i l’estratègia de dades de prova.
Passos pragmàtics per a la migració a FireDAC
En lloc de reestructurar tota l’aplicació d’una tirada, ha demostrat la seva eficàcia la següent seqüència:
- Introduir una capa d’accés a dades (Repository/DAO) com a façana
- Canviar casos d’ús individuals a FireDAC (p. ex. «lectura» primer, «escriptura» més tard)
- Unificar el maneig de connexions, tractament d’errors, logging
- Apagar gradualment components BDE on la façana sigui estable
Així l’aplicació roman sempre lliurable i s’evita un període llarg on «tot està mig fet».
Unicode, 64-Bit i dependències: les trappes de modernització en detall
Moltes modernitzacions no fracassen per concepte, sinó per qüestions de detall subestimades. Tres d’aquestes qüestions són especialment freqüents en projectes Delphi.
Migració a Unicode: no només cadenes, sinó fluxos de dades
En versions molt antigues de Delphi els sistemes provenen d’un món ANSI. Una migració a Unicode afecta:
- Tipus de cadena i conversions (WideString/AnsiString/UnicodeString)
- Maneig de fitxers i rutes (API Windows, rutes de xarxa)
- Import/Export (CSV, camps de longitud fixa, EDI, interfícies legades)
- Ordenació/collation a la base de dades
És essencial identificar els fluxos de dades crítics (p. ex. texts de factura, denominacions d’articles, adreces internacionals) i establir tests de regressió per a ells. Unicode és menys una «reconstrucció» i més un procés de qualitat transversal.
Canvi a 64-Bit: la memòria no és l’únic tema
El pas a 64 bits sovint es redueix a la mida dels punters. En la pràctica es tracta més aviat de:
- Components de tercers obsolets sense suport 64 bits
- Dependències COM/ActiveX
- DLLs i controladors (codi de codi de barres, dispositius, criptografia, signatura)
- Instal·ladors/desplegament i rutes del registre (WOW64)
Una estratègia raonable és primer inventariar totes les dependències externes i definir alternatives. Aleshores el pas a 64 bits és planificable i no es converteix en una sorpresa a l’últim moment abans del lliurament.
Windows 11 ARM64: revisar-ho aviat en comptes de pagar-ho tard
Amb Windows 11 ARM64 apareix una nova classe de sistemes de destinació. Encara que no totes les empreses necessitin immediatament builds natives ARM64, és sensat provar-ho aviat:
- Hi ha dependències natives (DLLs, controladors) que no funcionen sota ARM64?
- L’aplicació depèn d’emulació, i això és acceptable?
- Com és l’instal·lador, com són les opcions d’actualització/reparació?
En projectes de modernització això sol ser un tema «tardà» i costós. Millor: incloure’l a la roadmap de plataforma i aclarir-lo tècnicament des de bon inici.
REST-Server i serveis: fer que la lògica de negoci estigui disponible per portals i integració
Moltes empreses no modernitzen Delphi perquè l’aplicació d’escriptori «és vella», sinó perquè apareixen noves demandes: portal de clients, accessos per socis, processos mòbils, integració amb ERP/DMS/CRM, pipelines de reporting. Per això calen interfícies clares. Un REST-Server sovint és el pont més pràctic.
API primer? Només si vénen els drets i la lògica de domini
Una API només és un guany si aplica la mateixa lògica de negoci que el client. En cas contrari apareixen dos conjunts de regles: una al client d’escriptori i una altra al backend. Les conseqüències són incoherències i vies d’explotació.
Per això una capa de REST-Server hauria d’assentar-se tant com sigui possible sobre els serveis de domini. Components típics:
- Autenticació/autorització (rols, mandants, permisos)
- DTOs/serialització amb regles de versionat clares
- Concepte de transacció i errors (estats HTTP, Problem-Details, logging)
- Idempotència i concurrència (per a retries, processament per cues)
Modernitzar serveis Linux i serveis Windows
Els processos batch i les integracions en moltes empreses s’executen com Windows Services, tasques del planificador o fins i tot instàncies d’escriptori «ocultes». En la modernització cal consolidar:
- Separar UI i lògica en background
- Plans d’execució configurables i paràmetres operacionals clars
- Logging net (logs estructurats, correlació per job/request)
- Opció d’executar serveis sota Linux (p. ex. per desplegaments containeritzats)
El benefici no és només «modern», sinó operacional: explotació reproducible, menys intervencions manuals, recerca d’errors més eficient.
Modernitzar la UI sense tocar el nucli: VCL, FMX i enfocaments híbrids
Mols plans de modernització comencen per la UI. Això pot tenir sentit —siempre que sigui clar quin benefici aporta. Si la lògica de negoci està desacoblada, la UI es pot renovar amb molt menys risc.
Modernitzar progressivament aplicacions VCL
VCL continua sent una elecció robusta en molts escenaris B2B, especialment on domina Windows amb alta productivitat a l’escriptori. Modernitzar pot voler dir:
- Reduir la lògica UI (Presenter/ViewModel), traslladar regles de negoci a serveis
- Netejar l’ecosistema de components, consolidar controls propis
- Millorar la responsivitat (Async, treballs en background, progress, Cancel)
- Accessibilitat, validació consistent, missatges d’error més útils
Això aporta benefici tangible sense reescriure tota la interfície.
Multiplataforma Delphi: quan FMX té sentit
Si existeixen requeriments realment multiplataforma (Windows, macOS, i potser Linux en context de serveis), FMX pot ser una opció. El determinant és l’esperat: multiplataforma implica treball adicional de proves i integració (fonts, impressió, diàlegs OS, sistema de fitxers, empaquetat/desplegament). Els costos són previsible si la lògica de negoci ja està en una capa neta.
Un camí pragmàtic freqüent és l’híbrid: VCL es manté per al client Windows, mentre que nous frontends (portal, app mòbil) s’alimenten mitjançant el REST-Server. Així s’aconsegueix multiplataforma travessant els límits del sistema, no amb un únic stack UI.
Testing i regressió: com «fixar» la lògica de negoci
Perdre la lògica de negoci significa, en la pràctica, que el sistema lliura resultats diferents en casos límit. Això rarament és immediatament visible però és car. Per això la testabilitat no és un luxe sinó una eina de modernització.
Use-Cases daurats i dades de referència
Ha funcionat bé disposar d’un conjunt de use-cases «daurats»: processos reals i crítics amb dades definides i resultats esperats (p. ex. la cadena documental d’oferta a nota de crèdit, o una ordre de manteniment amb peces de substitució i registres de temps). Aquests s’estableixen com a tests de regressió o, com a mínim, scripts de prova repetibles.
És important no només els camins d’èxit, sinó també els camins d’error típics (conflictes de bloqueig, permisos mancats, dades mestres incompletes, fitxer d’import duplicat).
Automatitzar on genera més palanca
No tots els projectes heredats necessiten de cop un 80% de cobertura de tests unitari. L’alt ROI sovint arriba en:
- Serveis de domini (càlculs, regles, canvis d’estat)
- Accés a dades amb contracts clars (mapping, SQL, transaccions)
- Tests d’API (auth, permisos, versionat)
L’objectiu és estabilitat davant canvis, no mètriques acadèmiques.
Model operatiu a la pràctica: full de ruta de modernització en etapes
Des del punt de vista B2B, la modernització ha de mantenir la capacitat de lliurament. Un full de ruta típic que s’alinea amb els riscos:
Etapa 1: Anàlisi, arquitectura objectiu, Quick Wins (2–6 setmanes)
- Mapa del sistema (mòduls, bases de dades, interfícies, jobs, dependències)
- Matriz de riscos (BDE, tercers, 32/64-Bit, Unicode, desplegament)
- Definició de l’arquitectura objectiu (Layer-3, capa de serveis, estratègia d’API)
- Quick Wins: estabilitzar el procés de build, millorar logging, ordenar el control de versions
Etapa 2: Desacoblament de la lògica de negoci (continu, incremental)
- Identificar serveis de domini i extreure’ls dels forms
- Introduir façanes de repositori
- Primeres proves de regressió per use-cases crítics
Etapa 3: Modernitzar accés a dades/capa BD
- Introduir FireDAC, establir concepte de connexió i transacció
- BDE-Ablösung per mòduls (o migració de base de dades amb funcionament en paral·lel)
- Provar rendiment i comportament de bloqueig sota càrrega
Etapa 4: Implementar REST-Server i integracions
- API amb autenticació, permisos, versionat
- Connectar portals/integracions sense lògica duplicada
- Consolidar serveis per batch i processos de fons
Etapa 5: Decisions de plataforma i UI (64-Bit, ARM64, Multiplataforma)
- Build en 64-Bit, substituir dependències
- Comprovar/planificar compatibilitat ARM64
- Modernització de UI: refresc VCL o FMX/híbrid, segons el benefici per al negoci
L’ordre està triat intencionadament perquè primer s’obtingui transparència, després s’estabilitzi el nucli i només després s’estenguin els canvis «visibles». Així es redueix el risc i l’explotació roman planificable.
Anti-patrons típics: què encareix les modernitzacions innecessàriament
Alguns patrons reapareixen en auditories i projectes de rescat:
- «Construïm de nou i només traslladem funcions»: gairebé sempre condueix a pèrdua de lògica perquè falten els casos especials.
- API com a món paral·lel: les regles de negoci es queden al client i es reempren al backend.
- Canvi de base de dades sense tests semàntics: mateixes dades però comportament diferent (NULL, ordenació, lògica de dates).
- Gestió de dependències massa tardana: 64-Bit/ARM64 falla per una DLL petita just abans del Go-Live.
- «Refactoring primer» sense objectiu: molts canvis amb poc benefici mesurable, alta regressió.
La contrapartida és sempre la mateixa: primer aclarir l’arquitectura objectiu i els riscos, després reconstruir de manera incremental, testant i fent visible la lògica de negoci.
Conclusió: modernitzar és preservar —i ampliar amb criteri
Modernitzar Delphi sense perdre la lògica de negoci no és contradictori, sinó una disciplina. Les empreses no han de triar entre «conservar-ho tot» i «reemplaçar-ho tot». Amb una separació arquitectònica neta (p. ex. Layer-3), una BDE-Ablösung controlada cap a FireDAC, una estratègia d’API basada en REST-Server i un pla clar per a Unicode, 64-Bit i noves plataformes com Windows 11 ARM64 es pot transferir un sistema evolucionat a una estructura preparat per al futur de manera gradual.
El factor clau és tractar la lògica de negoci com l’actiu central: aïllar-la, fer-la testable i després modernitzar-la. Així neix una arquitectura que dóna suport a portals, serveis i requisits multiplataforma sense posar en risc l’operació en curs.
Si planifiqueu una Delphi Modernisierung i voleu integrar netament lògica de negoci, accés a dades i explotació, parleu amb nosaltres sobre un camí de migració realista: https://net-base-software-gmbh.de/kontakt/