Aneu al contingut principal
FromNine
Menú

Programari i núvol

Programari empresarial que els vostres equips poden continuar canviant.

Desenvolupem productes SaaS, portals per a la ciutadania i el personal i aplicacions de negoci centrals que són accessibles, segurs per defecte i que els vostres propis equips poden mantenir molt després del llançament.

Per a empreses de producte i organismes públics que donen servei a persones usuàries de diversos països, llengües i règims jurídics.

Parlem del vostre projecteModernització de sistemes
Programari empresarial i SaaS: capes de capacitatsQuatre capes apilades en profunditat. De dalt a baix: la interfície accessible que fan servir les persones, els mòduls de domini que contenen les regles, els serveis de plataforma per a l’arrendament múltiple i la identitat, i a sota la cadena de lliurament segura.01Interfícies accessibles02Mòduls de domini i regles03Arrendataris, identitat, dades04Cadena de lliurament segura
  1. 01Disseny guiat pel domini per a feines amb moltes regles, com la tramitació d’expedients
  2. 02Accessibilitat segons l’EN 301 549 i les WCAG 2.2 AA des del primer disseny
  3. 03Documentació i registres de decisions que els vostres equips poden assumir

01 Problemes

Què sentim abans d’una reconstrucció

  1. 01

    Cada canvi triga un trimestre

    L’aplicació funciona, però ningú no s’atreveix a tocar-ne el nucli. Els canvis petits demanen proves de regressió grans i una finestra de publicació.

  2. 02

    El portal falla a les persones a qui dona servei

    No funciona amb un lector de pantalla, en la segona llengua oficial o al mòbil. Les queixes arriben abans que l’auditoria d’accessibilitat.

  3. 03

    El canvi d’un client trenca el d’un altre

    El producte SaaS ha crescut a base de personalitzacions per a cada client. Ara cada versió és una negociació i alguns arrendataris s’han quedat encallats en versions antigues.

  4. 04

    El coneixement se’n va anar amb el proveïdor

    Les decisions no es van escriure mai. L’equip que el va construir ja no hi és, i el codi és l’única documentació.

  5. 05

    Clients i reguladors fan preguntes de seguretat

    L’equip de compres demana una SBOM, un procés de gestió de vulnerabilitats i evidència per al Reglament de ciberresiliència. Ningú no ho té preparat.

02 Què lliurem

Què lliurem

  1. 01 Enginyeria de productes SaaS

    Productes pensats per servir molts clients des d’un sol codi: el model d’arrendament múltiple adequat, configuració en lloc de personalització i versions que arriben a tots els arrendataris.

    Què fem

    • Elecció del model d’arrendament: compartit, agrupat o aïllat per arrendatari
    • Estratègia de configuració i d’indicadors de funcionalitat
    • Integració de la mesura de l’ús i de la facturació
    • Cicles de llançament amb desplegament per arrendatari

    Què rebeu

    • Disseny de l’arrendament múltiple i de l’aïllament
    • Model de configuració amb límits
    • Procés de llançament amb reversió per arrendatari

  2. 02 Disseny de domini per a regles complexes

    Disseny guiat pel domini quan les regles són el producte: tramitació d’expedients, requisits d’accés a ajuts, càlculs molt regulats. Triem de manera deliberada entre un monòlit modular i microserveis, i gairebé sempre comencem pel primer.

    Què fem

    • Sessions d’event storming amb especialistes del domini
    • Contextos delimitats i fronteres entre mòduls
    • Regles fetes explícites i comprovables
    • Registres de decisions d’arquitectura per a les grans eleccions

    Què rebeu

    • Model de domini i mapa de contextos
    • Codi modular amb fronteres que s’apliquen
    • Especificacions executables per a les regles clau

  3. 03 Portals per a la ciutadania i el personal

    Interfícies construïdes sobre un sistema de disseny, accessibles per defecte i multilingües des de la primera versió. A Catalunya això vol dir normalment el català i el castellà; en altres llocs, les llengües que parlen de debò les vostres persones usuàries.

    Què fem

    • Sistema de disseny amb components accessibles
    • Disseny de continguts en llenguatge planer
    • Proves amb tecnologies de suport i persones usuàries reals
    • Flux de localització per a cada llengua

    Què rebeu

    • Portal sobre un sistema de disseny reutilitzable
    • Informe de conformitat d’accessibilitat
    • Flux de continguts i traducció

  4. 04 Enginyeria de qualitat i desenvolupament segur

    Automatització de proves als nivells adequats, proves de contracte entre serveis, proves de rendiment abans del llançament i un cicle de desenvolupament segur basat en l’OWASP ASVS, les SBOM i els controls de la cadena de subministrament.

    Què fem

    • Estratègia i automatització de proves
    • Proves de contracte i de rendiment
    • Modelatge d’amenaces i verificació ASVS
    • Generació de SBOM i política de dependències

    Què rebeu

    • Bateries de proves automatitzades a la cadena
    • Informe de verificació de seguretat
    • Procés de gestió de vulnerabilitats preparat per al Reglament de ciberresiliència

  5. 05 Modernització incremental

    Substituïm una aplicació heretada funcionalitat per funcionalitat, darrere d’una façana d’enrutament, mentre l’activitat continua. Vegeu també la modernització de sistemes heretats.

    Què fem

    • Mapa de capacitats de l’aplicació existent
    • Enrutament de tipus strangler fig i encapsulament amb API
    • Migració de dades amb informes de conciliació
    • Execucions en paral·lel per als càlculs crítics

    Què rebeu

    • Seqüència de modernització amb fites de negoci
    • Façana i mòduls nous en producció
    • Dades conciliades a cada canvi de sistema

  6. 06 Mantenibilitat i traspàs

    Programari que els vostres equips poden fer seu: codi llegible, registres de decisions, procediments operatius i un pla de traspàs acordat al principi, no descobert al final.

    Què fem

    • Programació en parella amb els vostres desenvolupadors durant la construcció
    • Registres de decisions d’arquitectura mantinguts amb el codi
    • Procediments operatius i guies de guàrdia
    • Fites de transferència de coneixement

    Què rebeu

    • Pla de traspàs amb criteris d’acceptació
    • Documentació als vostres repositoris
    • Equip intern format

