Capítulo 9 — Arquitetura de Negócio

9.1 Objetivo do Capítulo

Este capítulo apresenta a Arquitetura de Negócio da Plataforma de Relacionamento Digital com o Cidadão.

Seu objetivo é descrever como a plataforma organiza suas capacidades, participantes, jornadas, serviços públicos digitais, processos institucionais e informações de negócio, estabelecendo a ligação entre:

• os objetivos estratégicos da parceria;
• as necessidades dos órgãos públicos participantes;
• as jornadas do cidadão e dos usuários internos;
• os módulos funcionais da plataforma;
• os domínios de negócio e seus bounded contexts;
• os serviços tecnológicos que sustentam a solução.

A Arquitetura de Negócio define o que a plataforma realiza e para quem, sem antecipar decisões de implementação que pertencem à Arquitetura Funcional (Capítulo 10), à Arquitetura da Plataforma (Capítulo 11) e à Arquitetura de Microsserviços (Capítulo 12).

9.2 Contexto

A plataforma atende diferentes órgãos e entidades públicas, permitindo que cada organização configure e disponibilize seus próprios serviços digitais sem necessidade de reconstruir a solução a cada implantação.

A arquitetura de negócio concilia dois objetivos permanentes:

1. oferecer capacidades corporativas comuns, reutilizáveis por todos os tenants;
2. permitir configurações, processos, serviços, dados e regras específicas de cada órgão.

Esses dois objetivos estão em tensão natural e sua gestão é um dos papéis centrais desta arquitetura: maximizar o reuso sem sacrificar a autonomia operacional dos órgãos, e garantir autonomia sem fragmentar o produto.

9.3 Princípios da Arquitetura de Negócio

9.3.1 Orientação ao Cidadão

Os serviços são estruturados a partir das necessidades e jornadas dos cidadãos. A experiência digital não reproduz a estrutura administrativa interna dos órgãos — ela é desenhada para quem precisa do serviço, não para quem o oferece.

9.3.2 Reutilização de Capacidades

Capacidades comuns — autenticação, protocolo, comunicação, documentos, agendamento e acompanhamento — são compartilhadas entre diferentes serviços. Nenhum domínio reimplementa o que outro já oferece.

9.3.3 Configuração por Tenant

Cada órgão configura seus serviços, processos, usuários, canais, comunicações e regras dentro de seu próprio contexto organizacional, sem afetar outros tenants.

9.3.4 Integração entre Canais

Uma interação iniciada em um canal pode ser consultada e, quando a regra do serviço permite, continuada por outro canal com contexto preservado.

9.3.5 Processos Orientados por Eventos

Ocorrências relevantes de negócio produzem eventos que acionam processos, comunicações, integrações e atualizações analíticas, desacoplando os domínios produtores dos consumidores.

9.3.6 Rastreabilidade

As ações realizadas na plataforma são rastreáveis, especialmente aquelas relacionadas a solicitações, documentos, decisões, comunicações, consentimentos e alterações cadastrais.

9.3.7 Evolução Incremental

Novos serviços, etapas, integrações e regras são incorporados sem necessidade de reconstrução integral da solução.

9.3.8 Segregação Organizacional

Dados, regras, documentos, processos, usuários e configurações de um tenant não são acessíveis por outro tenant sem autorização expressa e fundamento.

9.3.9 Configuração antes de Customização

Necessidades específicas dos órgãos são atendidas por parametrização, modelagem de processos e composição de capacidades. Customizações exclusivas que fragmentam o produto são evitadas.

9.3.10 Atendimento Humano e Digital Integrados

Atendimento digital, atendimento humano e automação não são silos independentes. Todos compartilham o contexto permitido da jornada do cidadão.

9.4 Participantes do Ecossistema de Negócio

9.5 Mapa de Capacidades de Negócio

As capacidades representam o que a plataforma precisa ser capaz de fazer, independentemente da tecnologia. O mapa a seguir organiza essas capacidades por agrupamento temático.

