Saltar ao contido principal
FromNine
Menú

Enxeñaría

Software empresarial que os seus propios equipos poden seguir cambiando.

Desenvolvemos produtos SaaS, portais para a cidadanía e para o persoal e aplicacións de negocio centrais que son accesibles, seguros por defecto e que os seus propios equipos poden manter moito despois da posta en marcha.

Para empresas de produto e organismos públicos que precisan software accesible, en galego e en castelán, que o seu propio equipo poida manter.

Fálenos do seu proxectoModernización de sistemas
Software empresarial e SaaS: capas de capacidadeCatro capas superpostas en profundidade. De arriba abaixo: a interface accesible que usan as persoas, os módulos de dominio que conteñen as regras, os servizos de plataforma para clientes e identidade, e por debaixo a cadea de entrega segura.01Interfaces accesibles02Módulos de dominio e regras03Clientes, identidade, datos04Cadea de entrega segura
  1. 01Deseño guiado polo dominio para traballo con moitas regras, como a tramitación de expedientes
  2. 02Accesibilidade segundo a EN 301 549 e as WCAG 2.2 AA desde o primeiro deseño
  3. 03Documentación e rexistros de decisións que os seus equipos poden asumir

01 Problemas

O que oímos antes dunha reconstrución

  1. 01

    Cada cambio leva un trimestre

    A aplicación funciona, pero ninguén se atreve a tocar o núcleo. Os cambios pequenos requiren grandes probas de regresión e unha xanela de publicación.

  2. 02

    O portal falla ás persoas ás que serve

    Non funciona cun lector de pantalla, na outra lingua oficial nin nun teléfono. As queixas chegan antes ca a auditoría de accesibilidade.

  3. 03

    O cambio dun cliente estraga o doutro

    O produto SaaS creceu personalizándose para cada cliente. Agora cada versión é unha negociación e algúns clientes quedaron atrapados en versións antigas.

  4. 04

    O coñecemento marchou co provedor

    As decisións nunca se puxeron por escrito. O equipo que o construíu xa non está, e o código é a única documentación.

  5. 05

    Chegan preguntas de seguridade da clientela e dos reguladores

    Os pregos piden un SBOM, un proceso de vulnerabilidades e evidencia para o Regulamento de ciberresiliencia. Ninguén os ten preparados.

02 Que entregamos

Que entregamos

  1. 01 Enxeñaría de produtos SaaS

    Produtos pensados para servir a moitos clientes desde un único código: o modelo de clientes axeitado, configuración en vez de personalización, e versións que chegan a todos os clientes.

    Que facemos

    • Elección do modelo de clientes: compartido, agrupado ou illado por cliente
    • Estratexia de configuración e de marcas de funcionalidade
    • Integración da medición do uso e da facturación
    • Calendario de versións con despregamento por cliente

    Que recibe

    • Deseño dos clientes e do illamento
    • Modelo de configuración con límites
    • Proceso de publicación con reversión por cliente

  2. 02 Deseño do dominio para regras complexas

    Deseño guiado polo dominio cando as regras son o produto: tramitación de expedientes, requisitos de acceso a axudas, cálculos cargados de normativa. Eliximos con criterio entre un monolito modular e os microservizos, e a maioría das veces comezamos polo primeiro.

    Que facemos

    • Event storming coas persoas expertas do dominio
    • Contextos delimitados e fronteiras entre módulos
    • Regras explícitas e que se poden probar
    • Rexistros de decisións de arquitectura para as grandes eleccións

    Que recibe

    • Modelo de dominio e mapa de contextos
    • Código modular con fronteiras que se fan cumprir
    • Especificacións executables para as regras clave

  3. 03 Portais para a cidadanía e para o persoal

    Interfaces construídas sobre un sistema de deseño, accesibles por defecto e multilingües desde a primeira versión. En Galicia iso significa galego e castelán ao mesmo nivel; noutros lugares, as linguas que falan de verdade as súas persoas usuarias.

    Que facemos

    • Sistema de deseño con compoñentes accesibles
    • Deseño de contidos en linguaxe clara
    • Probas con tecnoloxías de apoio e con persoas usuarias reais
    • Fluxo de localización para cada lingua

    Que recibe

    • Portal sobre un sistema de deseño reutilizable
    • Informe de conformidade en accesibilidade
    • Fluxo de contidos e de tradución

  4. 04 Enxeñaría da calidade e desenvolvemento seguro

    Automatización das probas nos niveis axeitados, probas de contrato entre servizos, probas de rendemento antes da posta en marcha e un ciclo de desenvolvemento seguro baseado en OWASP ASVS, SBOM e controis da cadea de subministración.

    Que facemos

    • Estratexia e automatización das probas
    • Probas de contrato e de rendemento
    • Modelado de ameazas e verificación ASVS
    • Xeración de SBOM e política de dependencias

    Que recibe

    • Baterías de probas automatizadas na cadea de entrega
    • Informe de verificación de seguridade
    • Proceso de xestión de vulnerabilidades preparado para o Regulamento de ciberresiliencia

  5. 05 Modernización gradual

    Substituír unha aplicación herdada función a función, detrás dunha fachada de enrutamento, mentres a actividade continúa. Vexa tamén Modernización de sistemas herdados.

    Que facemos

    • Mapa de funcións da aplicación existente
    • Enrutamento por substitución progresiva (strangler fig) e encapsulado con API
    • Migración de datos con informes de conciliación
    • Execucións en paralelo para os cálculos críticos

    Que recibe

    • Secuencia de modernización con fitos de negocio
    • Fachada e novos módulos en produción
    • Datos conciliados en cada cambio de sistema

  6. 06 Mantemento e traspaso

    Software que os seus equipos poden asumir: código lexible, rexistros de decisións, manuais de operación e un plan de traspaso acordado ao comezo, non descuberto ao final.

    Que facemos

    • Traballo en parella coas súas persoas desenvolvedoras durante a construción
    • Rexistros de decisións de arquitectura xunto ao código
    • Manuais de operación e guías de gardas
    • Fitos de transferencia de coñecemento

    Que recibe

    • Plan de traspaso con criterios de aceptación
    • Documentación nos seus repositorios
    • Equipo interno formado

