Saltar para o conteúdo principal
FromNine
Menu

Engenharia

Software empresarial que as suas equipas continuam a conseguir mudar.

Desenvolvemos produtos SaaS, portais para cidadãos e colaboradores e aplicações centrais de gestão que são acessíveis, seguros por omissão e fáceis de manter pelas suas próprias equipas muito depois do lançamento.

Para empresas de produto e entidades públicas que servem utilizadores em vários países, línguas e regimes jurídicos.

Fale-nos do seu projetoVer modernização de sistemas legados
Software empresarial e SaaS: camadas de capacidadesQuatro camadas sobrepostas em profundidade. De cima para baixo: a interface acessível que as pessoas usam, os módulos de domínio que contêm as regras, os serviços de plataforma para multi-inquilino e identidade, e o pipeline de entrega segura por baixo.01Interfaces acessíveis02Módulos de domínio e regras03Inquilinos, identidade, dados04Pipeline de entrega segura
  1. 01Domain-driven design para trabalho cheio de regras, como a tramitação de processos
  2. 02Acessibilidade segundo a EN 301 549 e as WCAG 2.2 AA desde o primeiro desenho
  3. 03Documentação e registos de decisão que as suas equipas podem assumir

01 Problemas

O que ouvimos antes de uma reconstrução

  1. 01

    Cada alteração demora um trimestre

    A aplicação funciona, mas ninguém se atreve a mexer no núcleo. Pequenas alterações exigem grandes testes de regressão e uma janela de lançamento.

  2. 02

    O portal falha a quem devia servir

    Não funciona com um leitor de ecrã, em inglês para quem não lê português ou num telemóvel. As reclamações chegam antes da auditoria de acessibilidade.

  3. 03

    A alteração de um cliente estraga a de outro

    O produto SaaS cresceu com personalizações por cliente. Agora cada versão é uma negociação e alguns inquilinos estão presos a versões antigas.

  4. 04

    O conhecimento saiu com o fornecedor

    As decisões nunca foram escritas. A equipa que construiu o sistema já mudou de projeto, e o código é a única documentação.

  5. 05

    Chegam perguntas de segurança de clientes e reguladores

    Os procedimentos de contratação pedem uma SBOM, um processo de gestão de vulnerabilidades e evidências para o Regulamento de Ciber-Resiliência. Ninguém as tem prontas.

02 O que entregamos

O que entregamos

  1. 01 Engenharia de produtos SaaS

    Produtos concebidos para servir muitos clientes a partir de uma só base de código: o modelo multi-inquilino certo, configuração em vez de personalização e versões que chegam a todos os inquilinos.

    O que fazemos

    • Escolha do modelo multi-inquilino: partilhado, agrupado ou isolado por inquilino
    • Estratégia de configuração e de feature flags
    • Integração da medição de consumo e da faturação
    • Ciclos de lançamento com implementação por inquilino

    O que recebe

    • Conceção do modelo multi-inquilino e do isolamento
    • Modelo de configuração com regras de segurança
    • Processo de lançamento com reversão por inquilino

  2. 02 Conceção de domínio para regras complexas

    Domain-driven design onde as regras são o produto: tramitação de processos, condições de elegibilidade, cálculos carregados de regulamentação. Escolhemos de forma deliberada entre um monólito modular e microsserviços, e na maioria das vezes começamos pelo primeiro.

    O que fazemos

    • Event storming com especialistas do domínio
    • Contextos delimitados e fronteiras entre módulos
    • Regras explícitas e testáveis
    • Registos de decisões de arquitetura para as grandes escolhas

    O que recebe

    • Modelo de domínio e mapa de contextos
    • Base de código modular com fronteiras aplicadas
    • Especificações executáveis para as regras principais

  3. 03 Portais para cidadãos e colaboradores

    Interfaces construídas sobre um design system, acessíveis por omissão e preparadas para várias línguas desde a primeira versão. Nas entidades públicas portuguesas, isso significa também autenticação pela Chave Móvel Digital e uma declaração de acessibilidade publicada em «/acessibilidade»; noutros mercados, significa as línguas que os seus utilizadores falam de facto.

    O que fazemos

    • Design system com componentes acessíveis
    • Conteúdos escritos em linguagem clara
    • Testes com tecnologias de apoio e utilizadores reais
    • Fluxo de localização para cada língua

    O que recebe

    • Portal sobre um design system reutilizável
    • Relatório de conformidade de acessibilidade
    • Fluxo de conteúdos e de tradução

  4. 04 Engenharia de qualidade e desenvolvimento seguro

    Automatização de testes aos níveis certos, testes de contrato entre serviços, testes de desempenho antes do lançamento e um ciclo de desenvolvimento seguro assente no OWASP ASVS, em SBOM e em controlos da cadeia de fornecimento.

    O que fazemos

    • Estratégia e automatização de testes
    • Testes de contrato e de desempenho
    • Modelação de ameaças e verificação ASVS
    • Geração de SBOM e política de dependências

    O que recebe

    • Conjuntos de testes automáticos no pipeline
    • Relatório de verificação de segurança
    • Processo de gestão de vulnerabilidades preparado para o Regulamento de Ciber-Resiliência

  5. 05 Modernização incremental

    Substituir uma aplicação legada uma capacidade de cada vez, atrás de uma fachada de encaminhamento, enquanto a atividade continua. Ver também modernização de sistemas legados.

    O que fazemos

    • Mapa de capacidades da aplicação existente
    • Encaminhamento strangler fig e encapsulamento por API
    • Migração de dados com relatórios de conciliação
    • Execuções em paralelo para os cálculos críticos

    O que recebe

    • Sequência de modernização com marcos de negócio
    • Fachada e novos módulos em produção
    • Dados conciliados em cada transição

  6. 06 Manutenção e passagem de testemunho

    Software que as suas equipas podem assumir: código legível, registos de decisão, procedimentos operacionais e um plano de passagem acordado no início, e não descoberto no fim.

    O que fazemos

    • Trabalho em par com os seus programadores durante o desenvolvimento
    • Registos de decisões de arquitetura mantidos junto do código
    • Procedimentos operacionais e guias de piquete
    • Marcos de transferência de conhecimento

    O que recebe

    • Plano de passagem com critérios de aceitação
    • Documentação nos seus repositórios
    • Equipa interna com formação