Plataforma de Relacionamento Digital com o Cidadão
│
├── Gestão de Identidade
│   ├── Tenants e configurações
│   ├── Usuários e credenciais
│   ├── Perfis e permissões
│   ├── Federação GOV.BR
│   └── Consentimentos
│
├── Relacionamento com o Cidadão
│   ├── Cadastro unificado
│   ├── Visão 360º do cidadão
│   ├── Histórico de interações
│   ├── Segmentação
│   └── Preferências e privacidade
│
├── Serviços Públicos Digitais
│   ├── Catálogo de serviços
│   ├── Formulários configuráveis
│   ├── Requisitos e documentos exigidos
│   ├── Disponibilidade por canal
│   └── Publicação e versionamento
│
├── Solicitações e Protocolos
│   ├── Abertura e validação
│   ├── Geração de protocolo único
│   ├── Acompanhamento de status
│   ├── Pendências e complementações
│   └── Histórico auditável
│
├── Processos e Workflow (BPM)
│   ├── Modelagem de processos
│   ├── Execução e instâncias
│   ├── Distribuição de tarefas
│   ├── Regras e condições
│   ├── SLA e prazos
│   └── Monitoramento de execução
│
├── Atendimento e CRM
│   ├── Filas e distribuição
│   ├── Atendimento omnichannel
│   ├── Ficha unificada do cidadão
│   ├── Transferências e encaminhamentos
│   └── Supervisão de equipes
│
├── Comunicação Omnichannel
│   ├── Mensagens transacionais
│   ├── E-mail, SMS, push, WhatsApp
│   ├── Campanhas segmentadas
│   ├── Templates e versionamento
│   └── Preferências e consentimentos
│
├── Gestão Documental (ECM/GED)
│   ├── Armazenamento e metadados
│   ├── Classificação e indexação
│   ├── Versionamento
│   ├── Busca avançada
│   └── Controle de acesso e auditoria
│
├── Agendamentos
│   ├── Cadastro de agendas e unidades
│   ├── Disponibilidade e calendários
│   ├── Marcação e confirmação
│   ├── Remarcação e cancelamento
│   └── Notificações relacionadas
│
├── Ouvidoria e Manifestações
│   ├── Registro de manifestações
│   ├── Triagem e classificação
│   ├── Encaminhamento e resposta
│   ├── Controle de prazos
│   └── Anonimato quando aplicável
│
├── Avaliação e Satisfação
│   ├── Coleta de avaliações
│   ├── Indicadores de qualidade
│   └── Melhoria contínua
│
├── Dados e Inteligência
│   ├── Analytics e dashboards
│   ├── Relatórios e exploração
│   ├── Qualidade de dados
│   ├── Data Lake por tenant
│   ├── IA e assistentes
│   └── RAG e busca semântica
│
└── Administração e Governança
    ├── Configuração de tenants
    ├── Gestão de integrações
    ├── Monitoramento operacional
    ├── Auditoria
    └── Centro de comando

9.6 Classificação das Capacidades

Capacidades Centrais

Representam o núcleo de valor da plataforma e são priorizadas no roadmap:

• relacionamento com o cidadão;
• catálogo de serviços;
• solicitações e protocolos;
• processos e workflow;
• atendimento e CRM;
• comunicação omnichannel;
• gestão documental;
• dados e inteligência.

Capacidades Habilitadoras

Permitem que as capacidades centrais operem com segurança e integração:

• identidade e acesso (IAM + GOV.BR);
• multi-tenancy e configuração por órgão;
• APIs e mensageria;
• integrações com sistemas externos;
• auditoria e observabilidade.

Capacidades de Suporte

Sustentam a operação e evolução contínua:

• administração e configuração;
• monitoramento operacional;
• gestão de SLA;
• gestão de mudanças;
• gestão de conhecimento.

9.7 Domínios de Negócio

A decomposição a seguir representa os domínios de negócio da plataforma com seus bounded contexts iniciais. Um domínio pode ser implementado por um ou mais componentes técnicos. A decomposição técnica em microsserviços é detalhada no Capítulo 12.