03 Arquitectura

Unha arquitectura de referencia ilustrativa

Unha forma habitual para unha aplicación de negocio que substitúe outra máis antiga: unha interface accesible, unha fachada de enrutamento que envía cada función ao sistema antigo ou ao novo, unha capa de API con contratos claros e un núcleo modular organizado arredor do dominio.

Os clientes e a configuración son servizos de plataforma explícitos, non condicións espalladas polo código. Por debaixo, cada compilación executa probas e comprobacións de seguridade e xera un SBOM.

Capas do debuxo

Persoas
Cidadanía, clientela e persoal, en calquera dispositivo e con tecnoloxías de apoio.
Modernización
A fachada de enrutamento, a aplicación existente e a migración de datos con conciliación.
Plataforma
Capa de API, identidade, núcleo modular, clientes e configuración, datos operativos.
Entrega segura
Probas de contrato e de rendemento, comprobacións ASVS e un SBOM en cada compilación.
Exemplo ilustrativo

  1. Persoas

    • Cidadanía, clientela, persoal
    • Interface accesible

  2. Moderniza­ción gradual

    • Fachada de enrutamento
    • Aplicación existente
    • Migración con conciliación

  3. Plataforma

    • Capa de API e contratos
    • Identidade e roles
    • Núcleo modular: entrada, expedientes, facturación
    • Clientes, configuración, marcas de funcionalidade
    • Almacéns de datos operativos

  4. Entrega segura

    • Probas de contrato e de rendemento, comprobacións ASVS e SBOM en cada compilación
Núcleo modular detrás dunha fachada de enrutamento

Arquitectura ilustrativa, non é o sistema dun cliente.

Ler o diagrama como texto

A ruta principal vai das persoas a unha interface accesible, pasa por unha fachada de enrutamento e por unha capa de API e chega a un núcleo modular organizado en contextos delimitados.

A fachada tamén envía algunhas funcións á aplicación existente, que se retira paso a paso. Os seus datos pasan, mediante unha migración con conciliación, aos almacéns de datos operativos.

A identidade dá servizo á capa de API. Os servizos de clientes e de configuración están debaixo do núcleo. Unha franxa de entrega segura, por debaixo, abrangue as probas de contrato, as probas de rendemento, a verificación de seguridade e os SBOM.

04 Consideracións e límites