03 Arquitetura

Uma arquitetura de referência ilustrativa

Uma forma típica para uma aplicação de gestão que substitui outra mais antiga: um front-end acessível, uma fachada de encaminhamento que envia cada capacidade para o sistema antigo ou para o novo, uma camada de APIs com contratos claros e um núcleo modular organizado em torno do domínio.

O modelo multi-inquilino e a configuração são serviços de plataforma explícitos, e não condições espalhadas pelo código. Por baixo, cada build corre testes e verificações de segurança e produz uma SBOM.

Camadas do desenho

Pessoas
Cidadãos, clientes e colaboradores, em qualquer dispositivo e com tecnologias de apoio.
Modernização
A fachada de encaminhamento, a aplicação existente e a migração de dados com conciliação.
Plataforma
Camada de APIs, identidade, núcleo modular, multi-inquilino e configuração, dados operacionais.
Entrega segura
Testes de contrato e de desempenho, verificações ASVS e uma SBOM em cada build.
Exemplo ilustrativo

  1. Pessoas

    • Cidadãos, clientes, colaboradores
    • Front-end acessível

  2. Modernização incremental

    • Fachada de encaminhamento
    • Aplicação existente
    • Migração com conciliação

  3. Plataforma

    • Camada de APIs e contratos
    • Identidade e perfis
    • Núcleo modular: entrada, processos, faturação
    • Inquilinos, configuração, feature flags
    • Dados operacionais

  4. Entrega segura

    • Testes de contrato e de desempenho, verificações ASVS, SBOM em cada build
Núcleo modular atrás de uma fachada de encaminhamento

Arquitetura ilustrativa, não corresponde a um sistema de um cliente.

Ler o diagrama em texto

O percurso principal vai das pessoas a um front-end acessível, através de uma fachada de encaminhamento e de uma camada de APIs, até um núcleo modular organizado em contextos delimitados.

A fachada encaminha também algumas capacidades para a aplicação existente, que é desativada passo a passo. Os dados dessa aplicação passam por uma migração com conciliação para os repositórios de dados operacionais.

A gestão de identidades serve a camada de APIs. Os serviços de multi-inquilino e de configuração estão por baixo do núcleo. Uma faixa de entrega segura, em baixo, abrange testes de contrato, testes de desempenho, verificação de segurança e SBOM.

04 Considerações e limites