9.8 Domínio 1 — Tenant e Administração Institucional

Objetivo

Gerenciar as organizações participantes, suas configurações e seus limites operacionais.

Entidades Principais

Tenant, órgão, unidade organizacional, configuração institucional, identidade visual, domínio de acesso, canal habilitado, parâmetros operacionais.

Responsabilidades

• criar e manter tenants;
• configurar dados institucionais e identidade visual;
• habilitar módulos e canais por tenant;
• definir parâmetros e limites contratados;
• associar administradores ao tenant;
• configurar integrações específicas do órgão.

Regras Essenciais

• todo tenant possui identificador único e imutável;
• alterações críticas são auditadas;
• configurações de um tenant não afetam outro;
• desativação preserva dados conforme política de retenção;
• módulos são utilizados somente quando habilitados para o tenant.

9.9 Domínio 2 — Identidade e Acesso

Objetivo

Gerenciar identidades, autenticação, perfis e autorização na plataforma.

Entidades Principais

Usuário, credencial, identidade federada, perfil, papel, permissão, sessão, tenant, vínculo organizacional, consentimento.

Responsabilidades

• cadastrar usuários locais com credenciais próprias;
• autenticar por IAM próprio ou federar via GOV.BR;
• controlar sessões e expiração;
• atribuir e revogar perfis e permissões;
• manter vínculos entre usuário, tenant e unidade;
• registrar eventos de autenticação e acesso;
• controlar bloqueio, inativação e recuperação.

Regras Essenciais

• um usuário interno deve estar vinculado a pelo menos um tenant;
• perfis possuem escopo explícito (tenant, unidade, recurso, operação);
• autorização considera usuário + tenant + perfil + recurso + operação;
• a autenticação GOV.BR não concede automaticamente permissões administrativas;
• credenciais não são compartilhadas entre tenants;
• acessos privilegiados possuem auditoria reforçada.

9.10 Domínio 3 — Cadastro do Cidadão

Objetivo

Manter a representação consolidada do cidadão e os dados necessários ao relacionamento digital com os órgãos.

Entidades Principais

Cidadão, dados básicos, documentos identificadores, meios de contato, endereços, preferências, consentimentos, empresas representadas, identidade GOV.BR, histórico de alterações.

Responsabilidades

• manter dados cadastrais com origem registrada;
• consolidar informações de diferentes fontes;
• registrar consentimentos e preferências;
• oferecer visão 360º ao atendente autorizado;
• controlar acesso por finalidade e perfil;
• tratar duplicidades;
• auditar alterações sensíveis.

Regras Essenciais

• cada dado possui origem registrada (declarado, verificado, externo);
• dados oficiais são diferenciados de dados declarados;
• alterações são auditadas com data e responsável;
• acesso respeita finalidade e perfil;
• a visão do cidadão pode variar por tenant conforme base legal;
• dados pessoais observam LGPD em toda a cadeia de tratamento.

9.11 Domínio 4 — Catálogo de Serviços

Objetivo

Gerenciar os serviços públicos digitais disponibilizados pelos órgãos participantes.

Entidades Principais

Serviço, categoria, órgão responsável, versão, requisitos, documentos exigidos, formulário, canal disponível.

Responsabilidades

• criar e versionar serviços;
• publicar e despublicar com controle de ciclo de vida;
• definir requisitos e documentos exigidos;
• associar formulários e processos;
• disponibilizar por canal configurado.

Ciclo de Vida do Serviço

Rascunho → Em revisão → Aprovado → Publicado → Suspenso → Descontinuado

Regras Essenciais

• somente versões publicadas são apresentadas ao cidadão;
• alterações que impactem solicitações em andamento preservam a versão aplicada;
• cada serviço possui tenant e órgão responsáveis;
• requisitos e documentos são exibidos antes da confirmação da solicitação.

9.12 Domínio 5 — Solicitações e Protocolos

Objetivo

Gerenciar a formalização, o acompanhamento e o encerramento das demandas dos cidadãos.

Entidades Principais

