Proposal Rationale¶

1. Objetivo¶

Este documento explica por que a proposta de macro-organizacao foi estruturada da forma apresentada em Macro Domain Proposal.

Ele existe para apoiar a revisao do time sobre:

coerencia com o discovery
adequacao ao contexto SaaS
clareza dos limites entre dominios de negocio e capacidades transversais
utilidade da proposta como base para a proxima etapa da inception

Este documento nao trata a proposta como algo ja validado.

Ele apenas explicita os criterios usados para torna-la mais robusta para avaliacao.

2. Principios usados na proposta¶

2.1 Separar produto SaaS de dominio de grant management¶

Uma fonte importante de confusao no desenho atual do produto e misturar:

operacao do produto enquanto servico
capacidades tecnicas compartilhadas
regras do negocio de grant management

Por isso, a proposta separa tres camadas:

control plane saas
shared platform capabilities
business domains

Essa separacao ajuda o time a discutir com mais clareza:

o que e necessario para multi-tenant
o que e compartilhado entre modulos
o que pertence ao ciclo de grant em si

2.2 Explicitar dominios do problema antes de discutir modulos¶

O discovery ja estabelece que o produto deve ser pensado a partir de partes do problema, e nao de portais, APIs ou times.

A proposta segue essa diretriz ao organizar o nucleo de negocio em:

strategy governance and portfolio
planning and funding opportunities
proposal submission and selection
award formalization
project execution and deliverables
finance and disbursements
accountability compliance and audit

Isso ajuda a evitar que a arquitetura nasca presa ao formato atual de:

portal admin
portal publico
modulo de pagamento
modulo de prestacao

2.3 Tornar a concessao formal um limite explicito¶

Um dos principais ajustes feitos foi promover Award Formalization a dominio explicito.

Isso foi importante porque a concessao formal concentra responsabilidades que nao cabem nem em selecao nem em execucao:

termo
aceite
pendencias documentais
vigencia
ativacao

Sem esse limite, ha risco de misturar:

decisao de selecao
situacao juridico-operacional do award
liberacao de execucao e desembolso

2.4 Tornar a governanca institucional visivel¶

O discovery nao descreve apenas o problema do grantor.

Ele tambem destaca:

risco institucional
aprovacoes internas
acompanhamento consolidado
responsabilidades da instituicao receptora

Por isso, a proposta trata Strategy Governance and Portfolio como bloco explicito, em vez de reduzir o topo da cadeia a planejamento de editais.

Esse ajuste ajuda a proposta a cobrir melhor:

grantor
instituicao receptora
portfolio
governanca

2.5 Tratar plataforma compartilhada como capacidade transversal¶

Workflow, forms, documents, notifications, integration hub e master data sao essenciais para a solucao.

Mas eles nao devem ser confundidos com dominios do problema.

Na proposta, esses elementos foram agrupados como Shared Platform Capabilities porque:

servem a varios dominios
podem evoluir com reutilizacao
sao importantes para configurabilidade SaaS
nao devem definir sozinhos o desenho dos bounded contexts

2.6 Incluir configurabilidade como requisito estrutural¶

O contexto do produto exige:

adaptacao ao ambiente institucional inicial
reuso por outras fundacoes
possibilidade de white-label

Isso significa que a proposta precisa considerar desde ja variacoes por tenant em:

identidade
formularios
documentos
politicas
integracoes
saidas regulatorias

Por isso, a proposta inclui explicitamente:

Tenancy and Commercial
Identity Access and Trust
Policy and configuration per tenant
Data exports marts per tenant

3. Como a proposta cobre o discovery¶

3.1 Correspondencia principal¶

Discovery	Proposta
Planning and Funding Opportunities	`Planning and Funding Opportunities`
Proposal Submission and Selection	`Proposal Submission and Selection`
Grant Award Formalization	`Award Formalization`
Project Execution and Deliverables	`Project Execution and Deliverables`
Resource Disbursement and Benefits	`Finance and Disbursements`
Accountability, Compliance and Audit	`Accountability Compliance and Audit`
Institutional Governance and Portfolio	`Strategy Governance and Portfolio`

3.2 Correspondencia com restricoes estrategicas¶

O discovery tambem registra restricoes que nao sao dominios do problema, mas influenciam o desenho do produto:

implantacao inicial em ambiente institucional
evolucao para servico replicavel
tensao entre customizacao local e escala

A proposta responde a isso ao separar:

o que e dominio de grant
o que e capacidade compartilhada
o que e operacao do produto SaaS

4. Como a proposta ajuda no contexto SaaS¶

4.1 Multi-tenant¶

Multi-tenant exige mais do que particionar dados.

Exige tambem:

isolamento
identidade por tenant
configuracao por tenant
analytics por tenant
limites operacionais por tenant

Esses aspectos estao refletidos fora dos dominios de grant management porque sao preocupacoes do produto SaaS.

4.2 White-label¶

White-label exige que a variacao entre clientes nao fique espalhada de forma ad hoc dentro dos dominios.

Por isso a proposta destaca:

branding
configuracoes
templates
politicas

Isso facilita avaliar o que deve ser parametrizavel e o que deve permanecer comum.

4.3 Reducao de acoplamento¶

Ao nomear melhor os limites, a proposta prepara a proxima etapa para discutir:

ownership por contexto
responsabilidades de escrita e leitura
menor sobreposicao entre times

5. O que a proposta ainda nao decide¶

Esta proposta ainda nao define:

numero de servicos
numero de bancos
tecnologia final
estrategia de integracao
BFFs ou gateways
topologia de deploy

Ela serve para alinhar o modelo de entendimento do problema e das capacidades do produto.

6. Criterios para avaliacao pelo time¶

O time pode usar esta proposta como base de avaliacao respondendo:

a separacao entre control plane, platform capabilities e business domains ficou clara
os dominios do discovery estao cobertos sem excesso de sobreposicao
Award Formalization faz sentido como dominio proprio
Strategy Governance and Portfolio cobre bem o papel do grantor e da instituicao receptora
a proposta ajuda ou atrapalha a evolucao para SaaS
a proposta cria um bom ponto de partida para discutir ownership de dados e componentes