Capítulo 54 — Roadmap Tecnológico
Este capítulo define a trajetória de evolução tecnológica da Plataforma de Relacionamento Digital com o Cidadão ao longo dos sessenta meses da parceria com a PRODEMGE. Ele responde a uma pergunta central que nenhum docum…
54.1 Objetivo do Capítulo
Este capítulo define a trajetória de evolução tecnológica da Plataforma de Relacionamento Digital com o Cidadão ao longo dos sessenta meses da parceria com a PRODEMGE. Ele responde a uma pergunta central que nenhum documento de arquitetura estática pode responder sozinho: como a plataforma muda ao longo do tempo sem comprometer a estabilidade dos tenants em produção, sem acumular dívida técnica e sem perder coerência arquitetural?
O roadmap não é um cronograma de projeto. É um instrumento de governança técnica: estabelece direções, marcos de maturidade, critérios de evolução e a relação entre as melhorias planejadas e os compromissos operacionais já assumidos. As datas são referências de horizonte, não promessas de entrega. As entregas concretas de cada ciclo serão acordadas por meio do processo de Gestão da Evolução descrito no Capítulo 55.
A estrutura deste capítulo cobre cinco horizontes de evolução — correspondentes aos cinco anos da parceria — organizados em torno de quatro eixos: capacidades funcionais, maturidade arquitetural, inteligência artificial e sustentabilidade operacional. Cada horizonte parte da base estabelecida pelo anterior e adiciona capacidades que não seriam viáveis sem a maturidade acumulada.
54.2 Contexto
A plataforma parte de uma base já operacional, com arquitetura de microsserviços, mensageria assíncrona via RabbitMQ, multi-tenancy nativo, módulos funcionais de CRM, BPM, GED, comunicação omnichannel, portal web, aplicativo mobile, IA com RAG e um conjunto consolidado de capacidades de segurança, observabilidade e DevSecOps.
Essa base não é ponto de partida experimental. É fundação produtiva sobre a qual o roadmap constrói. Isso tem uma consequência arquitetural importante: a evolução ocorre sobre infraestrutura em operação, com tenants em produção, com SLAs contratuais vigentes. Cada mudança deve respeitar o histórico de estabilidade da versão anterior e ser validada em staging antes de chegar à produção.
O roadmap é orientado por três forças concorrentes: a demanda dos órgãos participantes por novas capacidades, a evolução do ecossistema tecnológico (linguagens, frameworks, provedores de IA, regulações), e a necessidade de reduzir complexidade operacional acumulada ao longo do tempo. Um roadmap que ignora qualquer das três forças tende a gerar plataformas funcionalmente ricas mas operacionalmente frágeis, ou tecnologicamente atualizadas mas funcionalmente inadequadas ao contexto de governo.
54.3 Escopo
O capítulo cobre:
- estrutura do roadmap em horizontes anuais e eixos de evolução;
- capacidades funcionais planejadas por horizonte;
- evoluções arquiteturais e de infraestrutura planejadas;
- trajetória de maturidade dos componentes de IA;
- indicadores de maturidade tecnológica por fase;
- relação entre o roadmap e os processos operacionais e de SLA;
- decisões arquiteturais que governam o roadmap;
- rastreabilidade com os documentos do Chamamento.
Não estão no escopo deste capítulo os mecanismos de gestão e governança do backlog de evolução, que são tratados no Capítulo 55, nem o detalhamento dos processos de mudança e deploy, tratados no Capítulo 59.
54.4 Princípios do Roadmap
O roadmap é orientado por princípios que definem como a evolução ocorre, não apenas o que evolui:
Evolução sem ruptura. Nenhuma versão da plataforma pode invalidar tenants em produção. Interfaces são versionadas. Mudanças quebram compatibilidade somente após período de coexistência documentado.
Capacidade antes de otimização. Nos horizontes iniciais, o foco é ampliar cobertura funcional. Nos horizontes avançados, o foco desloca-se para eficiência, observabilidade e qualidade arquitetural acumulada. Otimização prematura de um módulo ainda em consolidação funcional gera retrabalho.
Maturidade como pré-requisito. Capacidades avançadas de IA, por exemplo, dependem da maturidade das bases de conhecimento, dos ciclos de avaliação e dos guardrails. Não são entregues antes da fundação estar operacionalmente estável.
ADRs como registro de trajetória. Cada decisão de roadmap que altera a arquitetura corrente é registrada como Architecture Decision Record antes de ser implementada. O histórico de ADRs é o registro rastreável das razões pelas quais a plataforma chegou ao estado que está em qualquer momento do ciclo.
SLA como restrição, não como objetivo. O roadmap não justifica desvios de SLA. Evoluções planejadas que impactam disponibilidade são executadas em janelas acordadas com a PRODEMGE e comunicadas com antecedência mínima conforme o processo de gestão de mudanças.
Retração técnica planejada. O roadmap prevê explicitamente ciclos de pagamento de dívida técnica — períodos em que o foco é refatoração, melhoria de cobertura de testes, documentação e simplificação de componentes. Esses ciclos não são visíveis ao usuário final, mas são indispensáveis para manter a velocidade de entrega nos horizontes seguintes.
54.5 Estrutura do Roadmap
O roadmap é organizado em cinco horizontes anuais. Cada horizonte é descrito por quatro eixos:
| Eixo | Descrição |
|---|---|
| Capacidades Funcionais | Módulos, features e fluxos disponíveis para os órgãos e cidadãos |
| Maturidade Arquitetural | Qualidade da arquitetura de software e infraestrutura |
| Inteligência Artificial | Capacidades de IA e maturidade do ciclo de RAG, avaliação e modelos |
| Sustentabilidade Operacional | Observabilidade, automação de operação, eficiência e redução de custo marginal por tenant |
A cada ano, marcos de maturidade permitem verificar objetivamente se o horizonte foi atingido antes de comprometer entregas do horizonte seguinte.
54.6 Horizonte 1 — Ano 1: Fundação e Primeiros Tenants
54.6.1 Contexto do Horizonte
O primeiro horizonte corresponde ao período de estruturação da parceria, implantação dos primeiros órgãos e estabilização da plataforma em ambiente produtivo compartilhado. O desafio central não é adicionar funcionalidades, mas consolidar a base em produção com operação confiável e replicável.
54.6.2 Capacidades Funcionais
Os módulos nucleares — CRM, BPM, GED, comunicação omnichannel, portal web e aplicativo mobile — são operacionalizados nos primeiros tenants. O foco é fluidez de onboarding: a capacidade de implantar um novo órgão em prazo previsível, com processo documentado, sem dependência de customizações fora do padrão.
O catálogo de serviços públicos, a gestão de solicitações e protocolos, e o painel de gestão com dashboards de atendimento compõem a experiência mínima funcional para gestores de órgão. Os canais de comunicação — e-mail, SMS, WhatsApp e notificação push — são ativados e configurados por tenant durante o onboarding.
A integração com GOV.BR via OpenID Connect é estabilizada como mecanismo padrão de autenticação do cidadão, com fallback de autenticação local para contextos que não exigem identidade federada.
54.6.3 Maturidade Arquitetural
O pipeline de CI/CD está operacional com cobertura de testes automatizados, análise estática de segurança e deploy progressivo via canary. O rollback automático por health check é testado e validado em produção.
A estratégia de multi-tenancy — isolamento de dados por schema ou banco por domínio conforme decidido via ADR-001 e ADR-112 — está implementada e auditada. Nenhuma requisição de um tenant acessa dados de outro, e esse isolamento é verificado por testes de segurança específicos no pipeline.
O modelo de observabilidade com OpenTelemetry, Prometheus e stack de log centralizado está ativo para todos os serviços. Os dashboards de SLA definidos no Capítulo 53 são alimentados por métricas reais e acessíveis à PRODEMGE.
54.6.4 Inteligência Artificial
O assistente conversacional com RAG está implantado nos primeiros tenants com bases de conhecimento iniciais — catálogo de serviços, perguntas frequentes e normativas do órgão. A pipeline RAG completa — ingestão, chunking, embedding, retrieval, reranking e geração — está operacional com isolamento multi-tenant verificado.
O copiloto de atendimento interno, que apoia atendentes com sugestões contextualizadas durante o atendimento, é implantado em pelo menos um órgão como validação do modelo em contexto real. A avaliação de qualidade do RAG — precisão de retrieval, groundedness, relevância — é iniciada com datasets de referência por tenant.
54.6.5 Sustentabilidade Operacional
O processo de onboarding de novo tenant é documentado, executado em ciclos controlados e avaliado quanto a tempo de execução e volume de customizações fora do padrão. O objetivo é que cada novo onboarding seja mais rápido que o anterior, eliminando gargalos operacionais identificados.
Os runbooks de operação — resposta a incidentes, deploy de emergência, rollback, restart de consumidores RabbitMQ, restore de backup — são validados em exercícios controlados. A operação não deve depender de conhecimento tácito não documentado.
54.6.6 Marcos de Maturidade — Ano 1
| Marco | Critério de Verificação |
|---|---|
| M1.1 | Dois ou mais tenants em produção com SLA vigente |
| M1.2 | Pipeline CI/CD com canary e rollback automático operacionais |
| M1.3 | Assistente RAG implantado com base de conhecimento em pelo menos dois tenants |
| M1.4 | Observabilidade completa: traces, métricas e logs centralizados para todos os serviços |
| M1.5 | Onboarding de novo tenant documentado e executado em menos de 30 dias corridos |
| M1.6 | Runbooks críticos validados em exercício operacional |
54.7 Horizonte 2 — Ano 2: Escala e Consolidação
54.7.1 Contexto do Horizonte
Com a base operacional estabilizada, o segundo horizonte concentra-se em escalar o número de tenants, aprofundar as capacidades funcionais existentes e iniciar a evolução das capacidades de IA para casos de uso mais complexos. A velocidade de onboarding torna-se indicador crítico: a parceria gera valor econômico na proporção da taxa de adoção pelos órgãos.
54.7.2 Capacidades Funcionais
O módulo de ouvidoria digital é implantado com fluxos de manifestação (reclamação, sugestão, elogio, denúncia), prazos legais configuráveis por órgão, notificação automática ao manifestante e relatórios de conformidade. O ciclo de vida de manifestações é integrado ao BPM para garantir rastreabilidade processual.
O portal do cidadão ganha funcionalidades de acompanhamento de histórico consolidado — todas as solicitações e interações do cidadão com todos os órgãos participantes, em uma visão unificada. Essa capacidade depende da maturidade do cadastro único de cidadão e do isolamento correto de dados entre órgãos.
A gestão de campanhas de comunicação — envio segmentado por perfil de cidadão, com controle de frequência, preferência de canal e métricas de engajamento — é introduzida como módulo de Marketing Digital. A segmentação é alimentada pelo Data Lake por tenant, com critérios configuráveis pelo gestor sem dependência de desenvolvimento.
O módulo de agendamento de atendimento presencial ou remoto, integrado ao catálogo de serviços e à agenda dos atendentes, é implantado como extensão do CRM.
54.7.3 Maturidade Arquitetural
O banco de dados por domínio — separação física ou lógica das bases de cada microsserviço — é concluído para os domínios que ainda compartilham banco por razões de implantação inicial. Essa separação é pré-requisito para escalabilidade independente dos serviços de alto volume no Horizonte 3.
O versionamento de APIs externas é formalizado: versões anteriores são mantidas por período mínimo definido em ADR, com canal de comunicação ativo para tenants que precisam migrar. A ausência de versionamento formal em APIs externas é a principal fonte de quebra silenciosa para integrações de órgãos.
O processo de gerenciamento de dívida técnica é operacionalizado: itens de dívida são identificados no backlog, classificados por impacto e urgência, e um percentual do ciclo de desenvolvimento é alocado sistematicamente ao pagamento da dívida mais crítica.
54.7.4 Inteligência Artificial
A classificação automática de solicitações, manifestações e documentos é expandida para todos os tenants, com modelos configuráveis por tenant e feedback loop para melhoria contínua. A precisão de classificação por tenant é monitorada como métrica de qualidade de IA no painel de governança.
O Evaluation Framework — conjuntos de dados de referência, métricas automatizadas de qualidade (RAGAS ou equivalente), regras de release gate — está operacional para todas as capacidades de IA implantadas. Nenhuma mudança em modelo, prompt ou base de conhecimento avança para produção sem passar pelo release gate.
A capacidade de IA para análise de dados é introduzida: o gestor do órgão pode consultar os dados do Data Lake do seu tenant em linguagem natural, com respostas fundamentadas em dados reais e citação das fontes. Essa capacidade é construída sobre o Model Abstraction Layer existente, com ferramentas de acesso controlado ao Data Lake por tenant.
54.7.5 Sustentabilidade Operacional
A automação de tarefas operacionais recorrentes — renovação de certificados, rotação de secrets, validação de backups, limpeza de filas DLQ sem movimento — é implantada como conjunto de jobs automatizados com alertas de falha. Operações que hoje dependem de intervenção manual programada são convertidas em automações verificáveis.
O modelo de custo por tenant é instrumentado: consumo de CPU, memória, storage, volume de mensagens, tokens de IA e chamadas de API são atribuídos ao tenant correspondente. Esse modelo alimenta o mecanismo de cost allocation e é insumo para a revisão do modelo comercial.
54.7.6 Marcos de Maturidade — Ano 2
| Marco | Critério de Verificação |
|---|---|
| M2.1 | Seis ou mais tenants em produção com SLA vigente |
| M2.2 | Módulo de ouvidoria digital implantado em todos os tenants ativos |
| M2.3 | Separação de banco por domínio concluída para todos os microsserviços |
| M2.4 | Evaluation Framework operacional para todas as capacidades de IA em produção |
| M2.5 | Custo por tenant instrumentado e relatado mensalmente |
| M2.6 | Onboarding de novo tenant executado em menos de 15 dias corridos |
54.8 Horizonte 3 — Ano 3: Expansão e Inteligência
54.8.1 Contexto do Horizonte
O terceiro horizonte é o ponto de inflexão entre uma plataforma em crescimento e uma plataforma em operação de escala. Com base madura e tenants consolidados, é possível introduzir capacidades que exigem maior sofisticação arquitetural — agentes de IA, integrações com ecossistema governamental ampliado e análise preditiva. O risco principal deste horizonte é tentar avançar em capacidades avançadas sem que a base operacional tenha a estabilidade necessária para suportá-las.
54.8.2 Capacidades Funcionais
A integração com o Datalake MG e com a MG-API — infraestrutura de dados e APIs do ecossistema governamental de Minas Gerais — é formalizada para os tenants que demandam cruzamento de dados e interoperabilidade com sistemas de outros órgãos estaduais. Os adaptadores de integração são versionados e governados como contratos formais.
O módulo de serviços digitais com assinatura eletrônica é introduzido, permitindo que documentos gerados pela plataforma sejam assinados digitalmente pelo cidadão via certificado digital ou identidade federada GOV.BR, com validade jurídica. Esse módulo é pré-requisito para processos que hoje exigem comparecimento presencial.
A pesquisa de satisfação integrada — CSAT, NPS e avaliação por serviço — é implantada como módulo de experiência do cidadão, com coleta automática ao fim de interações, dashboard de satisfação por órgão e integração com o ciclo de melhoria contínua dos serviços.
O portal de transparência, que disponibiliza indicadores de atendimento, tempos de resposta e volumes de solicitações por serviço em formato acessível ao público, é implantado para os órgãos que optarem por ativá-lo.
54.8.3 Maturidade Arquitetural
A estratégia de escalabilidade horizontal é exercitada em produção: serviços de alto volume — BFF do portal, serviço de CRM, consumidores de RabbitMQ de alto throughput — demonstram capacidade de escalar sob carga mediante testes de carga programados. Os limites de escala são documentados por componente.
O processo de Chaos Engineering é introduzido em escopo controlado: falhas simuladas em componentes não críticos validam os mecanismos de degradação controlada, circuit breaker e fallback. O objetivo não é introduzir instabilidade, mas verificar que os mecanismos de resiliência funcionam antes que uma falha real os acione.
A plataforma de desenvolvimento interno — bibliotecas compartilhadas, templates de microsserviço, guidelines de código, geradores de projeto — é formalizada e documentada. Isso reduz o tempo de inicialização de novos microsserviços e garante consistência de padrões sem dependência de revisor específico.
54.8.4 Inteligência Artificial
Agentes de IA com tool calling são introduzidos para casos de uso em que o assistente precisa executar ações além da geração de texto: consultar status de solicitação, iniciar protocolo, verificar disponibilidade de agendamento. Esses agentes são construídos sobre o Tool Registry e o Tool Execution Gateway descritos no Capítulo 16, com auditoria obrigatória de cada ação executada.
O modelo de análise preditiva é introduzido para gestores de órgão: previsão de volume de demandas, identificação de padrões sazonais, detecção de anomalias no comportamento de atendimento. Esses modelos são construídos sobre o Data Lake por tenant com pipelines de treinamento isolados.
A avaliação de modelos de linguagem locais — executados na infraestrutura da própria plataforma ou em nuvem privada governamental — é conduzida como alternativa aos modelos em nuvem pública para os casos de uso em que restrições de privacidade de dados tornam a transmissão a provedores externos inadequada.
54.8.5 Sustentabilidade Operacional
O FinOps da plataforma é formalizado: custo de infraestrutura, custo de IA e custo de suporte são atribuídos por tenant, com relatório mensal e identificação de oportunidades de otimização. O modelo de rateio é acordado com a PRODEMGE e alimenta as revisões periódicas do modelo comercial.
A plataforma de self-service para administradores de tenant é ampliada: configurações que hoje exigem intervenção da equipe técnica da parceira — alteração de templates de comunicação, configuração de novos serviços, ajuste de regras de BPM — são executáveis pelo administrador do órgão sem abertura de chamado.
54.8.6 Marcos de Maturidade — Ano 3
| Marco | Critério de Verificação |
|---|---|
| M3.1 | Quinze ou mais tenants em produção com SLA vigente |
| M3.2 | Integração com Datalake MG e MG-API operacional em pelo menos dois tenants |
| M3.3 | Agentes de IA com tool calling implantados em contexto controlado |
| M3.4 | Exercício de Chaos Engineering conduzido com relatório documentado |
| M3.5 | Relatório de FinOps por tenant entregue mensalmente |
| M3.6 | Avaliação de modelos locais de IA concluída com decisão documentada via ADR |
54.9 Horizonte 4 — Ano 4: Maturidade e Diferenciação
54.9.1 Contexto do Horizonte
O quarto horizonte é o de maturidade operacional plena. A plataforma atende múltiplos órgãos com SLA estável, a equipe de operação tem processos consolidados, e o volume de dívida técnica acumulada foi gerenciado sistematicamente nos horizontes anteriores. É o horizonte em que diferenciação competitiva — capacidades que não existem em plataformas equivalentes no mercado de governo — se torna o foco.
54.9.2 Capacidades Funcionais
O modelo de serviços integrados interórgãos é introduzido: um único protocolo iniciado pelo cidadão pode envolver múltiplos órgãos participantes da plataforma, com orquestração de BPM cross-tenant e visibilidade unificada ao cidadão. Esse caso de uso exige protocolos de autorização explícita entre tenants e governança específica de dados compartilhados.
A plataforma de APIs públicas é disponibilizada: órgãos participantes podem expor APIs do catálogo de serviços para consumo por portais de terceiros, aplicativos de prefeituras ou sistemas legados de outros entes, com controle de acesso, rate limiting e documentação automaticamente gerada a partir dos contratos internos.
O módulo de People Analytics para gestão da força de trabalho dos órgãos — acompanhamento de desempenho de atendentes, distribuição de carga, identificação de gargalos de capacidade — é introduzido como extensão do CRM para gestores de equipe.
54.9.3 Maturidade Arquitetural
A estratégia de multicloud é avaliada e decidida via ADR: manter provedor único com acordos de portabilidade, ou distribuir cargas entre provedores para reduzir dependência e otimizar custo. A avaliação é conduzida com dados de custo e desempenho reais coletados nos três anos anteriores.
O processo de aposentadoria de componentes legados — versões antigas de APIs, módulos substituídos por versões superiores, dependências externas sem suporte — é formalizado. Cada componente aposentado tem plano de migração comunicado com antecedência mínima de seis meses para os tenants afetados.
A cobertura de testes é auditada por módulo: testes unitários, de integração, de contrato e de ponta a ponta têm metas de cobertura definidas e acompanhadas como métrica de qualidade. Módulos abaixo da meta não recebem novas funcionalidades antes de atingi-la.
54.9.4 Inteligência Artificial
Os modelos locais de IA — se a avaliação do Horizonte 3 for favorável — são introduzidos em produção para capacidades de alto volume e com restrições de privacidade mais severas. O Model Abstraction Layer existente garante que a transição seja transparente para os serviços de negócio consumidores.
O pipeline de fine-tuning de modelos com dados anonimizados do domínio governamental é introduzido em escopo controlado, com governança específica de datasets, auditoria de consentimento e processo de avaliação antes de qualquer modelo ajustado entrar em produção.
A capacidade de IA para análise jurídica assistida — leitura de documentos normativos, identificação de obrigações e prazos, sugestão de adequações processuais — é avaliada como caso de uso especializado para órgãos com demanda específica.
54.9.5 Sustentabilidade Operacional
A plataforma atinge nível de disponibilidade de 99,9% mensal conforme previsto no ADR-1501 — evolução a partir do compromisso inicial de 99,5% após doze meses de estabilização operacional. Esse marco é alcançável porque os quatro eixos de evolução — funcional, arquitetural, IA e operacional — chegam ao Horizonte 4 com maturidade suficiente para suportar o SLA mais exigente.
54.9.6 Marcos de Maturidade — Ano 4
| Marco | Critério de Verificação |
|---|---|
| M4.1 | Vinte e cinco ou mais tenants em produção com SLA vigente |
| M4.2 | Plataforma de APIs públicas disponível para pelo menos três tenants |
| M4.3 | Disponibilidade mensal de 99,9% atingida por três meses consecutivos |
| M4.4 | Decisão sobre multicloud registrada via ADR com dados de custo/desempenho reais |
| M4.5 | Cobertura de testes auditada por módulo com metas formalizadas |
| M4.6 | Modelo local de IA em produção (se ADR favorável) ou decisão documentada de não adoção |
54.10 Horizonte 5 — Ano 5: Consolidação e Legado
54.10.1 Contexto do Horizonte
O quinto horizonte é o de preparação para a continuidade da plataforma além do primeiro ciclo da parceria. As decisões deste horizonte são orientadas por duas perguntas: o que precisa estar solidamente documentado para que a plataforma possa ser operada por qualquer equipe qualificada? E quais capacidades adicionais aumentam o valor da plataforma para um segundo ciclo?
54.10.2 Capacidades Funcionais
A consolidação do portfólio funcional é o foco: capacidades em uso limitado são avaliadas quanto a adoção, custo de manutenção e alinhamento estratégico. Capacidades com baixa adoção e alto custo de sustentação são candidatas a aposentadoria. O portfólio resultante é mais coerente e mais fácil de evoluir.
O módulo de participação cidadã — consultas públicas digitais, votações sobre prioridades de serviço, coleta estruturada de sugestões — é introduzido como capacidade de engajamento para órgãos que conduzem processos participativos.
A integração com sistemas de identidade municipal — para municípios participantes que não operam via GOV.BR estadual — é formalizada como adaptador de identidade configurável por tenant, sem alterar o modelo de IAM da plataforma.
54.10.3 Maturidade Arquitetural
A documentação arquitetural é completada e auditada: todos os serviços têm documentação atualizada de responsabilidade de domínio, contratos de API, esquema de dados, eventos produzidos e consumidos, e runbooks operacionais. Essa documentação é condição para transferência de conhecimento sustentável.
O Modelo de Maturidade Tecnológica da plataforma é avaliado formalmente: capacidades de escalabilidade, segurança, observabilidade, resiliência e DevSecOps são auditadas contra um framework de referência. O resultado é entregue à PRODEMGE como relatório técnico com as áreas de melhoria identificadas para o próximo ciclo.
54.10.4 Inteligência Artificial
As capacidades de IA são avaliadas quanto a maturidade, cobertura de tenants, qualidade medida pelo Evaluation Framework e custo por capacidade. O resultado alimenta o roadmap do próximo ciclo.
O Knowledge Graph — representação estruturada do conhecimento dos órgãos com entidades, relações e atributos — é avaliado como extensão do modelo de RAG atual, capaz de responder perguntas que exigem raciocínio relacional além da recuperação semântica direta.
54.10.5 Sustentabilidade Operacional
A plataforma opera com custo por tenant decrescente ao longo dos cinco anos: a reutilização de componentes, a automação operacional e o aumento de escala reduzem o custo marginal de cada novo tenant abaixo do custo dos tenants iniciais. Esse modelo de economia de escala é documentado e demonstrado com dados reais.
A transferência de conhecimento para equipes da PRODEMGE — prevista no Capítulo 50 — é avaliada e complementada com treinamentos avançados sobre a arquitetura consolidada, os processos operacionais e os mecanismos de evolução da plataforma para o próximo ciclo.
54.10.6 Marcos de Maturidade — Ano 5
| Marco | Critério de Verificação |
|---|---|
| M5.1 | Documentação arquitetural completa e auditada para todos os serviços em produção |
| M5.2 | Avaliação formal de Modelo de Maturidade Tecnológica entregue à PRODEMGE |
| M5.3 | Custo por tenant demonstravelmente inferior ao custo dos primeiros tenants implantados |
| M5.4 | Portfólio funcional revisado com aposentadoria de capacidades identificadas |
| M5.5 | Capacidades de IA avaliadas com relatório de qualidade por capacidade e por tenant |
| M5.6 | Programa de transferência de conhecimento avançado concluído |
54.11 Visão Consolidada do Roadmap
A tabela a seguir consolida os quatro eixos de evolução por horizonte, oferecendo leitura comparativa da trajetória da plataforma ao longo dos cinco anos.
| Eixo | Ano 1 | Ano 2 | Ano 3 | Ano 4 | Ano 5 |
|---|---|---|---|---|---|
| Capacidades Funcionais | CRM, BPM, GED, omnichannel, portal, mobile, catálogo | Ouvidoria, campanhas, agendamento, histórico consolidado | Assinatura digital, interórgãos, transparência, satisfação | APIs públicas, People Analytics, serviços integrados interórgãos | Participação cidadã, integração municipal, portfólio revisado |
| Maturidade Arquitetural | CI/CD, canary, observabilidade, multi-tenancy auditado | Banco por domínio, versionamento de APIs, gestão de dívida técnica | Chaos Engineering, plataforma interna, escalabilidade sob carga | Avaliação multicloud, aposentadoria de componentes, cobertura de testes | Documentação completa, Modelo de Maturidade, portfólio revisado |
| Inteligência Artificial | RAG com isolamento, copiloto de atendimento, avaliação inicial | Classificação automática, Evaluation Framework, análise em linguagem natural | Agentes com tool calling, análise preditiva, avaliação de modelos locais | Fine-tuning em escopo controlado, modelos locais (se aprovados), análise jurídica assistida | Knowledge Graph (avaliação), relatório de qualidade por capacidade |
| Sustentabilidade Operacional | Runbooks validados, onboarding replicável | Automação de operações recorrentes, custo por tenant instrumentado | FinOps formal, self-service ampliado | SLA 99,9% atingido, planos de aposentadoria de componentes | Custo por tenant decrescente, transferência de conhecimento avançada |
54.12 Relação com o SLA e a Operação
O roadmap não é independente dos compromissos operacionais. Três relações são estruturais:
Evoluções respeitam janelas operacionais. Qualquer mudança que afete serviços críticos classificados no Capítulo 53 é executada em janelas acordadas com a PRODEMGE, com notificação antecipada mínima de setenta e duas horas para mudanças planejadas. A violação desse protocolo por urgência comprovada ativa o processo de comunicação de emergência definido no Capítulo 51.
SLA como insumo de priorização. O histórico de cumprimento de SLA alimenta as decisões de roadmap: componentes com recorrência de incidentes ou desvios de disponibilidade têm prioridade de melhoria arquitetural sobre a introdução de novas funcionalidades. Um componente instável não recebe novos recursos antes de ser estabilizado.
SLA evolui com a plataforma. O ADR-1501 prevê a evolução do compromisso de disponibilidade de 99,5% para 99,9% após doze meses de estabilização. Essa evolução é deliberada e baseada na maturidade operacional demonstrada — não é uma concessão automática, mas um compromisso condicionado à maturidade.
54.13 Relação com a Gestão da Evolução
O roadmap define direção e marcos. A Gestão da Evolução da Plataforma — descrita no Capítulo 55 — define o processo pelo qual as iniciativas do roadmap são convertidas em entregas concretas: priorização de backlog, rituais de revisão, critérios de aceite, comunicação com tenants e controle de mudanças.
A distinção é deliberada: o roadmap é estratégico e estável — muda apenas por decisão governada entre PRODEMGE e a parceira. A gestão da evolução é tática e contínua — ajusta-se a cada ciclo de desenvolvimento com base em demandas, capacidade e dados operacionais.
54.14 Riscos e Mitigações
| Risco | Consequência | Mitigação |
|---|---|---|
| Aceleração de roadmap sob pressão comercial | Dívida técnica acumulada compromete horizontes seguintes | Percentual reservado para pagamento de dívida é não negociável no ciclo |
| Dependência de provedor de IA em nuvem | Impacto de mudança de preço ou política do provedor | Model Abstraction Layer e avaliação contínua de alternativas, incluindo modelos locais |
| Onboarding mais lento que o esperado | Receita abaixo da projeção, pressão sobre o modelo | Automação de onboarding como investimento prioritário no Horizonte 1 |
| Evolução funcional desconectada das necessidades dos órgãos | Funcionalidades entregues com baixa adoção | Comitê de roadmap com representação de tenants ativos |
| Mudança regulatória exigindo adaptação arquitetural não planejada | Interrupção do roadmap planejado | Monitoramento jurídico contínuo; reserva de capacidade por ciclo para adequações emergenciais |
| Maturidade de IA insuficiente para casos de uso avançados | Capacidades entregues com qualidade abaixo do aceitável | Evaluation Framework como gate obrigatório; não há produção sem avaliação aprovada |
| Desalinhamento de expectativas entre PRODEMGE e parceira | Conflitos sobre prioridades e entregas | Reuniões de revisão de roadmap com frequência mínima trimestral e ata registrada |
54.15 Decisões Arquiteturais — ADR
| ADR | Tema | Decisão |
|---|---|---|
| ADR-1601 | Horizonte de roadmap como unidade de governança | Cinco horizontes anuais com marcos de maturidade verificáveis; evolução por horizonte é condição para comprometer entregas do horizonte seguinte |
| ADR-1602 | Percentual mínimo de capacidade por ciclo para pagamento de dívida técnica | Mínimo de 20% da capacidade de desenvolvimento em cada ciclo alocado a refatoração, cobertura de testes e documentação |
| ADR-1603 | Critério de gate para capacidades avançadas de IA | Evaluation Framework com resultado aprovado é condição necessária para produção; gate não é negociável por prazo |
| ADR-1604 | Protocolo de aposentadoria de componentes | Notificação mínima de seis meses; coexistência de versão antiga e nova por período definido; remoção somente após confirmação de migração de todos os tenants |
| ADR-1605 | Comitê de revisão de roadmap | Revisão mínima trimestral com PRODEMGE; mudanças de horizonte exigem aprovação formal registrada; mudanças internas de ciclo são de responsabilidade da parceira |
| ADR-1606 | Relação entre SLA e prioridade de roadmap | Componentes com desvio de SLA recorrente têm prioridade máxima de melhoria arquitetural; novas funcionalidades no mesmo componente são bloqueadas até estabilização |
54.16 Rastreabilidade PRODEMGE
Edital CP 001/2026:
- Evolução tecnológica contínua ao longo da vigência da parceria: o roadmap formaliza a trajetória de evolução como compromisso estruturado, não como intenção genérica.
Plano de Negócio (Anexo I):
- Item 3.1.13 — incorporação contínua de novos módulos e funcionalidades ao longo da parceria: os horizontes do roadmap operacionalizam esse compromisso com marcos verificáveis.
- Item 3.4.5 — Evolução e Melhoria Contínua: implementação de novas funcionalidades, atualização tecnológica e adequações a novas normas são cobertos pelos quatro eixos do roadmap.
- Item 5.11 — Estratégia de Evolução da Plataforma: backlog priorizado e compartilhado, governança arquitetural com ADRs, implantação incremental com rollback e monitoramento contínuo são componentes estruturais do roadmap.
Funcionalidades (Anexo III) — impacto na pontuação de 60%:
- Bloco 6 — Infraestrutura e Governança: evolução controlada, versionamento, gestão de mudanças e capacidade de incorporar novas funcionalidades sem comprometer a operação são capacidades de governança avaliadas no Anexo III.
Capacidades (Anexo IV):
- Capacidades técnicas de IA, escalabilidade, observabilidade, DevSecOps e multi-tenancy têm trajetórias de maturidade explícitas em cada horizonte do roadmap.
Sustentabilidade (Anexo V):
- A sustentabilidade técnica da plataforma é garantida pelo roadmap: pagamento sistemático de dívida técnica, documentação contínua, aposentadoria planejada de componentes e custo por tenant decrescente ao longo do ciclo.
54.17 Referências Internas
- Capítulo 5 — Modelo de Negócio: estratégia de evolução da plataforma e modelo de receita por horizonte
- Capítulo 16 — Arquitetura de IA: trajetória de maturidade das capacidades de IA referenciada no roadmap
- Capítulo 40 — DevSecOps: pipeline de entrega contínua que habilita a cadência de evolução do roadmap
- Capítulo 47 — Continuidade de Negócio: RTO/RPO como restrições respeitadas nas janelas de evolução
- Capítulo 51 — Operação: protocolos de janela de manutenção e comunicação de mudanças
- Capítulo 53 — SLA: compromissos de disponibilidade como restrições e insumos de priorização do roadmap
- Capítulo 55 — Gestão da Evolução: processo pelo qual as iniciativas do roadmap são convertidas em entregas
- Capítulo 56 — Governança da Parceria: instâncias de revisão e aprovação do roadmap
- Capítulo 59 — Gestão de Mudanças: processo formal de mudança que governa cada iniciativa do roadmap
54.18 Considerações Finais
O roadmap tecnológico não é uma lista de desejos. É o instrumento pelo qual a parceria transforma sessenta meses de vigência em valor acumulado — para os órgãos participantes, para os cidadãos que utilizam os serviços e para a PRODEMGE como operadora da plataforma.
Três propriedades distinguem um roadmap eficaz de uma declaração de intenções: marcos verificáveis que permitem aferir objetivamente se um horizonte foi atingido; mecanismos de governança que garantem que desvios são identificados e corrigidos antes de comprometer o horizonte seguinte; e a disciplina de não comprometer a base para acelerar o topo.
A plataforma chega ao quinto ano em melhor estado arquitetural, operacional e funcional do que no primeiro — não apesar da evolução, mas por causa de como ela foi conduzida. Essa é a medida de um roadmap bem executado.
54.19 Próximo Capítulo
O Capítulo 55 — Gestão da Evolução da Plataforma — define os processos, rituais e mecanismos de governança pelos quais as iniciativas do roadmap são priorizadas, desenvolvidas, validadas e entregues aos tenants em produção.
54.20 Controle de Versão
| Campo | Valor |
|---|---|
| Documento | Documento Mestre — Plataforma de Relacionamento Digital com o Cidadão |
| Capítulo | 54 — Roadmap Tecnológico |
| Versão | 1.0 |
| Situação | Concluído |
| Última atualização | 17/07/2026 |
Capítulo 53 — SLA — Acordos de Nível de Serviço
Este capítulo formaliza os Acordos de Nível de Serviço da Plataforma de Relacionamento Digital com o Cidadão — o conjunto de compromissos mensuráveis que definem o padrão mínimo aceitável de operação, o que acontece quan…
Capítulo 55 — Gestão da Evolução da Plataforma
Este capítulo define os processos, rituais, critérios e mecanismos de governança pelos quais as iniciativas estratégicas do Roadmap Tecnológico — descritas no Capítulo 54 — são convertidas em entregas concretas: funciona…