En els darrers anys, la migració des d'arquitectures monolítiques cap a ecosistemes de microserveis s'ha convertit en un objectiu gairebé obligatori per a organitzacions que busquen escalar els seus equips tecnològics i accelerar l'entrega de valor. Tanmateix, a Q2BSTUDIO hem observat una tendència preocupant: la majoria d'aquests projectes es planifiquen com un exercici purament d'enginyeria de programari, centrat en diagrames de components, APIs REST i contenidors. Es dibuixen límits de domini en pissarres digitals, es discuteixen patrons de disseny i s'assumeix que la base de dades subjacent obeirà amb docilitat aquelles fronteres teòriques. La realitat, massa sovint, és ben diferent. Quan finalment arriba el moment de moure els actius d'informació, el pla col·lapsa davant d'una veritat incòmoda: les dades no s'adapten als esquemes, són els esquemes els que s'han d'adaptar a les dades.
Aquest fenomen és especialment agut en aplicacions a mida que han crescut orgànicament durant una dècada o més dins d'una única instància de base de dades relacional. El que va començar com un model de dades net i normalitzat, amb el temps es va convertir en una xarxa densa de dependències on les unions transversals entre dominis són la norma i no l'excepció. Els equips de desenvolupament, aprofitant l'absència de restriccions físiques, van construir informes que creuen quinze taules, van generar vistes materialitzades que alimenten mitja dotzena de mòduls diferents i van afegir columnes d'ús general que acaben sent escrites per processos als quals ningú els va assignar propietat. No es tracta de males pràctiques aïllades, sinó de la forma natural en què evoluciona un sistema quan la proximitat de les dades fa que els límits de negoci semblin irrellevants. El problema no és tècnic en origen, sinó epistemològic: l'organització va perdre de vista on acabava un context empresarial i on començava un altre, i aquella amnèsia es va cristal·litzar primer en l'esquema relacional.
La conseqüència directa és que qualsevol intent d'extracció guiat únicament per la lògica d'aplicació o per l'estructura del codi font està condemnat a xocar amb murs invisibles. A Q2BSTUDIO, quan abordem projectes de modernització de programari a mida, invertim deliberadament l'ordre d'anàlisi. Abans de proposar el primer servei, realitzem una arqueologia de la base de dades: mapem el graf real de relacions, identifiquem quines taules concentren escriptures des de múltiples orígens, mesurem volums i taxes de creixement, i busquem aquelles juntures naturals on la cohesió interna és alta i l'acoblament extern és baix. Aquelles línies de fractura, quan existeixen, rarament coincideixen amb els mòduls de la interfície d'usuari ni amb els paquets del backend. Sovint descobrim que un domini de negoci aparentment unitari està físicament atomitzat en desenes de taules entrellaçades amb altres contextos, o que una entitat secundària ha crescut fins a convertir-se en un coll d'ampolla de milers de milions de registres que cap migració massiva pot assumir en un cap de setmana.
L'estratègia que ha demostrat funcionar no consisteix a executar un gran pla dissenyat en una sala de juntes, sinó a tractar la descomposició com una sèrie d'experiments controlats i reversibles. Extraiem un candidat, movem únicament les dades que demostren pertànyer a una sola jurisdicció, despleguem el servei en paral·lel al flux legacy i contrastem resultats en producció. Si les mètriques divergeixen, aturem, ajustem i reintentem. Aquesta disciplina exigeix infraestructura que suporti la dualitat temporal, i aquí és on les plataformes cloud AWS/Azure aporten un avantatge decisiu: la capacitat d'escalar recursos de sincronització sota demanda, mantenir entorns de validació aïllats i absorbir pics de processament sense comprometre l'estabilitat operativa. El núvol no és només un destí de desplegament, sinó el laboratori que permet que les dades parlin abans que l'organització es comprometi amb una frontera incorrecta.
El mecanisme tècnic que fa viable aquest enfocament iteratiu és la captura de canvis en la font, coneguda com a CDC. En lloc de caure en l'engany de les escriptures duals, on cada nou servei segueix alimentant l'esquema antic i perpetuant l'acoblament, establim un flux unidireccional: la base de dades legacy roman com a font de veritat transitòria mentre els serveis extrets reconstrueixen el seu propi estat a partir d'un flux d'esdeveniments. Així, cada servei pot operar en paral·lel, validar la seva coherència i, només quan la confiança és suficient, assumir la responsabilitat total del seu domini. Aquest mètode resulta particularment útil quan ens trobem amb taules que resisteixen qualsevol classificació simple. Quan un conjunt de dades és escrit per múltiples dominis i forçar la seva assignació a un únic servei generaria una maranya de crides remotes, optem per reconèixer-lo com a infraestructura de plataforma: un servei propietari dedicat que desacobla les necessitats transversals del nucli de negoci.
No obstant això, fins i tot quan l'extracció de serveis avança amb èxit, existeix un cost que rarament es pressuposta en la fase de disseny: la desaparició de la consulta transversal lliure. En el monolit, un informe que combinava clients, comandes i facturació era una simple sentència SQL amb joins directes. Després de la divisió, aquelles taules habiten en silos intencionals i aquella operació ja no és possible sense infraestructura addicional. L'organització ha de construir pipelines d'integració o vistes materialitzades que recombinin les dades disperses, i aquesta solució no és una despesa de migració puntual, sinó un impost operatiu permanent. Cada vegada que un servei modifica un esquema, algú ha d'actualitzar la lògica de recombinació, i aquell algú sol ser un equip diferent del que va originar el canvi. Per mitigar aquesta càrrega, a Q2BSTUDIO integrem freqüentment capes de BI/Power BI que centralitzen l'analítica i el reporting sense sotmetre els serveis operatius a càrregues de lectura agressives ni a dependències creuades. Separar la ruta operativa de la ruta analítica no és un luxe, sinó una necessitat d'arquitectura.
Durant aquestes transformacions, la ciberseguretat adquireix una rellevància crítica que tampoc no es pot deixar per al final. Cada pipeline de sincronització, cada rèplica temporal i cada nou punt d'exposició de dades multiplica la superfície d'atac. El trànsit d'informació sensible entre el legacy i els nous serveis ha de xifrar-se, auditar-se i sotmetre's a polítiques de control d'accés estrictes des del primer dia. Paral·lelament, a Q2BSTUDIO explorem com els agents IA poden accelerar la fase de descobriment: alimentant models amb logs d'accés a base de dades, esquemes i patrons de consulta, és possible identificar automàticament dependències ocultes, detectar anomalies en la sincronització de dades i fins i tot suggerir límits de domini amb una objectivitat que els diagrames manuals rarament assoleixen. La intel·ligència artificial no reemplaça l'arquitecte, però elimina el soroll de la senyal, permetent-li concentrar-se en decisions estratègiques.
Al final, la lliçó que reiterem en cada projecte de modernització és que una descomposició exitosa no és un diagrama que s'executa, sinó una hipòtesi que es valida. Els límits de domini en un sistema madur no estan on l'equip d'arquitectura desitja que estiguin, sinó on les dades permeten establir-los. Planificar en termes de negoci és indispensable, però només l'evidència empírica de la producció pot confirmar si aquells límits són reals. A Q2BSTUDIO dissenyem aplicacions a mida i estratègies d'evolució tecnològica que parteixen d'aquesta honestedat: reconèixer que l'arquitectura neta és un horitzó, no un punt de partida, i que migrar cap a ella exigeix paciència, infraestructura adequada i la voluntat de deixar que les dades corregeixin el rumb abans que el cost de la correcció sigui prohibitiu. Perquè quan el codi i la informació discrepen, la informació sempre guanya.