Considerações de engenharia e limites

  • Primeiro o monólito modular

    Como o tratamos

    Começamos com módulos claros numa única unidade de implementação e só separamos serviços onde a escala, o ritmo de lançamento ou a responsabilidade das equipas o exigem.

    Limites e dependências

    Os microsserviços resolvem problemas de organização tanto quanto problemas técnicos. Sem equipas responsáveis por eles, acrescentam custo e modos de falha.

  • A acessibilidade é trabalho de engenharia

    Como o tratamos

    Componentes acessíveis, verificações automáticas no pipeline e testes manuais com tecnologias de apoio antes de cada versão importante.

    Limites e dependências

    As ferramentas automáticas encontram apenas parte dos problemas. A conformidade total exige auditorias manuais e, idealmente, testes com pessoas com deficiência.

    Os conteúdos e documentos acrescentados por editores depois do lançamento têm de cumprir o mesmo padrão. Damos formação aos editores, mas não controlamos o que publicam.

  • A modernização demora o que demoram os dados

    Como o tratamos

    A migração de dados é planeada por capacidade, ensaiada e conciliada, com aprovação do negócio em cada transição.

    Limites e dependências

    A qualidade dos dados legados dita muitas vezes o ritmo. Limpá-los é uma tarefa do negócio tanto quanto uma tarefa técnica.

  • Regulação para produtos de software

    Como o tratamos

    SBOM, gestão de vulnerabilidades e predefinições seguras fazem parte do nosso pipeline padrão, que prepara os produtos para o Regulamento de Ciber-Resiliência.

    Limites e dependências

    Se e como o regulamento se aplica ao seu produto é uma questão jurídica. Nós fornecemos as evidências de engenharia; os seus assessores jurídicos fazem a avaliação.

05 Como trabalhamos

Como trabalhamos

Ciclos curtos, utilizadores reais desde cedo e a passagem de testemunho planeada desde a primeira semana.

  1. 01

    Mapear o domínio

    Event storming com as pessoas que conhecem as regras e um mapa de capacidades do que existe hoje.

    ResultadoMapa de contextos e primeiros registos de decisão

  2. 02

    Lançar uma fatia fina

    Uma capacidade de ponta a ponta, através da fachada, em produção com utilizadores reais.

    ResultadoFatia a funcionar em produção

  3. 03

    Crescer capacidade a capacidade

    Cada versão muda uma capacidade, os seus dados e os seus utilizadores, com conciliação e reversão preparadas.

    ResultadoPlano de versões por capacidade

  4. 04

    Passar o testemunho

    Os seus programadores trabalham em par com os nossos, assumem o piquete e ficam com o roadmap quando os critérios de passagem estão cumpridos.

    ResultadoPassagem aceite

06 Controlo humano

Onde as pessoas mantêm o controlo

No software de gestão, ter controlo significa saber quem mudou o quê, quem o aprovou e como desfazer.

  • Os product owners decidem o âmbito

    O product owner da sua organização define as prioridades e aceita cada incremento. Nós aconselhamos; quem decide é o product owner.

  • A configuração tem um responsável

    As definições dos inquilinos e as feature flags são alteradas através de um processo auditado, pelos perfis que a sua organização atribui.

  • As transições são aprovadas

    Cada passagem do sistema antigo para o novo é aprovada pelo negócio, com uma reversão ensaiada.

  • As decisões ficam escritas

    Os registos de decisões de arquitetura mostram o que foi escolhido, por quem e porquê, para que as equipas futuras as possam rever com conhecimento de causa.

07 Tecnologias

Tecnologias com que trabalhamos

Back-end
  • Java e Kotlin
  • .NET
  • TypeScript e Node.js
  • Python
Front-end
  • React e Next.js
  • Angular
  • Design systems com componentes acessíveis
  • Aplicações móveis nativas e multiplataforma
Dados
  • PostgreSQL
  • SQL Server e Oracle (ambientes existentes)
  • Streaming de eventos
  • Motores de pesquisa
Qualidade e segurança
  • Playwright e testes de contrato
  • Testes de carga e de desempenho
  • SAST, DAST e análise de dependências
  • SBOM em CycloneDX ou SPDX

A referência a uma tecnologia descreve a nossa experiência de engenharia. Não implica uma parceria com o respetivo fabricante nem o seu aval.

08 Exemplo

Um exemplo ilustrativo

Exemplo ilustrativo

Um portal de requerimentos comum aos municípios de uma comunidade intermunicipal