Consideracións técnicas e límites

  • Primeiro, un monolito modular

    Como o abordamos

    Comezamos con módulos claros nunha única unidade despregable e só separamos servizos cando o esixen a escala, o ritmo de publicación ou a responsabilidade dos equipos.

    Límites e dependencias

    Os microservizos resolven problemas organizativos tanto como técnicos. Sen equipos que se fagan cargo deles, engaden custo e novos modos de fallo.

  • A accesibilidade é traballo de enxeñaría

    Como o abordamos

    Compoñentes accesibles, comprobacións automáticas na cadea de entrega e probas manuais con tecnoloxías de apoio antes de cada versión importante.

    Límites e dependencias

    As ferramentas automáticas só atopan parte dos problemas. A conformidade completa necesita auditorías manuais e, idealmente, probas con persoas con discapacidade.

    Os contidos e documentos que engaden as persoas editoras despois da posta en marcha deben cumprir o mesmo estándar. Formamos a quen edita, pero non controlamos o que publica.

  • A modernización dura o que duran os datos

    Como o abordamos

    A migración de datos planifícase por función, ensáiase e concíliase, coa aprobación do negocio en cada cambio de sistema.

    Límites e dependencias

    A calidade dos datos herdados adoita marcar o ritmo. Limpalos é unha tarefa de negocio tanto como técnica.

  • Normas para os produtos de software

    Como o abordamos

    Os SBOM, a xestión de vulnerabilidades e a configuración segura por defecto forman parte da nosa cadea de entrega estándar, que prepara os produtos para o Regulamento de ciberresiliencia.

    Límites e dependencias

    Se o Regulamento se aplica ao seu produto, e como, é unha cuestión xurídica. Nós achegamos a evidencia técnica; a súa asesoría legal fai a avaliación.

05 Como traballamos

Como traballamos

Ciclos curtos, persoas usuarias reais desde o comezo e o traspaso planificado desde a primeira semana.

  1. 01

    Mapear o dominio

    Event storming coas persoas que coñecen as regras e un mapa das funcións que existen hoxe.

    ResultadoMapa de contextos e primeiros rexistros de decisións

  2. 02

    Entregar unha primeira parte

    Unha función de principio a fin, a través da fachada, en produción con persoas usuarias reais.

    ResultadoPrimeira parte funcionando en produción

  3. 03

    Crecer función a función

    Cada versión move unha función, os seus datos e as súas persoas usuarias, coa conciliación e a reversión preparadas.

    ResultadoPlan de versións por función

  4. 04

    Traspasar

    As súas persoas desenvolvedoras traballan en parella coas nosas, asumen as gardas e fanse cargo da folla de ruta cando se cumpren os criterios de traspaso.

    ResultadoTraspaso aceptado

06 Control humano

Onde as persoas manteñen o control

No software de negocio, ter o control significa saber quen cambiou que, quen o aprobou e como desfacelo.

  • A persoa responsable do produto decide o alcance

    A persoa responsable do produto na súa organización fixa as prioridades e acepta cada incremento. Nós aconsellamos; ela decide.

  • A configuración ten responsable

    Os axustes de cada cliente e as marcas de funcionalidade cámbianse mediante un proceso auditado, polos roles que vostede asigna.

  • Os cambios de sistema apróbanse

    O negocio aproba cada paso do sistema antigo ao novo, cunha reversión ensaiada.

  • As decisións quedan por escrito

    Os rexistros de decisións de arquitectura mostran que se escolleu, quen o fixo e por que, para que os equipos futuros poidan revisalo con coñecemento de causa.

07 Tecnoloxías

Tecnoloxías coas que traballamos

Back end
  • Java e Kotlin
  • .NET
  • TypeScript e Node.js
  • Python
Front end
  • React e Next.js
  • Angular
  • Sistemas de deseño con compoñentes accesibles
  • Móbil nativo e multiplataforma
Datos
  • PostgreSQL
  • SQL Server e Oracle (contornos existentes)
  • Streaming de eventos
  • Motores de busca
Calidade e seguridade
  • Playwright e probas de contrato
  • Probas de carga e de rendemento
  • SAST, DAST e análise de dependencias
  • SBOM en CycloneDX ou SPDX

Mencionar unha tecnoloxía describe a nosa experiencia técnica. Non implica unha asociación co seu fabricante nin o seu respaldo.

08 Exemplo

Un exemplo ilustrativo