03 Arquitectura

Una arquitectura de referència il·lustrativa

Una forma habitual per a una aplicació de negoci que en substitueix una altra de més antiga: una interfície accessible, una façana d’enrutament que envia cada funcionalitat al sistema antic o al nou, una capa d’API amb contractes clars i un nucli modular organitzat al voltant del domini.

L’arrendament múltiple i la configuració són serveis de plataforma explícits, no condicions escampades pel codi. A sota, cada compilació executa proves i controls de seguretat i genera una SBOM.

Capes del dibuix

Persones
Ciutadania, clients i personal, amb qualsevol dispositiu i amb tecnologies de suport.
Modernització
La façana d’enrutament, l’aplicació existent i la migració de dades amb conciliació.
Plataforma
Capa d’API, identitat, el nucli modular, arrendament múltiple i configuració, dades operatives.
Lliurament segur
Proves de contracte i de rendiment, controls ASVS i una SBOM a cada compilació.
Exemple il·lustratiu

  1. Persones

    • Ciutadania, clients, personal
    • Interfície accessible

  2. Modernització incremental

    • Façana d’enrutament
    • Aplicació existent
    • Migració amb conciliació

  3. Plataforma

    • Capa d’API i contractes
    • Identitat i rols
    • Nucli modular: entrada, expedients, facturació
    • Arrendataris, configuració, indicadors de funcionalitat
    • Magatzems de dades operatives

  4. Lliurament segur

    • Proves de contracte i de rendiment, controls ASVS, SBOM a cada compilació
Un nucli modular darrere d’una façana d’enrutament

Arquitectura il·lustrativa, no el sistema d’un client.

Llegiu el diagrama en format de text

El recorregut principal va de les persones a una interfície accessible i, a través d’una façana d’enrutament i una capa d’API, fins a un nucli modular organitzat en contextos delimitats.

La façana també envia algunes funcionalitats a l’aplicació existent, que es retira pas a pas. Les seves dades passen per una migració amb conciliació cap als magatzems de dades operatives.

La identitat dona servei a la capa d’API. Els serveis d’arrendament múltiple i de configuració són sota el nucli. A sota de tot, una franja de lliurament segur cobreix les proves de contracte, les proves de rendiment, la verificació de seguretat i les SBOM.

04 Consideracions i límits