01Situação
Os municípios de uma comunidade intermunicipal têm cada um o seu portal, feito por fornecedores diferentes. Cada portal falha as verificações de acessibilidade de forma diferente, e cada alteração é feita várias vezes.
02O que construiríamos
Um só portal sobre um design system partilhado, com autenticação pela Chave Móvel Digital e com os conteúdos, os regulamentos e as integrações de cada município mantidos na configuração e num só ciclo de lançamento.
03Onde as pessoas decidem
Cada câmara municipal aprova os conteúdos e a configuração que lhe dizem respeito; a comunidade intermunicipal decide as funcionalidades comuns.
04O que mediríamos
Problemas de acessibilidade por versão, prazo de uma alteração em todos os municípios e percentagem de alterações feitas uma só vez em vez de município a município.

09 Por setor

No seu setor

  • Administração pública

    Gestão processual e portais para cidadãos que cumprem o Decreto-Lei n.º 83/2018 e usam a autenticação do Estado, incluindo a Chave Móvel Digital, como prevê o Decreto-Lei n.º 49/2024.

  • Serviços financeiros

    Portais de clientes e aplicações de back-office com registos de auditoria sólidos e processos de lançamento que cumprem o controlo de alterações.

  • Indústria transformadora

    Configuradores, portais de assistência e produtos SaaS para fabricantes de equipamentos, ligados ao ERP e à assistência no terreno.

Portugal

Um novo mercado é uma versão, não um fork

Um produto vendido na UE cumpre o Ato Europeu da Acessibilidade através de leis nacionais que diferem no pormenor, e o Regulamento de Ciber-Resiliência através de um único regulamento com obrigações que começam por fases. Em Portugal, o Decreto-Lei n.º 82/2022 transpõe o Ato Europeu da Acessibilidade e aplica-se aos produtos e serviços abrangidos desde 28 de junho de 2025, com os requisitos técnicos na Portaria n.º 220/2023; o INR acompanha a sua aplicação.

As entidades públicas seguem o Decreto-Lei n.º 83/2018 para os seus sites e aplicações móveis e, ao abrigo do Decreto-Lei n.º 49/2024, usam a autenticação do Estado, incluindo a Chave Móvel Digital. Mantemos estas diferenças na configuração e em módulos bem delimitados, para que um novo mercado seja uma versão e não um fork. As evidências de acessibilidade e a documentação de segurança são produzidas pelo pipeline, prontas para as perguntas de cada procedimento de contratação.

Perguntas sobre software empresarial e SaaS

Devemos desenvolver à medida ou configurar uma plataforma?

Configure uma plataforma quando o seu processo está próximo do padrão, e desenvolva à medida quando o processo é o que distingue a sua organização ou quando nenhuma plataforma se ajusta às regras. Trabalhamos com Salesforce, SAP e Odoo e também com código à medida, por isso não temos razão para impor uma resposta. O nosso serviço de Arquitetura e consultoria torna esta escolha explícita.

Podem garantir que o nosso portal é acessível?

Desenvolvemos segundo a EN 301 549 e as WCAG 2.2 AA, testamos de forma automática e manual e entregamos um relatório de conformidade com os problemas conhecidos. Não prometemos zero problemas; prometemos encontrá-los, comunicá-los e corrigir o que estiver no nosso âmbito.

Conseguem modernizar sem uma migração de uma só vez?

Sim, e é o que recomendamos. Uma fachada de encaminhamento permite mudar uma capacidade de cada vez enquanto a aplicação existente continua a funcionar, com os dados conciliados em cada passo.

A nossa equipa pode assumir o software?

É o plano por omissão. Os critérios de passagem são acordados no início, os seus programadores trabalham em par com os nossos durante o desenvolvimento, e os registos de decisão e os procedimentos operacionais ficam nos seus repositórios.

O que significa o Regulamento de Ciber-Resiliência para o nosso produto?

Se a sua organização coloca no mercado da UE software com elementos digitais, o regulamento pode trazer obrigações de conceção segura, gestão de vulnerabilidades e documentação. Nós construímos as evidências de engenharia: SBOM, um processo de gestão de vulnerabilidades e predefinições seguras.

Diga-nos o que tem de continuar a funcionar enquanto muda

Propomos a primeira capacidade a mudar e o que a sua equipa terá a seu cargo no fim.

Fale-nos do seu projetoVer modernização de sistemas legados