Exemplo ilustrativo

Un portal de solicitudes con Cl@ve para unha mancomunidade de concellos

01Situación
Unha mancomunidade presta servizos comúns a varios concellos, e cada un recolle as solicitudes á súa maneira: papel, correo e un formulario web que non supera as comprobacións de accesibilidade. Cada cambio faise varias veces.
02Que construiriamos
Un único portal sobre un sistema de deseño compartido, con acceso con Cl@ve e en galego e castelán ao mesmo nivel, cos contidos, trámites e integracións de cada concello na configuración e unha única liña de versións.
03Onde deciden as persoas
Cada concello aproba os contidos e a configuración dos seus trámites; a persoa responsable do produto na mancomunidade decide sobre as funcións comúns.
04Que mediriamos
Incidencias de accesibilidade por versión, tempo para aplicar un cambio en todos os concellos e proporción de cambios feitos unha soa vez en lugar de concello a concello.

09 Por sector

No seu sector

  • Sector público

    Xestión de expedientes e portais para a cidadanía que cumpren a normativa de accesibilidade, funcionan en galego e en castelán e conectan cos servizos de intercambio de datos entre administracións.

  • Servizos financeiros

    Portais para a clientela e aplicacións de backoffice con rexistros de auditoría sólidos e procesos de publicación que satisfán o control de cambios.

  • Fabricación e industria

    Configuradores, portais de servizo e produtos SaaS para fabricantes de equipos, conectados ao ERP e ao servizo técnico de campo.

España

Accesible, con Cl@ve e nas dúas linguas oficiais

En España, os sitios web e as aplicacións móbiles do sector público deben cumprir o Real decreto 1112/2018 de accesibilidade, e a Lei 11/2023 traspón a Acta europea de accesibilidade para os produtos e servizos do seu ámbito desde o 28 de xuño de 2025. O Regulamento de ciberresiliencia engade obrigas para o software que entran en vigor por etapas.

Nos servizos públicos, Cl@ve é a plataforma común de identificación, autenticación e sinatura do sector público administrativo estatal, e en Galicia a cidadanía ten dereito a usar o galego coa Administración. Deseñamos sistemas que funcionan en galego e en castelán, coas dúas linguas ao mesmo nivel.

Mantemos estas diferenzas na configuración e en módulos ben delimitados, de modo que unha nova entidade ou un novo mercado sexa unha versión e non unha bifurcación. A cadea de entrega produce a evidencia de accesibilidade e a documentación de seguridade que piden os pregos.

Preguntas sobre software empresarial e SaaS

Desenvolvemos a medida ou configuramos unha plataforma?

Configure unha plataforma cando o seu proceso estea preto do estándar, e desenvolva a medida cando o proceso sexa o que o distingue ou cando ningunha plataforma se axuste ás regras. Traballamos con Salesforce, SAP e Odoo e tamén con código propio, así que non temos motivo para empurrar unha resposta. O noso servizo de Arquitectura e consultoría fai explícita esta elección.

Poden garantir que o noso portal é accesible?

Construímos segundo a EN 301 549 e as WCAG 2.2 AA, probamos de forma automática e manual, e entregamos un informe de conformidade cos problemas coñecidos. Non prometemos cero problemas; prometemos atopalos, informar deles e corrixir o que estea no noso alcance.

Poden modernizar sen unha migración dunha soa vez?

Si, e recomendámolo. Unha fachada de enrutamento permítenos mover unha función de cada vez mentres a aplicación existente segue funcionando, cos datos conciliados en cada paso.

Pode o noso propio equipo facerse cargo do software?

Ese é o plan por defecto. Os criterios de traspaso acórdanse ao comezo, as súas persoas desenvolvedoras traballan en parella coas nosas durante a construción, e os rexistros de decisións e os manuais de operación quedan nos seus repositorios.

Que supón o Regulamento de ciberresiliencia para o noso produto?

Se introduce no mercado da UE software con elementos dixitais, pode traer obrigas de deseño seguro, xestión de vulnerabilidades e documentación. Nós construímos a evidencia técnica: SBOM, un proceso de vulnerabilidades e configuración segura por defecto.

Díganos que debe seguir funcionando mentres cambia

Propoñerémoslle a primeira función que mover e o que o seu equipo asumiría ao final.

Fálenos do seu proxectoModernización de sistemas