Consideracions d’enginyeria i límits

  • Primer, un monòlit modular

    Com ho abordem

    Comencem amb mòduls clars en una sola unitat desplegable i només en separem serveis quan l’escalat, el ritme de publicació o la responsabilitat dels equips ho demanen.

    Límits i dependències

    Els microserveis resolen problemes organitzatius tant com tècnics. Sense equips que se’n facin càrrec, afegeixen cost i maneres de fallar.

  • L’accessibilitat és feina d’enginyeria

    Com ho abordem

    Components accessibles, comprovacions automàtiques a la cadena i proves manuals amb tecnologies de suport abans de cada versió important.

    Límits i dependències

    Les eines automàtiques només troben una part dels problemes. La conformitat completa necessita auditories manuals i, idealment, proves amb persones amb discapacitat.

    Els continguts i els documents que les persones editores afegeixen després del llançament han de complir el mateix nivell. Les formem, però no controlem el que publiquen.

  • La modernització dura el que duren les dades

    Com ho abordem

    La migració de dades es planifica per funcionalitat, s’assaja i es concilia, amb l’aprovació del negoci a cada canvi de sistema.

    Límits i dependències

    La qualitat de les dades heretades sovint marca el ritme. Netejar-les és una tasca tant de negoci com tècnica.

  • Normativa per a productes de programari

    Com ho abordem

    Les SBOM, la gestió de vulnerabilitats i la configuració segura per defecte formen part de la nostra cadena estàndard, que prepara els productes per al Reglament de ciberresiliència.

    Límits i dependències

    Si el Reglament s’aplica al vostre producte, i com, és una qüestió jurídica. Nosaltres aportem l’evidència d’enginyeria; la valoració la fan els vostres assessors.

05 Com treballem

Com treballem

Cicles curts, persones usuàries reals des del principi i el traspàs planificat des de la primera setmana.

  1. 01

    Cartografiar el domini

    Sessions d’event storming amb les persones que coneixen les regles i un mapa de capacitats del que existeix avui.

    ResultatMapa de contextos i primers registres de decisions

  2. 02

    Posar en producció una primera peça

    Una funcionalitat de punta a punta, a través de la façana, en producció amb persones usuàries reals.

    ResultatPrimera peça funcionant en producció

  3. 03

    Créixer funcionalitat a funcionalitat

    Cada versió trasllada una funcionalitat, les seves dades i les seves persones usuàries, amb la conciliació i la reversió preparades.

    ResultatPla de versions per funcionalitat

  4. 04

    Fer el traspàs

    Els vostres desenvolupadors treballen en parella amb els nostres, assumeixen les guàrdies i es fan càrrec del full de ruta quan es compleixen els criteris de traspàs.

    ResultatTraspàs acceptat

06 Control humà

On les persones mantenen el control

En el programari de negoci, tenir el control vol dir saber qui ha canviat què, qui ho ha aprovat i com es desfà.

  • La persona responsable del producte decideix l’abast

    La persona responsable del vostre producte fixa les prioritats i accepta cada increment. Nosaltres aconsellem; ella decideix.

  • La configuració té una persona responsable

    Els paràmetres dels arrendataris i els indicadors de funcionalitat es canvien amb un procés auditat, per part dels rols que assigneu.

  • Els canvis de sistema s’aproven

    Cada pas del sistema antic al nou l’aprova el negoci, amb una reversió assajada.

  • Les decisions queden per escrit

    Els registres de decisions d’arquitectura mostren què es va triar, qui ho va decidir i per què, perquè els equips futurs les puguin revisar amb coneixement de causa.

07 Tecnologies

Tecnologies amb què treballem

Servidor
  • Java i Kotlin
  • .NET
  • TypeScript i Node.js
  • Python
Interfície
  • React i Next.js
  • Angular
  • Sistemes de disseny amb components accessibles
  • Aplicacions mòbils natives i multiplataforma
Dades
  • PostgreSQL
  • SQL Server i Oracle (entorns existents)
  • Fluxos d’esdeveniments
  • Motors de cerca
Qualitat i seguretat
  • Playwright i proves de contracte
  • Proves de càrrega i de rendiment
  • SAST, DAST i anàlisi de dependències
  • SBOM en CycloneDX o SPDX

Esmentar una tecnologia descriu la nostra experiència d’enginyeria. No implica cap acord de col·laboració amb el fabricant ni cap aval per part seva.

08 Exemple

Un exemple il·lustratiu

Exemple il·lustratiu

Un portal de sol·licituds compartit per un consorci de municipis