Solicitação, protocolo, requerente, serviço e formulário submetido, etapa, situação, pendência, comentário, documento, histórico, responsável.

Responsabilidades

• iniciar e validar solicitações;
• gerar protocolo único;
• controlar estados e transições;
• solicitar e receber complementações;
• manter histórico auditável;
• integrar com processos e sistemas externos;
• comunicar mudanças de situação ao cidadão.

Estados de Referência

Rascunho → Submetida → Recebida → Em análise
→ Aguardando complementação → Em processamento
→ Deferida/Concluída | Indeferida | Cancelada

Os estados são referência arquitetural. Serviços específicos podem definir ciclos de vida próprios.

Regras Essenciais

• todo protocolo é único no escopo definido pela plataforma;
• o cidadão visualiza apenas o histórico permitido pelo perfil;
• alterações de situação registram data, origem e responsável;
• documentos são associados à solicitação e ao tenant;
• transições podem acionar eventos RabbitMQ;
• a solicitação preserva a versão do serviço e do formulário utilizados.

9.13 Domínio 6 — Processos e Workflow (BPM)

Objetivo

Modelar, executar e monitorar processos associados aos serviços públicos digitais.

Entidades Principais

Definição de processo, versão, etapa, transição, regra, instância, tarefa, responsável, grupo, SLA, evento, variável de processo.

Responsabilidades

• modelar e versionar processos;
• publicar definições;
• iniciar instâncias a partir de solicitações ou eventos;
• distribuir tarefas por perfil ou grupo;
• executar transições e regras;
• controlar prazos e violações de SLA;
• acionar integrações e serviços externos;
• monitorar instâncias e identificar gargalos.

Regras Essenciais

• processos em execução mantêm a versão em que foram iniciados;
• alterações de fluxo não corrompem instâncias ativas;
• tarefas possuem responsáveis ou critérios de distribuição definidos;
• ações automáticas são idempotentes quando necessário;
• decisões automatizadas são auditáveis;
• processos respeitam o tenant de origem.

9.14 Domínio 7 — Atendimento e CRM

Objetivo

Centralizar o atendimento ao cidadão e manter o histórico consolidado das interações autorizadas.

Entidades Principais

Atendimento, interação, conversa, canal, fila, atendente, cidadão, protocolo, encaminhamento, classificação, nota de atendimento.

Responsabilidades

• receber e distribuir interações;
• identificar o cidadão e recuperar contexto permitido;
• registrar conversas e encaminhamentos;
• vincular atendimentos a protocolos;
• transferir sem perda de contexto;
• coletar avaliação ao encerrar;
• permitir supervisão em tempo real.

Regras Essenciais

• histórico respeita tenant e perfil do atendente;
• dados sensíveis possuem acesso restrito;
• transferência preserva o contexto da interação;
• cada interação identifica canal, data e responsável;
• atendimento pode gerar solicitação ou vincular-se a uma já existente;
• classificação pode ser manual ou apoiada por IA;
• encerramento registra motivo e resultado.

9.15 Domínio 8 — Comunicação Omnichannel

Objetivo

Gerenciar comunicações transacionais, institucionais e segmentadas em múltiplos canais.

Entidades Principais

Mensagem, comunicação, campanha, destinatário, segmento, canal, template, consentimento, preferência, tentativa, entrega, retorno.

Responsabilidades

• enviar notificações transacionais automáticas;
• receber e tratar interações de cidadãos;
• gerenciar templates com versionamento;
• respeitar preferências e consentimentos;
• executar campanhas segmentadas;
• registrar entregas e processar falhas;
• consolidar métricas de engajamento.

Canais

Portal web, aplicativo mobile, e-mail (PRO SMTP ou equivalente), SMS, push (iOS e Android), WhatsApp Business ou equivalente.

Regras Essenciais

• comunicações possuem tenant e finalidade registrados;
• canais transacionais obrigatórios são diferenciados de campanhas opcionais;
• preferências e consentimentos são considerados quando aplicáveis;
• falhas permitem retentativa conforme política definida;
• entregas por fornecedores externos são rastreadas.

