Plana web per ajudar a l’emplenat de la plantilla del document d’arquitectura, els següents apartats són accessibles des de la pròpia plantilla.
Explicar quin es el propòsit del Servei o Sistema d’Informació definit al DA i quines necessitats cobreix/cobrirà l’aplicació dintre del Departament u Organisme responsable.
Exemple
El propòsit, en el cas d’haver de redactar el DA de Microsoft Outlook, seria “Gestionar les bústies de correus dels usuaris”.
Indicar, relacionat amb el punt anterior, com el Sistema d’informació donarà servei o cobrirà la necessitat indicada en el punt anterior. S’ha d’explicar, a grans trets, com serà aquest sistems d’informació e identificar els consumidors d’aquest Sistema.
Directrius
En aquest punt ha de quedar clar que es fa per aconseguir l’objectiu i quins son els consumidors de l’aplicació o servei (Interns Gencat, Col·laboradors Externs o Públics).
Llistats dels requeriments/necessitats fonamentals que ha de cobrir l’arquitectura de la solució/servei. Son els punts que condicionaran tota l’arquitectura.
Exemple
Informar els requisits que tenen en compte aspectes de la solució fora de la seva funcionalitat i que son importants o rellevants per l’arquitectura.
Identificar i descriure les parts interessades per a l’arquitectura. S’han d’informar totes les parts que estan involucrades ja no en la confecció del document, si no amb el servei.
Exemple
Directrius o requeriments a l’hora de realitzar el diagrama:
Definir les dependències del servei que es detallen al DA. Tant d’entrada com de sortida, tot explicant el tipus de comunicació entre aquestes dependències i el sistema d’informació. Caldrà tenir en compte sempre les eines transverals existents a la Generalitat. Si una solució transversal pot cobrir aquestes dependències, aquesta eina transversal haurà de ser l’escollida.
Caldrà també que aquestes dependències no siguin realment acoblaments entre aplicacions. Si fos així, aquestes dependències haurien de substituir-se per serveis. Cal que el CPD de cada sistema estigui informat.
Enumerar els diferents actors que apareixen al diagrama de context i detarllar-ne la descripció d’aquests. A més, caldrà explicar com s’autentiquen al Sistema.
Exemple
Directrius o requeriments a l’hora de realitzar el diagrama
Detallar quina es l’estrcutura interna de l’aplicació. Segons el principi d’arquitectura 1.1, les aplicacions han d’estar segregades per funcionalitat/responsabilitat per evitar monolits. Detallar en aquest punt quina es aquesta estructura interna de l’aplicació.
Directrius
Ha d’estar contestat i que tingui sentit amb els punts “Finalitat i ús de les dades (RGPD)” i “Nivell de RGPD assignat al fitxer”.
Ha d’estar contestat i que tingui sentit amb els punts “Dades de caràcter personal” i “Nivell de RGPD assignat al fitxer”.
Ha d’estar contestat i que tingui sentit amb els punts “Dades de caràcter personal” i “Finalitat i ús de les dades (RGPD)”.
Quines dades es consideren Bàsiques:
Quines dades es consideren Especialment protegides:
MOLT CRÍTIC: La informació és altament confidencial, accessible per un nombre molt restringit d’individus, amb requeriments d’integritat, autenticitat i traçabilitat molt alts? (exemples: dades de Seguretat Pública, informació policial, gestió de claus criptogràfiques, etc.)
CRÍTIC: La informació és confidencial, restringida a un cercle reduït d’individus, amb requeriments de xifrat i traçabilitat dels accessos?
Exemples
Gestió de centres penitenciaris, eleccions, gabinets jurídics, subvencions, contractacions, plataformes transversals de suport a la tramitació, actuació de cossos d’emergències, inventari d’infraestructures crítiques, plans de protecció civil, etc.
SENSIBLE: La informació és restringida a àrees o unitats amb requeriments avançats de control d’accés i garanties d’integritat i autenticitat?
Exemples
Registre de ciutadans amb dades acadèmiques, sistemes de gestió de personal, llistes de col·lectius, la divulgació de les quals podria tenir repercussió política, registres d’empreses amb informació reservada, gestió de dades pressupostàries i econòmic-financeres, gestió del deute, sistemes d’ anàlisi de dades: estadístiques de serveis/operativa i quadres de comandament, actuacions de cossos operatius de la Generalitat (exceptuant els d’emergències), gestió de flotes d’emergència, tràmits de pagament on-line, tràmits electrònics i portals de tràmits, auditories, gestió de riscos, plans de continuïtat de negoci, assistència jurídica, gestió de la publicació d’informació (previ a la publicació).
INTERN: Hi ha informació no crítica on es pot permetre una lleu pèrdua d’integritat e informació?
Exemples
Intranets departamentals, plataformes col·laboratives, fòrums, blogs, registres de professionals, convocatòries, concursos de personal, oposicions, usuaris d’aplicació, assistents a cursos, entrada/sortida de documents, gestió d’inventaris, qüestions parlamentàries, plecs, plans d’actuació, gestió de compres, consultes i suggeriments, queixes sense dades sensibles, infraestructures, expedients sense informació anterior, etc.
PUBLIC: La informació és pública sense restriccions de difusió del contingut.
Indicar el temps requerit de retenció de la informació per motius legals o anàlisis històric. En el cas d’escollir l’opció “Altres” cal tenir en compte que s’haurà de pactar amb CPD.
Identificar els tipus de bases de dades utilitzats. En cas d’escollir més d’un tipus de base de dades caldrà especificar per a que es fa servir cada tipus de base de dades. Les dades descrites en aquest punt han de quadrar amb la Vista de Desplegament (2.6)
Permet justificar l’estimació de tamany a la vista de desplegament. Tot i tractar-se d’una valoració aproximada o estimativa, la resposta a aquest punt ha de ser resultat d’una reflexió prèvia. No es demana un número sense més, si no producte d’una estimació bassada en un anàlisi encara que sigui a alt nivell.
Diagrama de les principals entitats de dades del servei o solució.
En cas de fer servir entitats de referència, enumerar aquelles que en fa ús el servei/solució. Llistat de les entitats identificades.
Diagrama de Flux de la informació.
Estimar quants usuaris poden accedir simultàniament al sistema d’informació
Validar que la proposta per administrat les tasques o procesos batch permeti monitoritzar la seva correcta execució. No serveix una execució amb Cron que no dona cap garantia d’execució.
Directrius
Aquest es el punt per informar sobre aquests processos. No pot aparèixer a cap altre punt del DA. Si això passa, remetrem a que s’informi aquí.
Detallar quines tecnologies s’utilitzen per cada una de les capes.
Directrius
Identificar aquelles llibreries que no estan en un repositori confiable.
Informació del repositori on es pujarà el codi font i detalls respecte als artefactes a desplegar al GitLab. Ha d’esser un (com a mínim) d’aquests. Es pot donar el cas que el codi estigui a un repositori general i que també estigui en un altre dels repositoris.
Directrius
S’ha de proporcionar tota la informació necessària per agilitzar al màxim la integració des de Suport SIC.
La integració amb el SIC, si no es així caldrà donar d’alta una excepció d’arquitectura, excepte en el cas de tractar-se d’un producte comercial en comptes d’un desenvolupament a mida.
S’ha d’informar obligatòriament.
Cal que cadascuna de les tecnologíes estigui aquí enumerada i justificada la seva utilització.
Exemple
Afegir diagrames que ajudi a entendre quina es l’arquitectura de la infraestructura.
Directrius
Cal que estigui informat i son clarament identificables tots els elements indicats a les taules d’aquesta mateixa vista. Si els esquemes de PRE i PRO son diferents, s’han de presentar dos diagrames.
S’ha de crear una taula com la de la plantilla per cada un dels entorns que formen part del servei. Aquesta taula es farà servir per a les instàncies on-premise.
Detall de cada un dels camps de la taula:
Element | Descripció |
---|---|
Identificador d’instància | Identificador únic que se li dona a aquella instancia dintre del document d’arquitectura, aquest identificador s’utilitzarà després per referenciar la instancia a la taula d’emmagatzematge i a l’apartat 4.4 on s’ha d’identificar quins servidors / instancies són noves, quines han tingut canvis o quines són compartides amb altres serveis / solucions del departament. |
Tipus de Servei | PaaS IaaS Hosting |
Programari i versió | Nom del programari i versió que s’instal·la. Ha d’estar alineat amb el full de ruta del programari. En cas de sistemes/serveis nous, caldrà que les versions siguin les actuals segons el Full de Ruta del CTTI. |
Talla i recursos adicionals | Indicar la talla de la instancia segons la següent taula i especificar si es necessari afegir algun recurs addicional com pot ser vCPUs o Gb de ram. |
Nivell de Servei | Continu - A - 2h 24x7 Continu - STD - 1d Laboral - B - 4s |
Detall de cada un dels camps de la taula:
Element | Descripció |
---|---|
Identificador d’Instància | Per relacionar la taula d’elements de catàleg cloud amb el disc addicional es fa us d’aquest camp, ha de coincidir amb l’identificador de la instancia que se li ha donat a la taula anterior. |
Tipus de disc {#TipusDisc} | Blocs - Aquest tipus d’emmagatzematge està especialment pensat per quan es necessita una capacitat de disc dur en brut, com per exemple, espai per a una BBDD Oracle. Fitxers - Aquest tipus d’emmagatzematge està especialment pensat per quan l’usuari necessita accés a una carpeta compartida de fitxers. |
Mida del disc | Indicar la mida en GB del disc adicional necessari per la instancia indicada al camp “Identificador d’Instancia”. |
Tier - Nivell de disc {#NivellDisc} | Alt rendiment (TIER 1): Dades d’alta criticitat, fitxers que s’accedeixen sovint, etc. Mig rendiment (TIER 2): Fitxers que no s’accedeixen gaire sovint. Alta Capacitat (TIER 3): Copies de seguretat. |
RTO i RPO {#RTORPO} | RTO: 2 hores / 8 hores / 12 hores RPO: RPO Zero (No pot perdre cap transacció) / RPO Darrer Backup / |
Taula on es detalla la informació relativa als contenidors que formen part del servei.
Detall de cada un dels camps de la taula:
Element | Descripció |
---|---|
Identificador d’instància | Identificador únic que se li dona a aquella instancia dintre del document d’arquitectura, aquest identificador s’utilitzarà després per referenciar la instancia a l’apartat 4.4 on s’ha d’identificar quins servidors / instancies són noves, quines han tingut canvis. |
Nombre de Pods / Contenidors | Un POD es la unitat mes petita a crear a Kubernetes, en la majoria dels casos un POD equival a un contenidor, en aquest camp s’ha d’indicar el nombre de pods a crear del tipus que es detalla a la resta de camps de la taula. |
Programari i versió / Imatge Docker | Nom del programari i versió que s’instal·la. Ha d’estar alineat amb el full de ruta del programari. Si es fa ú d’una imatge Docker ja existent al repositori oficial, indicar el seu nom. |
Memòria Ram i/o recursos addicionals | Memòria Ram assignada al Pod / Contenidor. En algunes plataformes de cloud es requereix altre tipus de dades de recursos addicionals, per exemple CPU. |
Disc Persistent | Indicar si es necessari o no disc persistent, en cas afirmatiu s’ha d’informar de la mida del disc en Gb. |
Administrat per CPD | Indicar si el Pod / Contenidor es administrat per part del proveïdor de CPD o no disposa d’administració. |
En aquest cas, s’haurà d’informar també la taula amb el total de recursos (RAM i CPU) per al global del Namespace.
Per remetre la informació relativa a instàncies aprovisionades en cloud públic, ja sigui en format Gestionat o No Gestionat, caldrà afegir l’export de la calculadora, no per cap control de tipus pressupostari, si no per tenir l’enumeració dels elements contractats.
Element | Descripció |
---|---|
Tipus de Producte de Power Platform | Marcar aquells productes de la PowerPlatform Suite involucrats a l’Arquitectura de la solució |
Nom dels entorns (SANDBOX, Production, etc.) i Grups de Seguretat | Enumerar els entorns i els grups de seguretat associat a cada entorn. Indicar a més, només en el cas que no sigui West Europe, la regió i la finalitat de cadascuan dels entorns |
Administradors dels entorns (indicar adreça de correu gencat) | Nom i correu electrònic dels administradors de cadascun dels entorns |
Requereix CDS | Indicar si requereix o no base de dades |
Si requereix CDS | Enumerar les característiques de la Base de Dades en cas d’haver contestat SI en el punt anterior |
Tipus d’aplicació de Power Platform | Model-driven Canvas Portals |
Tipus de Connectors? | Enumerar els connectors amb orígens de dades, tant si son Standard com si son Premium |
Informar de quines son les xarxes que s’utilitzen per l’acces a l’aplicació, protocol utilitzat i regles de firewall necessaries per connectar els diferents equips.
Directrius
En el cas de fer crides a serveis REST, cal fer ús de ports segurs
Verificar si el servei necessita realitzar enviaments de correus electrònics
Directrius
Principi d’Arquitectura 1.6.2 (Servidors SMTP transversals)
Informar si el servei necessita sortida a internet. Fent crides altres serveis per executar processos o obtenir informació.
Directrius
Principi d’Arquitectura 1.6.3 (Accés a internet des de xCAT)
Informar si es fan servir d’altres serveis tecnics com els protocols IMAP o POP3
Cal que cadascuna de les tecnologíes estigui enumerada i justificada la seva utilització. A més, cal indicar quins entorns hi ha (INT, PRE, PRO, FOR)
Detallar informació respecte als següents punts:
Estàndard: Diària incremental amb 2 setmanes de retenció, setmanal completa amb 1 mes de retenció, mensual completa amb 3 mesos de retenció i anual completa amb 1 any de retenció (cobrint 1 any i 3 mesos de retenció de dades)
Avançada: Diària incremental amb 1 mes de retenció, setmanal completa amb 2 mesos de retenció, mensual completa amb 6 mesos de retenció i anual completa amb 2 anys de retenció (cobrint 2 anys i 6 mesos de retenció de dades)
Especial: Diària incremental amb 1 mes de retenció, setmanal completa amb 2 mesos de retenció, mensual completa amb 12 mesos de retenció i anual completa amb 5 anys de retenció. (cobrint 6 anys de retenció de dades)
Indicar a on s’ubicarán els logs.
Directrius
Principi d’Arquitectura 2.4.4 (Nomenclatura de les infraestructures)
Cal respectar l’estandart CTTI de nomenclatura (Estandard CTTI per a la nomenclatura de les infraestructures)
Definició, si es que hi ha sondes que verifiquen el correcte funcionament del servei, de que estan controlant i que resultat s’espera per validar que el servei està funcionant correctament.
Indicar que s’han llegit i es tindran en compte les mesures de seguretat vigents a l’hora d’implementar l’arquitectura del servei/solució.
Mesures de seguretat vigents a l’hora d’implementar l’arquitectura del servei/solució:
Indicar el sistema d’autenticació que el servei fa servir per permetre l’accés a aquest
Directrius
Principi d’Arquitectura 1.6.4 (Gestió d’identitats)
En els nous serveis es obligatori la integració amb GICAR. En cas contrari caldrà excepció d’Arquitectura.
Definir quina modalitat d’integració amb GICAR s’està fent servir
Directrius
Per més detall de cada una de les modalitats consultar el Portal Canigó
Detallar en quin percentatge de consum de recursos es tenen que mantenir els servidors en un ús normal i quin es el máxim d’ús en una situació de pic.
L’aplicació està preparada per l’escalabilitat horitzontal?
Directrius
La següent taula aclara el que impliquen els diferents nivells de servei.
Horari de servei | RTO | Disponibilitat | Continuïtat | |
---|---|---|---|---|
Continu-A-2h | 24x7 | 2h | 99'90% | 2 hores |
Continu-STD-1d | 24x7 | 8h | 99'50% | 24 hores |
Laboral-B-4s | 12x5 | 12h | 95'00% | 4 setmanes |
Temps que pot estar el negoci amb el servei aturat.
Directrius
En cas d’escollir un RTO de 2 hores, totes les instàncies de l’arquitectura hauran d’estar en Alta Disponibilitat.
En cas d’incidència quin es desitja que sigui el punt de recuperació.
Laboral (12x5), Continu (24x7) o Altres (definir).
Presentar l’estudi de com afecta la indisponibilitat de les entitats externes al servei i proposar mesures per reduir o anular la seva afectació.
Directrius
No s’ha d’informar la indisponibilitat en el cas d’eines transversals (GICAR, Ironports, antivirus, etc.) si no les entitats externes indicades a la Vista de Context.
Enumerar l’idioma o idiomes que el servei ofereix.
En cas que el punt anterior sigui informat amb mes d’un idioma, explicar com es resol aquest ús.
Directrius
Aquest apartat del DA es l’únic que s’ha d’informar des del punt de vista del projecte i no des del punt de vista d’Arquitectura. Caldrà que sigui molt precís en els nous elements de la infraestructura del servei, en aquells que canvien de talla, o de versió de programari.
En el cas de tractar-se de l’evolució d’un servei ja existent, en aquest apartat s’inclourà el detall de la integració amb serveis externs que en versions anteriors del DA no existien.
Dades específiques d’integració amb el SIC que no estiguessin fetes prèviament. Entorns a gestionar per el SIC, l’organització de les branques i el detall dels artefactes que el SIC desplegarà.
Definir aquelles regles de connectivitat que no estaven d’alta fins ara. Dominis DNS dels diferents entorns i aquelles pàgines que es volen protegir mitjançant GICAR.
Ha d’estar alineat amb la vista de Desplegament, tot indicant, mitjançant l’identificador d’instancies, quines es mantenen iguals, quines canvien en les seves característiques i quines son nous aprovisionaments, doncs abans no hi formaven part de la infraestructura.