ContacteContext
Un dels objectius principals de l’Àrea d’Arquitectura de Drets Socials i Inclusió és establir un marc descriptiu de l’arquitectura de referència per garantir la coherència tecnològica i optimitzar el desenvolupament de les nostres solucions.
Aquesta arquitectura ens permet assegurar que totes les aplicacions i sistemes compleixin els mateixos estàndards, millorant l’eficiència operativa, reduint els riscos tecnològics i facilitant la col·laboració entre equips i proveïdors.
A més, una arquitectura estandarditzada facilita l’escalabilitat i robustesa de les solucions, millora la seguretat, resiliència i fiabilitat, i permet optimitzar costos de desenvolupament i manteniment a llarg termini.
Amb aquest propòsit, s’han establert un seguit de decisions d’arquitectura de compliment obligatori per qualsevol desenvolupament o integració d’una nova iniciativa o domini funcional de Drets Socials i Inclusió, que s’hauran de justificar en cas que no es compleixin.
Aquestes decisions estenen i amplien els principis d’arquitectura de sistemes d’informació establerts pel CTTI, que també han de ser de coneixement i compliment obligatori, i que estan recollits en el seu Manifest Cloud.
Document de descripció de l’arquitectura (DA)
Es necessari formalitzar l’arquitectura d’una nova solució segons el format estàndard definit pel CTTI, i seguir el procediment d’ISOL impulsat per la Unitat d’Integració de Solucions.
Des de l’octubre de 2025, el CTTI ha establert l’AiDA com a eina única per presentar les descripcions d’arquitectura de noves solucions.
Es demana presentar les vistes de context i desplegament en format C4model:
No s’aprovaran DA’s que no compleixin uns mínims (apartats sense complimentar, informació inconsistent, incoherències respecte d’aquesta arquitectura de referència, comentaris sense resoldre, etc.).
Descomposició en dominis funcionals
Cal plantejar enfocaments que permetin descompondre una solució en dominis funcionals, cadascun amb responsabilitat única de les seves dades i els serveis que exposa, segons un enfocament Domain Driven Design.
Cada domini ofereix una abstracció del seu coneixement respecte de la resta, mitjançant una API d’operacions o una integració asíncrona.
No es permeten interaccions ni acoblaments entre diferents dominis a nivell de base de dades, ni tampoc es permet compartir una mateixa base de dades a mode de monòlit. D’aquesta manera, es pretén evitar possibles punts de fallida únics amb afectació a tot el sistema.
Model de desplegament en el núvol
Les diferents iniciatives o dominis funcionals han de presentar una arquitectura desacoblada entre presentació, negoci i dades. Els components de presentació i negoci han de permetre un desplegament basat en contenidors, que permetin elasticitat i autoescalat segons demanda, i també l’actualització o la substitució d’un component de forma autònoma, sense afectar tot el producte.
Totes les capes de l’arquitectura han d’oferir:
-
Alta disponibilitat multizona: amb una distribució balancejada dels recursos en diferents ubicacions, per oferir robustesa i resiliència davant d’una possible caiguda o fallida d’una ubicació única.
-
Autoescalat horitzontal o vertical de recursos configurable segons demanda, per optimitzar costos mitjançant la facturació per consum en temps real, en lloc del pagament per reserva fixa.
Per assegurar el compliment d’aquests dos requeriments, cal desplegar els components de la solució en hiperescalars de núvol públic prioritzant les solucions menys gestionades (SaaS, CaS) i únicament sota una excepció les d’autogestió (PaS, IaS) com indica el Manifest Cloud.
En aquest escenari, el proveïdor d’aplicació és responsable únic de la configuració, instal·lació i monitoratge end-to-end del sistema aprovisionat, i de garantir que no esdevenen costos inesperats per una mala definició de la infraestructura com a codi de la solució.
Arquitectura de frontals web
Tots els nous desenvolupaments de frontals web hauran d’estar basats en el framework Angular. Només es permetrà l’arquitectura de microfrontals (preferentment SPAs).
Les característiques de microfrontals inclouen:
-
S’ha desplegar incloent únicament les funcions pròpies de la capa de presentació.
-
S’ha de prioritzar el desplegament d’aplicacions SPA amb desplegament estàtic a serveis de CDN de cloud natiu per optimitzar la descàrrega, alliberar recursos computacionals, incrementar la disponibilitat i facilitar l’accés.
-
En cas que existeixin ja mòduls ja desenvolupats de funcionalitats transversals (web components) s’hauran de prioritzar sobre solucions personalitzades o pròpies (exemples: mòdul d’avisos, mòdul d’agenda).
-
Els frontals han de garantir i gestionar la capa de seguretat de client per la comunicació amb el backend i assegurar compatibilitat amb GICAR, VALID i ePortal.
-
Es poden utilitzar llibreries de regles (BRMS) com Corticon.js per gestionar petites validacions de negoci o per funcionalitats offline.
-
Tots els frontals han de complir amb la normativa d’accessibilitat i internalització de les llengües oficials a Catalunya.
Pels components gràfics pels microfrontals web cal seguir el Sistema de Disseny de DSI.
Arquitectura de components de negoci
Establim per defecte una arquitectura basada en microserveis, on es preveuen les tecnologies següents:
-
Java: SpringBoot, openjdk.
-
Node/Javascript (prioritació per FaaS i/o APIs).
-
Python (Analítica i IA).
Un mateix microservei no hauria d’operar amb diferents motors de bases de dades concurrentment. En cas estrictament necessari: la solució ha d’oferir una recuperabilitat consistent i coordinada de les dades en aquests diferents motors, de manera que la possible pèrdua i restauració d’una BD no causi una descompensació amb les altres.
Els microserveis han d’oferir mecanismes de publicació de mètriques (del contenidor o pròpies de negoci) que permetin realitzar l’observabilitat del sistema. Utilitzarem Prometheus com estàndard d’exposició de mètriques, i l’agregació d’aquestes mètriques ha d’estar basada en Open Telemetry en desplegaments en el núvol públic.
Cal incorporar mecanismes de Feature Toggles que permetin activar o desactivar serveis o operacions dinàmicament, sense requerir un canvi de configuració que suposi un reinici dels contenidors.
Interoperabilitat entre dominis funcionals o solucions
Com a mecanismes d’interoperabilitat entre diferents sistemes d’informació contemplarem:
-
Interacció síncrona: basada en la publicació de serveis exposats pel microservei, en forma d’API REST sobre protocol HTTPS. La implementació del component que exposa l’API ha de possibilitar la generació de la documentació d’aquesta com a codi, segons l’especificació OpenAPI 3. Tota interoperabilitat ha de ser integrada en la plataforma de API Manager de DSI (iSocial) i en cas d’exposició pública també a la API Manager transversal.
-
Interacció asíncrona:
- Configuració per cues: En sistemes on no disposem de controls d’esdeveniments utilitzarem cues de missatgeria. Per les cues serà requerit fer servir sistemes escalables de cloud públic per aplicacions natives al núvol i la plataforma iSocial per les aplicacions on-premise.
- Configuració per esdeveniments: Basada en incorporar en els microserveis un sistema de publicació i subscripció d’esdeveniments en tòpics de missatges sota uns esquemes definits, seguint un enfocament Event Driven Design. El Departament està desenvolupant Octotòpic, un sistema d’intercanvi de missatges asíncrons a través d’EventHub que serà el referent en aquest tipus de comunicacions.
-
Integració per frontend: prioritzarem la creació de components web (web components) que consumeixen serveis de negoci amb requeriments de seguretat i d’autorització específics entre aplicacions.
Bases de dades operacionals
Establim MongoDB Atlas com a motor de base de dades de referència, per qualsevol nova iniciativa en construcció. La cadena de connexió ha d’utilitzar sempre adreçaments privats hostatjats en el proveïdor de núvol públic, evitant l’accés a les dades directament per Internet.
En el cas de necessitar una base de dades relacional (per requeriments justificats de caire tecnològic o funcional de la solució, i amb la corresponent aprovació d’Arquitectura), el motor de referència preferible ha de ser Postgresql (excepcionalment Oracle) sota un model que compleixi les característiques d’alta disponibilitat multizona, PITR (point-in-time recovery), i RPO (recovery point objective) / RTO (recovery time objective) complint els requeriments definits per negoci.
Bases de dades en memòria
Com a bases de dades en memòria (per persistència de dades de sessió web, o magatzems en caché de dades de consulta recurrent) cal anteposar l’ús de solucions ja gestionades pel proveïdor de núvol públic on es desplega el sistema.
En cas de requerir una solució a mida, establim Redis com a motor de referència amb una configuració que compleixi amb els requeriments de RTO i RPO expressats en els requeriments de la aplicació.
Aprovisionament de productes gestionats i administrats
Sempre cal donar preferència a productes gestionats i administrats pel propi proveïdor de núvol públic o solucions SaaS, davant de solucions implementades a mida, per evitar la configuració i l’operativa manual d’aquests:
-
En el cas de contenidors: solucions gestionades i administrades en la capa de control-plane i l’aprovisionament de nodes: com ECS o EKS en modalitat Fargate, AKS o Container Apps, GKE,…
-
En el cas de base de dades: un servei gestionat com MongoDB Atlas en cas d’un motor no-relacional, o un RDS Aurora Postgres o Azure Database Postgres al núvol en cas de motor relacional i Elastic Cloud en cas de motor de cerca textual.
Components transversals de Drets Socials
Les solucions han d’integrar-se amb els principals sistemes estratègics tecnològics de Drets Socials, en lloc d’implementar solucions a mida:
wSocial Seguretat
Plataforma de gestió d’usuaris i perfils de l’ecosistema d’aplicacions de Drets Social i Inclusió.
WSocial Observabilitat
Plataforma de recollida d’esdeveniments, traçabilitat i auditoria de les aplicacions del ecosistema eSocial.
tSocial
Plataforma de gestió de tràmits d’expedients administratius.
iSocial
API Gateway de Drets Socials i Inclusió encarregat de gestionar les interoperabilitats de tipus API i SOAP i porta d’accés a serveis de la Generalitat. També pot gestionar cues per intercanvi asíncron.
kSocial
Aplicació que administra i proporciona el vocabulari i el catàleg de serveis unificat de Drets Socials i Inclusió.
Mòdul d’agenda
Agenda transversal al ecosistema eSocial.
Mòdul d’avisos
Sistema gestor dels avisos funcionals per les aplicacions.
BRMS
Gestor de regles de negoci de Drets Socials i Inclusió.
BMP
Gestor de modelatge de processos i orquestrador de flux.
Octotopic
Gestor d’esdeveniments i missatges desplegat sobre una solució Confluent (sota Apache Kafka i Apache Flink).
VidSigner
Per als serveis de signatura electrònica segura s’utilitzarà el component Vidsigner de Validated ID que combina criptografia i biometria per signar documents legalment, tant presencialment com remotament. S’integra fàcilment a gestors documentals i als backoffice del Departament.
Components transversals del CTTI
Les solucions han d’integrar-se amb els principals components tecnològics del CTTI, en lloc d’implementar solucions a mida:
Plataforma Kafka Eventhub
Com a broker per implementar comunicacions asíncrones entre sistemes d’informació, sobre tòpics amb un model d’autorització basat en MTLS i un registre d’esquemes basat en JSON, AVRO o altres models de serialització de missatge.
Api Manager CTTI
Plataforma corporativa de publicació i gestió d’APIS, segons un model de subscripció a aquestes basat en credencials pròpies del producte o integrat amb la Plataforma de Seguretat. A nivell públic.
Plataformes de CI/CD
És obligatori utilitzar els sistemes corporatius de desplegament i d’integració contínua del CTTI:
-
SIC per a desplegaments en núvol privat o Api Manager.
-
SIC+ per a desplegaments al núvol públic.
PTD
Eines i solucions de la plataforma transversal de dades.
Migració de dades
Les migracions de dades entre aplicacions han d’anar en concordança amb el sistema on migrem la informació. Valorarem fer servir sistemes gestionats, evitant la creació d’infraestructura redundada i fent servir sempre que sigui possible eines especialitzades per la migració.
Per cloud públic (exemple AWS o equivalents a altres proveïdors) eines com:
- AWS Database Migration Service
- AWS Migration Service
- AWS Migration Hub
- AWS Migration Hub Refactor Spaces
I a nivell intern eines com:
- Eventhub (Confluence connectors)
- Mongo ATLAS
- API Manager (per interconnexions)
S’evitarà sempre que sigui possible l’ús de sistemes no especialitzats (SFTP) o solucions personalitzades (migració CSV, binaris, etc.) i l’ús d’aquestes solucions ha d’estar justificat tant per Arquitectura com per negoci quan no sigui possible una alternativa per limitacions tècniques o funcionals.
Consideracions en la capa de networking
Cal ajustar-se al model de connectivitat i seguretat perimetral de NUS i CTTI en el que es coneix com a projecte de “NET0”: rangs d’adreçament CIDR enrutables respecte rangs no enrutables, proxies de sortida a internet i servidors DNS en cada proveïdor de núvol públic, tallafocs i regles de seguretat d’aplicació i web, encaminaments de tràfic segons domini Internet respecte domini Intranet, etc.
Tota comunicació híbrida entre sistemes desplegats on-premises o núvol privat i components en el núvol públic ha de ser mitjançant el corresponent hub and spoke (Transit Gateway, Express Route,…) per línia dedicada connectada a la NET0.
Cloenda
Aquestes directrius tenen l’objectiu de garantir una arquitectura escalable, moderna i coherent en tots els nostres sistemes, essent d’obligat compliment. Us agrairem que tingueu en compte aquestes pautes per a qualsevol nova licitació, projecte o actualització.
Per a qualsevol dubte o aclariment, no dubteu a posar-vos en contacte amb nosaltres mitjançant el correu de la Bústia d’Arquitectura de Drets Socials i Inclusió.