9.16 Domínio 9 — Gestão Documental (ECM/GED)

Objetivo

Gerenciar documentos relacionados a cidadãos, serviços, solicitações e processos.

Entidades Principais

Documento, arquivo, versão, metadado, categoria, classificação, permissão, vínculo, retenção, assinatura, histórico.

Responsabilidades

• receber e validar arquivos;
• armazenar com metadados e hash de integridade;
• classificar e indexar para busca;
• versionar sem sobrescrever versões anteriores;
• associar documentos a solicitações e processos;
• controlar acesso por perfil e finalidade;
• auditar operações documentais;
• integrar com solução GED externa quando aplicável.

Regras Essenciais

• documentos possuem tenant e proprietário institucional;
• versões anteriores são preservadas com rastreabilidade;
• acesso considera perfil, finalidade e vínculo;
• exclusão respeita retenção legal e políticas do tenant;
• documentos enviados à IA observam autorização e isolamento por tenant.

9.17 Domínio 10 — Agendamentos

Objetivo

Permitir a marcação de atendimentos ou serviços que exigem data, horário e unidade.

Entidades Principais

Agenda, unidade, serviço, recurso, data, horário, capacidade, agendamento, requerente, situação.

Responsabilidades

• disponibilizar horários por unidade e serviço;
• reservar vagas com controle de concorrência;
• confirmar, remarcar e cancelar;
• notificar o cidadão sobre confirmações e lembretes;
• associar agendamento ao serviço e ao cidadão.

Regras Essenciais

• uma vaga não pode ser confirmada simultaneamente para dois usuários;
• reserva temporária expira automaticamente quando não confirmada;
• horários respeitam calendário, capacidade e indisponibilidades;
• alterações geram eventos e comunicações.

9.18 Domínio 11 — Ouvidoria e Manifestações

Objetivo

Gerenciar manifestações dos cidadãos e seu tratamento institucional.

Tipos de Manifestação

Reclamação, denúncia, solicitação, sugestão, elogio, pedido de informação.

Responsabilidades

• registrar manifestação com ou sem identificação;
• classificar e encaminhar ao setor responsável;
• acompanhar tratamento e prazos;
• registrar resposta e notificar o cidadão;
• preservar confidencialidade e anonimato quando aplicável;
• medir satisfação com o tratamento recebido.

Regras Essenciais

• tratamento preserva confidencialidade e anonimato conforme o tipo;
• perfis com acesso a manifestações são restritos;
• prazos são controlados com alertas automáticos;
• a integração com MG-Ouv é mediada por adaptador específico.

9.19 Domínio 12 — Avaliação e Satisfação

Objetivo

Coletar e analisar a percepção do cidadão sobre serviços e atendimentos para apoiar a melhoria contínua.

Responsabilidades

• solicitar avaliação após pontos-chave da jornada;
• coletar nota e comentário;
• associar avaliação ao contexto (serviço, canal, protocolo);
• consolidar indicadores de satisfação por tenant;
• disponibilizar resultados para gestores;
• identificar tendências.

9.20 Domínio 13 — Segmentação e Campanhas

Objetivo

Permitir a definição de grupos de cidadãos e a execução de comunicações direcionadas.

Responsabilidades

• criar segmentos por critérios cadastrais, comportamentais e contextuais;
• isolar segmentos por tenant;
• criar, aprovar, executar e acompanhar campanhas;
• medir entrega e engajamento;
• respeitar consentimentos e preferências de comunicação.

Regras Essenciais

• segmentação respeita finalidade e base legal;
• critérios são auditáveis;
• dados sensíveis possuem restrição de uso;
• campanhas possuem aprovação antes da execução;
• dados pessoais observam minimização e LGPD.

9.21 Domínio 14 — Dados, Analytics e Qualidade

Objetivo

Consolidar, analisar e disponibilizar dados operacionais e analíticos para gestão e tomada de decisão.

Responsabilidades

