Els principis d’arquitectura CTTI són les normes i directrius generals que guien l’estratègia tecnològica i estan destinades a ser perdurables i rarament modificables i tenen com a objectiu informar i recolzar la forma en què CTTI vol que es realitzi la selecció tecnològica així com la implementació de Sistemes d’Informació.
A continuació detallem quins són aquests principis:
Des d’un punt de vista d’arquitectura empresarial, l’arbre de decisió que guiarà la selecció de tecnologia per a noves solucions es basarà en el següent:
I des de la mateixa perspectiva d’arquitectura empresarial, s’optarà sempre pel reaprofitament de solucions i plataformes existents.
1.1 Segregació de funcions/responsabilitats. Les aplicacions han d’estar estructuralment dividides en blocs independents per funcionalitats, processos de negoci o serveis, per tal d’evitar els monòlits.
Aquest principi és d’aplicació a totes les capes. Una aplicació tipus pot dividir-se fàcilment, per exemple, en els següents mòduls:
1.2 Des del moment del disseny l’Arquitectura ha de ser desacoblada per permetre als components i aplicacions mantenir-se completament autònoms i independents.
1.3 Arquitectura orientada a serveis. Les aplicacions poden ser consumides externament (exposant la seva funcionalitat) o bé han d’integrar-se amb aplicacions de tercers. Les relacions s’han de dur a terme mitjançant patrons síncrons o asíncrons segons el cas (APIs REST, Event Driven, …).
1.4 Model de qualitat, a l’hora de dissenyar un sistema cal incorporar aspectes qualitatius al cicle de vida, per més informació visitar el Portal de Qualitat.
1.5 El cicle de vida serà automàtic, tant de les aplicacions (Integració contínua - CI/CD) com de la infraestructura (Infraestructura com a Codi - IaC), així com la custòdia de codi que es farà als repositoris de la Generalitat.
1.6 Solucions transversals. Es prioritzarà la utilització de solucions transversals en lloc de fer solucions a mida. S’ha d’evitar desenvolupar les funcionalitats que ja estan disponibles.
A continuació es detallen algunes de les solucions transversals més esteses:
1.6.1 Ús del framework Canigo. Per aplicacions JEE s’ha de fer ús del Framework Canigó.
1.6.2 Servidors SMTP transversals, utilitzar els servidors SMTP transversals (IronPort) com servidor SMTP per enviar correus des de les aplicacions. Manual per a la integració SMTP
1.6.3 Accés a internet des de xCAT, per accedir a recursos internet des de servidors ubicats a la xarxa XCAT, és necessari utilitzar el ProxyPass, mai accedir directament a internet.
1.6.4 Gestió d’identitats, les aplicacions han d’autentificar els usuaris tenint en compte els següents models:
1.6.5 Sistema de gestió del document electrònic (SGDE), proporciona als Sistemes d’Informació, les principals funcions necessàries per al tractament i transformació del document electrònic, per tal de donar suport a l’intercanvi fiable i segur de documents i informació entre els ciutadans i la Generalitat de Catalunya.
1.6.6 Gestor de continguts web (GECO+), permet crear i mantenir continguts i portals d’internet mitjançant un conjunt de peces i serveis comuns (framework).
1.6.7 PICA - Plataforma d’interoperabilitat (PICA). Plataforma que permet l’accés a informació dels organismes de la Generalitat i altres administracions públiques i institucions, el consum de serveis comuns de tramitació, la integració entre els Sistemes d’Informació departamentals i la plataforma de tramitació corporativa. Tot sota criteris d’estandardització, rapidesa, senzillesa, seguretat i legalitat.
1.6.8 Tramitador d’ajuts i subvencions (TAIS). Sistema d’informació per a la gestió electrònica d’expedients de gestió de subvencions.
2.1 Continuïtat tecnològica. Per a facilitar la segregació de responsabilitats i mantenibilitat de les aplicacions es proposa desacoblar frontend i backend, així com exposar la lògica necessària mitjançant serveis (REST principalment)
2.2 Estabilitat de les versions de programari. Les versions de les diferents peces (productes, llibreries…) que composen un sistema han de ser el més estables possible. S’ha de fer ús de versions LTS (Long-Term Support) o bé, o en la seva mancança, la GA (General Availability) o la nomenclatura que hagi donat el fabricant com a estable. Un sistema productiu no pot incorporar versions no consolidades (snapshot, alpha, beta, release candidate, milestone…) dels components que en formin part.
2.3 Interoperabilitat. S’ha de garantir l’intercanvi d’informació i dades entre sistemes, amb patrons síncrons o asínrons, i aquest es farà preferentment amb les plataformes corporatives orientades a aquest ús: API Manager i EventHub/Kafka.
2.4 Els estàndards de qualitat definits pel CTTI són aplicables al desenvolupament, manteniment i ús de les solucions TI de la Generalitat de Catalunya.
A continuació es llisten els relacionats amb els principis d’arquitectura:
2.5 Ús de Cloud Públic. S’ha de plantejar l’ús de cloud públic preferentment vs l’ús d’entorns d’execució onpremise.
2.6 Ús de protocols segurs per a les aplicacions publicades, així com d’altres mecanismes per a evitar atacs de DDoS, SQL Injection, Cross Site Scripting i d’altres. També s’ha de valorar per a aplicacions crítiques l’encriptat de dades en repòs.
2.7 Mateixa arquitectura per Preproducció i Producció. Per a què les proves fetes a preproducció tinguin validesa, és necessari que els entorns de preproducció i producció siguin idèntics pel que fa al disseny, encara que els recursos assignats a preproducció siguin inferiors. En aquest cas, l’ús de cloud públic i infraestructura com a codi facilitarà la replicabilitat i equivalència d’entorns.
3.1 Optimització de costos, pensar en els costos i en la seva optimització, sobretot ajustant el recursos necessaris, establint polítiques d’escalat i utilitzar serveis que es puguin apagar quan no s’usen.
3.2 Benefici màxim al menor cost i risc possible. Cal tenir presents els costos d’infraestructura i el model de llicenciament requerits per a posar en marxa una solució, ja que representen un cost recurrent. A l’hora de concebre una solució s’ha d’identificar quin tipus de llicenciament serà el millor per la solució desitjada. Quan s’escull un producte (opensource o comercial) en modalitat SaaS, es tria construir amb plataformes LowCode, o bé s’acaba decidint fer un desenvolupament a mida, cal fer una avaluació del cost vs. benefici de l’opció triada respecte a les altres:
3.3 Impacte d’actualització, pensar en l’impacte d’actualització que pugui tenir un canvi de sistema operatiu, middleware o producte allà on s’executa l’aplicació: quant menys acoblament amb el sistema de base i més utilització d’estàndards existeix, més senzilla serà l’actualització o l’ampliació de funcionalitats de l’aplicació. Per exemple, containeritzar les aplicacions per a aïllar-les de l’entorn d’execució i incloure-hi les seves dependències a l’artefacte.