01Situació
Els ajuntaments d’un consorci fan servir formularis i portals diferents, fets per proveïdors diferents. Cadascun falla els controls d’accessibilitat d’una manera diferent, i cada canvi normatiu s’ha d’aplicar diverses vegades.
02Què construiríem
Un sol portal de sol·licituds sobre un sistema de disseny compartit, amb identificació amb Cl@ve, continguts en català i en castellà, i els tràmits, les dades i les integracions de cada ajuntament en la configuració, amb un sol cicle de versions.
03On decideix una persona
Cada ajuntament aprova els continguts i la configuració dels seus tràmits; el consorci decideix les funcionalitats compartides.
04Què mesuraríem
Problemes d’accessibilitat per versió, temps per aplicar un canvi a tots els ajuntaments i proporció de canvis fets una sola vegada en lloc de per a cada municipi.

09 Per sectors

En el vostre sector

  • Sector públic

    Gestió d’expedients i portals per a la ciutadania que compleixen la normativa d’accessibilitat, funcionen en les llengües oficials que calgui i es connecten amb els serveis comuns de les administracions, com Cl@ve.

  • Serveis financers

    Portals de clients i aplicacions de back-office amb un rastre d’auditoria sòlid i processos de publicació que superen el control de canvis.

  • Indústria i fabricació

    Configuradors, portals de servei i productes SaaS per a fabricants d’equips, connectats a l’ERP i al servei tècnic de camp.

Espanya

Un mercat nou és una versió, no una bifurcació

Un producte que es ven a tota la UE troba l’Acta europea d’accessibilitat a través de lleis nacionals que difereixen en els detalls, i el Reglament de ciberresiliència a través d’un sol reglament amb obligacions que entren en vigor per etapes. Els clients de cada país també esperen la seva llengua, les seves regles de facturació i els seus sistemes d’identificació.

A Espanya, la Llei 11/2023 transposa l’Acta europea d’accessibilitat (el seu títol I s’aplica des del 28 de juny del 2025) i cada comunitat autònoma designa les autoritats de vigilància; els llocs web i les aplicacions del sector públic segueixen el Reial decret 1112/2018. Els sistemes informàtics de facturació han de complir Verifactu: els contribuents de l’impost sobre societats a partir de l’1 de gener del 2027 i la resta d’obligats a partir de l’1 de juliol del 2027. I per identificar-se davant de les administracions, la ciutadania fa servir sistemes com Cl@ve.

Mantenim aquestes diferències en la configuració i en mòduls ben delimitats, de manera que un mercat nou és una versió i no una bifurcació. La cadena de lliurament genera l’evidència d’accessibilitat i la documentació de seguretat, a punt per a les preguntes de contractació de cada mercat.

Preguntes sobre programari empresarial i SaaS

Hem de fer programari a mida o configurar una plataforma?

Configureu una plataforma quan el vostre procés és prou estàndard, i desenvolupeu a mida quan el procés és el que us diferencia o quan cap plataforma no s’adapta a les regles. Treballem amb Salesforce, SAP i Odoo i també amb codi a mida, de manera que no tenim cap motiu per imposar una resposta. El nostre servei d’Arquitectura i consultoria fa explícita aquesta elecció.

Ens podeu garantir que el nostre portal serà accessible?

Construïm d’acord amb l’EN 301 549 i les WCAG 2.2 AA, fem proves automàtiques i manuals i lliurem un informe de conformitat amb els problemes coneguts. No prometem zero problemes; prometem trobar-los, informar-ne i corregir els que són dins del nostre abast.

Podeu modernitzar sense una migració d’un sol cop?

Sí, i és el que recomanem. Una façana d’enrutament ens permet traslladar una funcionalitat cada vegada mentre l’aplicació existent continua funcionant, amb les dades conciliades a cada pas.

El nostre equip es pot fer càrrec del programari?

És el pla per defecte. Els criteris de traspàs s’acorden al principi, els vostres desenvolupadors treballen en parella amb els nostres durant la construcció, i els registres de decisions i els procediments operatius són als vostres repositoris.

Què implica el Reglament de ciberresiliència per al nostre producte?

Si comercialitzeu programari amb elements digitals al mercat de la UE, us pot comportar obligacions de disseny segur, gestió de vulnerabilitats i documentació. Nosaltres generem l’evidència d’enginyeria: SBOM, un procés de gestió de vulnerabilitats i configuració segura per defecte.

Expliqueu-nos què ha de continuar funcionant mentre canvia

Us proposarem la primera funcionalitat que cal traslladar i de què es faria càrrec el vostre equip al final.

Parlem del vostre projecteModernització de sistemes