• ingerir eventos de negócio no Data Lake por tenant;
• disponibilizar dashboards com indicadores operacionais;
• oferecer exploração de dados e relatórios;
• monitorar e tratar qualidade dos dados;
• manter linhagem e rastreabilidade;
• apoiar componentes de IA com dados históricos.

Regras Essenciais

• dados mantêm tenant e origem registrados;
• indicadores possuem definição formal e documentada;
• dados operacionais e analíticos permanecem separados;
• acesso analítico respeita perfis e finalidade;
• dados pessoais observam minimização;
• ingestões são idempotentes quando necessário.

9.22 Domínio 15 — Inteligência Artificial

Objetivo

Oferecer capacidades de inteligência de forma controlada, governada e reutilizável pelos demais domínios.

Capacidades

Assistência conversacional, busca semântica, classificação de intenções, recomendação de serviços, sumarização, extração de informações estruturadas, apoio ao roteamento de atendimento, análise de tendências.

Responsabilidades

• receber requisições dos domínios com contexto de tenant validado;
• aplicar políticas de acesso e quotas;
• selecionar provedor e modelo conforme configuração;
• recuperar contexto via RAG da base de conhecimento do tenant;
• aplicar guardrails de segurança e privacidade;
• registrar métricas de consumo por tenant;
• retornar resposta com rastreabilidade técnica.

Regras Essenciais

• toda requisição possui contexto de tenant validado;
• bases de conhecimento são isoladas por tenant;
• dados sensíveis são controlados antes do envio a modelos;
• respostas distinguem conteúdo gerado de dados oficiais quando necessário;
• ações transacionais dependem de confirmação e autorização fora da IA;
• prompts e configurações são versionados;
• provedores permanecem desacoplados das aplicações de negócio.

9.23 Domínio 16 — Integrações e Interoperabilidade

Objetivo

Permitir que a plataforma interaja com sistemas externos de forma padronizada, rastreável e desacoplada.

Responsabilidades

• gerenciar configurações de integrações por tenant;
• mediar comunicação com sistemas governamentais via adaptadores;
• expor APIs documentadas e versionadas;
• publicar e consumir eventos RabbitMQ;
• monitorar saúde e falhas;
• reprocessar mensagens com falha de forma controlada.

Regras Essenciais

• integrações não são implementadas nos canais;
• cada integração possui adaptador específico com versionamento;
• falhas são tratadas com retentativa, DLQ e alerta;
• o tenant de origem é propagado nas chamadas externas.

9.24 Jornadas Corporativas Prioritárias

As jornadas a seguir integram múltiplos domínios e constituem o núcleo de valor da plataforma.

Jornada 1 — Descoberta e Solicitação de Serviço

Cidadão acessa canal
    │
    ▼
Pesquisa ou recebe recomendação (IA / Catálogo)
    │
    ▼
Consulta detalhe e requisitos
    │
    ▼
Autentica quando necessário (IAM / GOV.BR)
    │
    ▼
Preenche formulário e anexa documentos
    │
    ▼
Confirma solicitação
    │
    ▼
Protocolo único gerado
    │
    ▼
Processo iniciado via evento RabbitMQ
    │
    ▼
Cidadão recebe confirmação pelo canal preferido

Domínios: Identidade, Cadastro, Catálogo, Solicitações, Documentos, BPM, Comunicação, IA.

Jornada 2 — Tratamento de Solicitação

Solicitação recebida
    │
    ▼
Classificação (manual ou IA)
    │
    ▼
Instância de processo criada
    │
    ▼
Tarefa distribuída
    │
    ▼
Análise → Complementação necessária?
    ├─ Sim → Solicitar ao cidadão → Aguardar → Retornar
    └─ Não → Decisão ou execução
    │
    ▼
Atualizar protocolo e comunicar cidadão
    │
    ▼
Concluir com registro auditável

Domínios: Solicitações, BPM, Atendimento/CRM, Documentos, Comunicação, Integrações, Auditoria, IA.

Jornada 3 — Atendimento Omnichannel

Interação recebida (portal, e-mail, chat, WhatsApp...)
    │
    ▼
