Entreguei em 19/09/2026 o trabalho final da especialização em Arquitetura de Software, Ciência de Dados & Cybersecurity da PUC-PR. O formato pedido não era uma monografia teórica, e sim um projeto de intervenção: escolher um problema real do próprio ambiente de trabalho, propor uma solução arquitetural fundamentada e definir como medir se ela funcionou.
Este post tem duas partes: como o trabalho foi construído e o que ele propõe, em resumo.
Por que esse tema
Trabalho há anos com integrações em cima de um ERP hospitalar de terceiro. O modelo vigente é o mais comum do mercado: cada novo sistema que precisa de dado recebe credencial JDBC/ODBC e passa a executar SQL direto no schema do produto.
Funciona. Até não funcionar.
Escolhi esse tema porque ele cruza exatamente as três trilhas da especialização:
- Arquitetura — acoplamento, fronteiras, evolução de sistema legado
- Cybersecurity — privilégio mínimo, superfície de ataque, rastreabilidade e LGPD
- Dados — governança de acesso e catálogo formal do que é exposto
Nenhuma das três resolveria o problema sozinha, e essa foi a tese: a decisão não é técnica isolada, é arquitetural.
O processo de construção
O documento saiu em quatro blocos, nessa ordem — e a ordem importou.
1. Problematização antes de solução. A primeira versão que escrevi começava pelo ORDS. Estava errada: virou apresentação de produto. Reescrevi partindo do problema e cheguei a três classes distintas de dor:
- Acoplamento estrutural — o consumidor conhece as tabelas internas; uma atualização do fornecedor quebra integração em produção silenciosamente. Hohpe e Woolf chamam isso de antipadrão do banco de dados compartilhado.
- Segurança — a credencial é concedida no nível da conexão, não da operação de negócio. Acesso para "consultar pedidos" habilita, na prática, ler tudo que o usuário enxerga. Sem trilha consolidada de quem acessou o quê.
- Organizacional — construir integração exige conhecer o schema interno. Competência concentrada em poucas pessoas, que viram gargalo permanente.
O terceiro é o mais crítico e o mais fácil de ignorar em um trabalho técnico. Conway (1968) já dizia que a estrutura de comunicação da organização se reflete na arquitetura que ela produz. No caso analisado, a centralização de conhecimento produziu uma arquitetura que só pode ser operada por seus autores.
2. Justificar a escolha derrubando a alternativa. Não bastava defender o ORDS; precisava mostrar por que a alternativa óbvia — uma API intermediária em Java, Node ou Python — foi descartada:
- introduz uma stack nova para manter, monitorar e atualizar indefinidamente;
- cria novo ponto de falha, exigindo estratégia própria de HA quando a infra Oracle já tem redundância consolidada;
- exige competência que a equipe operacional não possui, ou seja, reproduz o gargalo em vez de eliminá-lo.
Esse último ponto é o que amarra a decisão técnica ao problema organizacional. Um analista que escreve SQL e PL/SQL consegue publicar um recurso REST completo, com paginação, filtro e OpenAPI gerado, sem aprender framework nenhum.
3. Fundamentação puxada pelo problema, não pelo catálogo. Cada autor entrou para responder a uma dor específica: Fielding para o desacoplamento via contrato; Fowler (Strangler Fig) e Newman para modernização sem alterar o legado; Bass/Clements/Kazman e Ford/Parsons/Kua para atributos de qualidade; OWASP API Security Top 10, ISO/IEC 27001 e LGPD para o eixo de segurança.
4. Risco e indicador por último. Foi a parte que mais mudou a proposta. Ao listar as ameaças, apareceram mitigações que viraram regra de projeto, por exemplo, nenhuma tabela é exposta diretamente, só views com projeção mínima. A regra nasceu da análise de risco, não do desenho inicial.
A proposta, em resumo
Publicar uma camada REST sobre o ERP usando Oracle REST Data Services, sem alterar uma linha do produto de terceiro.
O ORDS roda sobre o próprio banco existente e publica tabelas, views e procedures PL/SQL como recursos REST. A camada vive em um schema dedicado, isolado do schema do ERP, e pode ser removida sem deixar resíduo, ponto decisivo, porque o código-fonte é do fornecedor e alterá-lo comprometeria suporte e garantia.
O ambiente é on-premise: dois nós Oracle Linux, HAProxy para balanceamento e escala horizontal, WAF na borda. A proposta aproveita isso como ativo, o ORDS usa o Connection Pool já configurado, então as requisições REST se distribuem entre os dois nós sem projeto novo de clusterização e sem investimento em hardware ou licença.
As regras que sustentam o desenho:
| Regra | Motivo |
|---|---|
| Leitura só por view, nunca tabela | Desacopla do schema interno e aplica projeção mínima + mascaramento |
| Escrita só por procedure homologada | Preserva o suporte contratual do fornecedor |
| Recurso REST versionado | Atualização do ERP não quebra consumidor em produção |
| Paginação obrigatória + rate limit no WAF | Evita que consulta mal dimensionada degrade o próprio ERP |
| Revisão formal de privilégio antes de publicar | Impede exposição indevida de dado sensível |
O detalhe operacional que mais gosto: cada integração pertence a um schema Oracle, que agrupa seus módulos, handlers e privilégios. Ativar ou desativar uma integração inteira é um comando de banco, sem restart de serviço, sem novo deploy, sem impacto nas demais. Em incidente, suspende, investiga e reativa depois com a configuração intacta.
Execução
Treze semanas, em quatro fases, tudo em homologação espelhando a topologia real (dois nós + balanceador + WAF):
- Diagnóstico (3 sem.) — inventário das entidades candidatas, classificação por sensibilidade, definição do schema dedicado e da política de privilégios.
- Provisionamento (4 sem.) — instalação do ORDS, construção das views de desacoplamento, primeiros módulos/templates/handlers, catálogo OpenAPI.
- Implementação (3 sem.) — três integrações representativas (consulta simples, consulta composta, escrita por procedure), autenticação por token, ajuste do WAF ao tráfego REST, teste de carga.
- Consolidação (3 sem.) — runbook e execução assistida por alguém que não participou da construção. Se essa pessoa não conseguir publicar uma integração sozinha, o projeto falhou no ponto que mais importa.
Como isso é medido
Indicadores com meta pactuada, aferidos ao fim da intervenção:
| Indicador | Linha de base | Meta |
|---|---|---|
| Tempo para disponibilizar nova integração | 20 dias úteis | 5 dias úteis |
| Integrações por acesso direto ao banco | 100% | máx. 30% |
| Credenciais diretas concedidas a consumidores | total atual | redução de 70% |
| Recursos com especificação OpenAPI | 0% | 100% |
| Tempo para suspender integração em incidente | acima de 4h | menos de 5 min |
| Analistas aptos a publicar sem o especialista | 1 | mínimo de 4 |
O indicador de "analistas aptos" é o que define o sucesso real. Os outros medem arquitetura; esse mede se o gargalo organizacional foi de fato dissolvido, que era o problema de origem.
O que levo do trabalho
Duas coisas.
A primeira: restrição de contexto não é obstáculo ao projeto, é insumo dele. "O ERP é de terceiro e não pode ser tocado" parecia limitação e acabou sendo o critério que eliminou as alternativas erradas e apontou a certa.
A segunda: arquitetura que só uma pessoa consegue operar é dívida, por mais elegante que seja no diagrama. Tratar distribuição de competência como decisão de arquitetura, e não como assunto de gestão, foi a virada de chave do trabalho.
O próximo passo é sair do papel. Quando a fase de diagnóstico rodar de verdade e as linhas de base estimadas virarem número medido, publico a continuação aqui.