Case: Governança de acessos
GOVERNANÇA · PLATAFORMA B2B · PRODUCT ARCHITECTURE
Como transformei
produtos independentes
em uma plataforma
multiempresa
Cada produto gerenciava identidade e acessos de forma independente.
Estruturei uma arquitetura compartilhada de governança que conectou
empresas, usuários, papéis e permissões — e depois passou a suportar
5 produtos utilizando o mesmo modelo de identidade e autorização
.
PAPEL
Product Architecture
Discovery
Product Strategy
Facilitação
ESCOPO
SSO & IAM
Multiempresa
Papéis & Permissões
Governança de Acessos
Feature Management
ENTREGÁVEIS
Arquitetura de Identidade
Modelo de Governança
Modelo de Papéis &
Permissões
Fluxos de Administração
Arquitetura de Navegação
Princípios de Governança
FRAMEWORKS & FERRAMENTAS
Benchmark
Systems Mapping
MoSCoW
Arquitetura da Informação
Figma
Miro
IMPACTO
5 produtos
passaram a compartilhar o mesmo
modelo de identidade e autorização.
1 arquitetura
reutilizada entre diferentes produtos da
plataforma.
1 identidade
compartilhada, mantendo autonomia para
cada produto.
CONTEXTO
O crescimento da plataforma tornou
a gestão descentralizada
insustentável
Cada produto administrava sua própria autenticação, usuários e regras de acesso. Esse modelo
funcionava enquanto as soluções eram independentes, mas começou a gerar duplicidade e
complexidade à medida que a operação evoluiu para uma plataforma multiempresa.
Onboarding, offboarding e alterações de acesso precisavam ser tratados em diferentes sistemas.
A expansão da plataforma exigia uma base comum de identidade e governança.
O problema não era criar mais um login.
Era impedir que cada novo produto
precisasse reconstruir sua própria gestão
de acessos.
ANTES
Produto A → identidade própria
Produto B → identidade própria
Produto C → identidade própria
DEPOIS
Identidade & Governança compartilhada
Produto 01
Produto 02
Produto 03
Produto 04
Produto 05
DESAFIO
Como compartilhar identidade sem
retirar a autonomia dos produtos?
Centralizar tudo criaria um novo problema: produtos diferentes possuíam contextos,
funcionalidades e regras próprias.
A arquitetura precisava conciliar duas forças.
Governança compartilhada
Identidade, empresas e autorizações
precisavam seguir uma lógica comum.
Autonomia de produto
Cada produto deveria continuar responsável
por sua experiência e regras de negócio.
A questão deixou de ser apenas sobre SSO e passou a ser sobre
onde deveria viver cada responsabilidade da plataforma.
DISCOVERY
O benchmark ajudou a separar
identidade, contexto e permissão
Antes de modelar a solução, analisei produtos que já lidavam com estruturas complexas de
organizações, usuários, papéis e múltiplos ambientes.
Google Workspace
Foi a principal referência para entender como organizações e produtos poderiam coexistir sob
uma mesma identidade.
PRINCIPAIS APRENDIZADOS:
identidade compartilhada entre produtos;
administração centralizada;
troca de contexto sem novo login;
navegação entre produtos por um ponto único de entrada.
Discord
Usei o Discord para estudar uma lógica diferente: ambientes separados, papéis reutilizáveis e
permissões organizadas por contexto.
PRINCIPAIS APRENDIZADOS:
papéis agrupam permissões;
identidade permanece a mesma entre ambientes;
permissões mudam conforme o contexto;
diferentes espaços podem compartilhar a mesma conta.
Google Ad Manager
O Google Ad Manager ajudou a observar como produtos enterprise organizam hierarquias,
acessos e múltiplos níveis de administração.
PRINCIPAIS APRENDIZADOS:
governança por níveis;
separação entre acesso e operação;
administração centralizada com diferentes graus de autonomia.
O padrão se repetia: identidade não precisava pertencer ao produto.
Se cada produto continuasse sendo responsável por autenticação, usuários e permissões, a plataforma continuaria replicando o mesmo problema.
A direção passou a ser transformar identidade e autorização em capacidades compartilhadas.
PRIORIZAÇÃO
Nem tudo precisava ser resolvido no
primeiro ciclo
Usei MoSCoW para separar o que era essencial para sustentar a arquitetura do que poderia
evoluir depois.
MUST HAVE
Identidade compartilhada
Empresas
Usuários
Papéis
Permissões
SSO
SHOULD HAVE
Gestão multiempresa
Administração centralizada
Navegação entre produtos
COULD HAVE
Feature Management
Maior granularidade de permissões
Novas regras de contexto
WON'T HAVE — NAQUELE MOMENTO
Automatizações e regras avançadas
que aumentariam a complexidade
antes da validação da arquitetura
base.
ARQUITETURA
Modelei empresas, usuários, papéis
e produtos como entidades
independentes
A partir dos padrões observados, estruturei o modelo separando
identidade, autorização e
contexto de negócio
. A intenção era evitar que a entrada de um novo produto exigisse remodelar
toda a camada de acesso.
DECISÕES
Três decisões tornaram o modelo
reutilizável
1. Identidade deveria pertencer à
empresa, não ao produto
Uma pessoa passou a manter uma
única identidade, enquanto seus
acessos poderiam variar conforme
produto e contexto.
TRADE-OFF
A modelagem inicial ficou mais complexa.
GANHO
Novos produtos poderiam reutilizar a
mesma identidade.
2. Papéis deveriam agrupar
permissões
Em vez de configurar cada usuário
isoladamente, papéis passaram a
representar conjuntos reutilizáveis de
acessos.
TRADE-OFF
Era necessário criar uma camada adicional
de governança.
GANHO
A administração deixava de depender de
configurações individuais.
3. Autorização deveria ser
compartilhada; experiência, não
Cada produto continuaria controlando
sua interface e suas regras de negócio,
mas utilizaria uma referência comum
para determinar o que cada usuário
poderia acessar.
TRADE-OFF
Precisávamos definir claramente a
fronteira entre plataforma e produto.
GANHO
Governança comum sem transformar
todos os produtos em uma única aplicação.
NAVEGAÇÃO ENTRE PRODUTOS
A arquitetura deixou de
atender um produto e virou
uma capacidade
compartilhada da
plataforma
Além da arquitetura de acesso, havia um problema de navegação: se o
usuário possuía acesso a diferentes produtos, ele precisava conseguir
alternar entre eles sem sentir que estava entrando em sistemas
desconectados.
A referência veio do padrão do Google Workspace.
Criamos um ponto único de entrada para os produtos disponíveis ao
usuário, permitindo trocar de contexto mantendo a mesma identidade.
GOVERNANÇA
A plataforma passou a decidir quem
pode acessar o quê — sem controlar
como cada produto funciona
A separação entre identidade, autorização e experiência criou uma camada comum de
governança enquanto os produtos permaneceram independentes para evoluir suas próprias
interfaces e regras de negócio.
Também separamos a gestão de acesso da disponibilidade de funcionalidades.
Assim, quem pode acessar um produto e quais recursos estão
disponíveis naquele contexto deixaram de ser o mesmo problema.
IDENTIDADE
Quem é?
AUTORIZAÇÃO
O que pode acessar?
PRODUTO
Como a experiência funciona?
+ FEATURE MGT
O que está disponível neste contexto?
ESCALA
Arquitetar uma plataforma é decidir o
que precisa ser compartilhado
O sinal mais importante veio depois da definição inicial: o mesmo modelo foi reutilizado para
integrar cinco produtos com necessidades diferentes ao fluxo comum de gerenciamento de
acessos e autorização.
Uma fundação compartilhada, diferentes experiências.
RESULTADOS
O que passou a ser possível
5 produtos integrados
O mesmo modelo de identidade e autorização passou a atender diferentes produtos.
Identidade reutilizável
Usuários deixaram de depender de uma identidade específica para
cada produto.
Governança centralizada
Empresas, papéis e permissões passaram a seguir uma estrutura
compartilhada.
Produtos desacoplados
Cada solução preservou autonomia sobre sua experiência e regras
de negócio.
Base para expansão
Novos módulos poderiam partir da arquitetura existente em vez de
reconstruir a camada de identidade.
APRENDIZADO
Arquitetar uma plataforma é decidir o
que precisa ser compartilhado
Esse projeto mudou minha forma de pensar arquitetura de produto.
O desafio não estava apenas nas interfaces, mas nas relações entre empresas, pessoas,
permissões e produtos — e principalmente em definir
o que precisava ser centralizado e o que
deveria permanecer independente
.
Essa separação criou uma fundação que continuou sendo reutilizada conforme a plataforma
cresceu.
Uma arquitetura escalável não tenta
controlar todos os produtos. Ela define as
regras que permitem que eles cresçam
juntos.