Identificar canal e cidadão
    │
    ▼
Recuperar contexto permitido
    │
    ▼
Assistente resolve?
    ├─ Sim → Responde e registra
    └─ Não → Encaminhar para fila humana
              │
              ▼
              Atendente assume com contexto preservado
              │
              ▼
              Orienta, registra ou abre solicitação
              │
              ▼
              Conclui e coleta avaliação

Domínios: CRM/Atendimento, Comunicação, Cadastro, Identidade, Solicitações, IA, Satisfação.

Jornada 4 — Agendamento de Atendimento

Cidadão seleciona serviço agendável
    │
    ▼
Escolhe unidade e visualiza horários
    │
    ▼
Seleciona data e horário
    │
    ▼
Confirma (vaga reservada sem conflito)
    │
    ▼
Recebe protocolo e lembrete automático
    │
    ▼
(Opcional) Remarca ou cancela

Domínios: Agendamentos, Catálogo, Comunicação, Identidade.

Jornada 5 — Ingestão no Data Lake e Geração de Insights

Evento de negócio produzido
    │
    ▼
Publicado no RabbitMQ com tenantId e correlationId
    │
    ▼
Consumidor de ingestão envia ao Data Lake do tenant
    │
    ▼
Analytics consolida indicadores
    │
    ▼
IA enriquece RAG com dados históricos
    │
    ▼
Gestor visualiza dashboards atualizados

Domínios: Todos os produtores de eventos, RabbitMQ, Dados/Analytics, IA.

9.25 Relação entre Domínios

Os domínios se relacionam por contratos estáveis — APIs e eventos. Nenhum domínio acessa diretamente os dados de outro.

9.26 Relação com a Arquitetura Funcional

9.27 Benefícios da Arquitetura de Negócio

• visão comum entre negócio e tecnologia como fundamento de todas as decisões;
• separação clara de responsabilidades com bounded contexts identificados;
• base para decomposição em microsserviços (Capítulo 12);
• rastreabilidade direta entre requisitos do edital e domínios responsáveis;
• suporte a configurações específicas por órgão sem fragmentar o produto;
• redução de duplicidade entre canais e domínios;
• evolução incremental sem redesenho completo;
• fonte de verdade definida por domínio com governança explícita;
• base objetiva para priorização do roadmap.

9.28 Riscos e Mitigações

9.29 Decisões Arquiteturais a Registrar

9.30 Considerações Finais

A Arquitetura de Negócio é o elo entre as necessidades dos órgãos e cidadãos e as decisões técnicas que serão tomadas nos capítulos seguintes. Ela garante que toda escolha arquitetural — de decomposição, de dados, de integração ou de segurança — possa ser rastreada a uma necessidade de negócio identificada e não a uma preferência tecnológica isolada.

O Capítulo 10 transforma esses domínios em módulos funcionais com interfaces de usuário, APIs, eventos, dados e métricas definidos.

9.31 Controle de Versão

9.32 Rastreabilidade PRODEMGE

• [PNR] — Plano de Negócio Referencial: relacionamento e atendimento ao cidadão, comunicação multicanal, gestão de jornadas, BPM, serviços digitais, gestão documental, dados, IA, integração, segurança, governança, multi-tenancy, implantação e evolução contínua.
• [ANX-III] — Planilha de Qualificação de Funcionalidades: os domínios estabelecem a base de negócio para os seis blocos funcionais — Relacionamento e Atendimento, BPM, ECM/GED, Dados e Analytics, Integração, e Infraestrutura e Governança.
• [ANX-IV] — Planilha de Qualificação de Capacidades: os domínios de IA, integração, identidade e dados correspondem às capacidades avaliadas no Anexo IV.
• [ANX-V] — Planilha de Qualificação de Sustentabilidade: configuração antes de customização, evolução incremental, segregação e governança de dados atendem aos critérios de sustentabilidade.
• [EDITAL] — Edital CP001/2026: a arquitetura de negócio demonstra aderência ao objeto da parceria e à abrangência funcional esperada.