Reconstruir l'stack tecnològic per a l'era de la IA: arquitectura componible, cloud i No-Code
Molt pocs CTO tenen l'oportunitat de construir un stack des de zero. La majoria n'hereten un: una col·lecció de decisions preses al llarg dels anys, optimitzades per a un món que ja no existeix, amb prou pes perquè substituir-lo de cop sigui inviable i prou disfuncions perquè deixar-lo estar sigui encara pitjor.
M'he passat la major part de la carrera operant stacks heretats, no projectes greenfield. Per això la pregunta del 2025 no és «com seria l'stack ideal per a l'era de la IA?», sinó «com faig evolucionar l'stack que tinc cap a una cosa capaç d'absorbir workloads natius d'IA, integrar-se amb sistemes autònoms i escalar sense ensorrar-se?».
La resposta passa per tres canvis estructurals que convergeixen aquest any: l'arquitectura componible, la rearquitectura del cloud per a workloads d'IA i el pas del Low-Code al No-Code per a casos d'ús acotats. Cap dels tres és un concepte nou. El que és nou és que l'argument econòmic per convertir-los en compromisos arquitectònics de fons — i no en experiments tàctics — ja costa molt de rebatre.
Vet aquí com plantejar la reconstrucció de l'stack sense fer veure que te'n pots sortir començant de zero.
Els símptomes que delaten un stack endarrerit
Abans de decidir què canvies, diagnostica què falla. Els símptomes d'un stack que va a remolc de l'era de la IA:
- Cada nova integració triga més que l'anterior. El que abans era un sprint ara és un trimestre. El codi acumula acoblament més de pressa del que tu acumules capacitats.
- Les features d'IA exigeixen un pipeline a mida cada vegada. Cada integració d'un LLM reinventa la gestió de prompts, el parsing de la sortida, l'avaluació i la monitorització, perquè la plataforma no t'ofereix primitives compartides.
- Els costos de cloud escalen de manera no lineal amb l'ús. Els ingressos creixen 2x; el cloud, 3x. L'arquitectura et serveix a tu, però no al teu marge.
- Cada petició de compliance desencadena sis setmanes de crisi. Cada nova regulació obliga a reauditar sistemes que no es van dissenyar per ser auditats.
- Els enginyers júniors no poden lliurar features de cap a cap. L'stack té tantes peces especialitzades que qualsevol feina no trivial demana tres persones de tres equips diferents.
Si en reconeixes més de dos, el teu stack acumula deute estructural més de pressa del que pots refactoritzar. La reconstrucció no és opcional; l'únic que ho és, és l'abast.
Arquitectura componible: l'opció per defecte del 2025
L'stack monolític tradicional era coherent però rígid. L'era dels microserveis era flexible però operativament brutal. L'arquitectura componible — el punt mitjà real que per fi madura el 2025 — consisteix a construir sistemes a partir de components ben definits que es poden desenvolupar, substituir o escalar de manera independent, sense l'overhead operatiu dels microserveis purs.
Les característiques que defineixen un stack componible:
- Primer, les interfícies. Cada component té un contracte ben definit (normalment API + esdeveniments). La implementació és intercanviable.
- Les dades com a plataforma. Les dades són un actiu compartit al qual s'accedeix amb patrons consistents, no un subproducte de cada servei.
- Acoblament laxe en execució, estret en disseny. Els components no s'han de conèixer en temps d'execució, però en temps de disseny hi ha un model coherent de com es componen.
- Substrat operatiu comú. Observabilitat, autenticació, desplegament i configuració són primitives compartides, no es reinventen a cada servei.
El canvi que la majoria d'organitzacions han de fer el 2025 és passar de «tenim microserveis» a «tenim primitives componibles». El primer sovint vol dir un garbuix de serveis amb contractes inconsistents, patrons d'integració ad hoc i heterogeneïtat operativa. El segon vol dir menys blocs, però més ben definits.
Com és una arquitectura componible a la pràctica
Un patró concret que funciona per a la majoria de scale-ups:
Capa de plataforma core (amb criteri marcat, compartida):
- Gestió d'identitats i accessos (única font de veritat per a l'autenticació)
- Bus d'esdeveniments i/o cua de missatges per a la comunicació asíncrona
- Stack d'observabilitat (logs, mètriques, traces, errors)
- Primitives de desplegament i infraestructura (mòduls d'IaC, plantilles golden)
- Plataforma de dades (data warehouse, streaming, governança)
Capa de serveis de domini (acotada, substituïble):
- Serveis de lògica de negoci, cadascun amo de les seves dades, que es comuniquen a través de contractes ben definits
- Serveis d'integració que adapten sistemes externs als patrons interns
Capa d'experiència (flexible, de cicle ràpid):
- Aplicacions frontend (web, mòbil)
- Serveis backend-for-frontend (BFF) que componen serveis de domini en API específiques de cada experiència
- Capa de features d'IA que integra LLM, agents i sistemes de retrieval
Capa d'infraestructura d'IA (emergent, amb propòsit):
- Capa d'accés a models amb routing, fallback i avaluació
- Capa de retrieval i context (bases de dades vectorials, embeddings, grafs de coneixement)
- Runtime d'agents per orquestrar l'ús d'eines
- Pipelines de feedback i avaluació
Això no és una arquitectura de referència: és un patró. Els detalls depenen del teu domini, de la teva escala i del sistema que ja tens. El que importa és que cada peça tingui un rol clar i cada interfície sigui explícita.
Els workloads d'IA trenquen la teva estratègia cloud del 2022
L'estratègia cloud del 2025 és fonamentalment diferent de la del 2022. Els tres canvis que importen:
1. El multi-cloud ja no és teòric
La majoria de CTO parlaven de multi-cloud però operaven en un sol cloud. L'economia no justificava la complexitat. El 2025, el panorama de la IA ha capgirat el càlcul:
- L'accés als models condiciona la tria de regió i de proveïdor. El millor model per al teu cas d'ús pot ser en un cloud diferent del de la teva infraestructura principal.
- La disponibilitat de GPU depèn de cada cloud i és volàtil. La capacitat de GPU reservada a AWS no serveix de res quan el teu workload va millor amb un model d'Azure.
- La sobirania de dades empeny cap a regions concretes que no són disponibles a tot arreu. Compliance europeu, regulacions sectorials, clàusules de contractes amb clients.
No necessites que tot sigui multi-cloud. El que probablement sí que necessites és una capa d'IA multi-cloud: una abstracció que et permeti encaminar workloads a proveïdors diferents sense reescriure codi d'aplicació.
2. El patró «industry cloud» és real
Les plataformes cloud específiques de sector (ICP) estan passant de les diapositives dels analistes a l'adopció en producció. Per als CTO de sanitat, serveis financers, sector públic, retail o indústria, el càlcul de construir o comprar la feina de plataforma fonamental ha canviat. Els industry clouds dels hyperscalers resolen compliance, patrons de dades i integracions que internament costarien anys de construir.
La pregunta no és si fer servir capacitats cloud específiques del teu sector, sinó com integrar-les sense un lock-in que t'hipotequi la flexibilitat futura.
3. L'arquitectura de costos és una qüestió de disseny, no de facturació
Els workloads d'IA fan que el cost del cloud sigui no lineal. Una crida a l'API d'un LLM pot ser 1.000 vegades més cara que una consulta a la base de dades. La inferència a escala afegeix costos que les teves pràctiques de FinOps no modelen. Les bases de dades vectorials amb índexs grans s'encareixen de pressa.
La disciplina del 2025: el cost és una restricció de disseny de primer ordre. Cada decisió arquitectònica que toqui workloads d'IA hauria de portar un model de cost adjunt:
- Cost d'inferència per usuari a l'escala objectiu
- Corba prevista de creixement del cost a mesura que creix l'ús
- Estratègia de fallback quan el cost supera el pressupost
- Model més barat com a alternativa allà on la qualitat ho permeti
Els equips que adopten aquesta disciplina aviat s'estalvien la conversa trimestral sobre per què la factura d'AWS s'ha duplicat.
El No-Code com a evolució natural del Low-Code
El No-Code sovint es despatxa amb un «això és per a perfils de negoci». Aquest enquadrament passa per alt el canvi estructural que s'està produint.
L'evolució és clara: les plataformes Low-Code van democratitzar la construcció d'aplicacions senzilles. No van substituir l'enginyeria: li van treure de sobre tota una classe de feina trivial. El No-Code, amb interfícies augmentades amb IA, està fent el mateix amb una altra capa de feina.
On importa el No-Code per als CTO el 2025:
1. Eines internes
Totes les empreses construeixen dotzenes d'eines internes: panells d'administració, interfícies de correcció de dades, eines de flux de treball per als equips d'operacions. El 2020 les construïen els enginyers. El 2025 les construeixen els equips d'operacions amb plataformes No-Code, supervisats per enginyers que fixen els guardrails.
El temps d'enginyeria que es recupera és substancial. El risc és que, sense disciplina, acabis amb un paisatge de shadow IT. El patró que funciona: aprovar una plataforma No-Code concreta, definir els patrons d'accés a dades, exigir revisió interna per a tot allò que toqui dades de clients i deixar que els equips es construeixin les seves pròpies eines.
2. Automatització de fluxos augmentada amb IA
Els constructors d'agents No-Code, els orquestradors de fluxos i les plataformes d'automatització natives d'IA maduren de pressa. Per a fluxos que són un 70% predictibles, amb la IA encarregant-se del 30% que varia, les plataformes No-Code són l'eina adequada.
3. Prototipatge ràpid i test de mercat
El cas d'ús del fundador en solitari: posar a prova una idea de producte, validar un flux, demostrar que un client pagarà — tot abans de comprometre's amb enginyeria de producció. Les plataformes No-Code són el lloc adequat per fer-ho, i els CTO haurien de sentir-s'hi còmodes en lloc de combatre el patró.
On el No-Code no hi pinta res
Per ser precisos amb els límits:
- Les superfícies de producte core. El codi que et diferencia de la competència ha de ser teu.
- Tot el que tingui lògica de negoci complexa o requisits alts de fiabilitat. Les plataformes No-Code tenen límits en totes dues coses.
- Tot el que hagi d'escalar substancialment o integrar-se a fons amb els teus sistemes. Replatformar quan el No-Code se't queda petit surt més car que construir-ho bé des del principi.
La feina del CTO és traçar aquests límits de manera explícita, perquè els equips sàpiguen on s'acaba el No-Code i on comença l'enginyeria.
El pla de reconstrucció pragmàtic
No estàs construint un stack des de zero: n'estàs fent evolucionar un. Així és com jo ho seqüenciaria:
Fase 1: avaluar (4–6 setmanes)
- Inventaria l'stack. Cada servei, cada integració, cada peça d'infraestructura compartida.
- Classifica cada peça. Estratègica (ens diferencia), commodity (ha de funcionar però no és especial), legacy (amb data de retirada).
- Mesura el dolor. Quines peces ens alenteixen? Quines costen desproporcionadament? Quines bloquegen iniciatives futures?
- Projecta-ho sobre l'arquitectura objectiu. Quina peça pertany a quina capa componible?
Fase 2: triar la primera aposta (1–2 mesos d'execució)
La primera iniciativa de reconstrucció hauria de ser:
- Concreta (un component específic, no «modernitzar la plataforma»)
- Acotada (s'acaba en un trimestre, no en un any)
- D'alt valor (elimina un dolor real)
- De baix risc (si falla, no s'endú el negoci per davant)
Una bona primera aposta pot ser consolidar l'stack d'observabilitat, construir una capa unificada d'accés a la IA o aïllar un servei de domini amb una interfície neta.
Fase 3: establir el patró
La primera iniciativa no compta només pel seu resultat. Compta perquè estableix els patrons que farà servir la resta de l'stack: estàndards d'interfície, patrons de desplegament, contractes d'observabilitat, primitives d'integració d'IA.
Si l'encertes, les iniciatives següents s'acceleren. Si l'erres, cada iniciativa posterior torna a obrir les mateixes discussions.
Fase 4: escalar la reconstrucció
A partir d'aquí, la reconstrucció esdevé sistemàtica. Iniciativa a iniciativa, fas migrar l'stack cap a l'arquitectura objectiu — sense fer mai una reescriptura big-bang. Cada iniciativa té valor per si sola; l'efecte acumulat és un stack transformat.
Un ritme raonable són 2–4 iniciatives arquitectòniques significatives l'any. Anar més de pressa tendeix a generar massa canvis en curs alhora. Anar més a poc a poc vol dir que l'objectiu no para de moure's.
Les reconstruccions fracassen quan són un projecte secundari
Les reconstruccions d'stack competeixen amb les features pel temps d'enginyeria. La tensió és real i no es resol del tot.
El patró que he vist funcionar: dedicar un equip de plataforma (2–4 enginyers més un tech lead) a la reconstrucció arquitectònica, separat dels equips de features. L'equip de plataforma és l'amo de l'evolució de les primitives componibles. Els equips de features les consumeixen.
Per a les organitzacions que no tenen plantilla per a un equip de plataforma dedicat, els squads dedicats en nearshore encaixen bé en aquest paper. La feina de plataforma té lliurables clars i un abast acotat, i es beneficia d'enginyers que s'hi dediquen a temps complet en lloc d'anar saltant de context.
Això no va d'estalviar costos: va de concentrar l'esforç. Una reconstrucció arquitectònica té èxit quan algú hi pensa a temps complet, no quan és el projecte secundari de tres enginyers de features.
L'stack que guanya el 2025
Els CTO que aniran per davant el 2026 són els que aquest any fan apostes arquitectòniques concretes:
- Primitives componibles, no una proliferació de microserveis.
- Una capa d'integració d'IA que sigui un producte, no una col·lecció de crides a API.
- Multi-cloud on importa (IA, compliance) i un sol cloud on no.
- No-Code per als problemes que toca; enginyeria per als que no.
- Un equip de plataforma — o capacitat equivalent — empenyent la reconstrucció.
Els que quedaran enrere són els que encara apedacen un stack de l'era 2020 amb requisits del 2025: una batalla perduda que cada trimestre es fa més costeruda.
Si has de dotar d'equip una reconstrucció de plataforma al costat del teu equip intern, parla amb un CTO sobre com és, a la pràctica, un squad de plataforma en nearshore.
