ADR-001: Automação do Fluxo de Aprovação de Cadastro de Denominador
Status: Aprovado (Extensão de Backend)
Data: 08/09/2025
Contexto: Automação do processo de aprovação de denominadores
Decisores: Equipe FinOps
1. Contexto do Problema
Atualmente, o processo de cadastro de um novo denominador no sistema exige uma aprovação manual do gestor responsável. Este processo é propenso a atrasos, falhas de comunicação e falta de rastreabilidade, impactando diretamente a agilidade na criação de novos denominadores e, consequentemente, nos processos de FinOps. A dependência de interações manuais para cada aprovação gera ineficiência operacional.
2. Decisão Proposta
A decisão inicial foi implementar uma solução automatizada para o fluxo de aprovação de cadastro de denominadores, utilizando uma API de notificação dedicada. Esta API se integraria ao sistema de cadastro e às ferramentas de comunicação (Slack e/ou e-mail) para notificar o gestor de forma eficiente e rastreável.
Para priorizar a entrega imediata, optou-se pela Opção B: Integração com finopping-backend Existente.
No entanto, uma nova etapa de desenvolvimento já está em fase de discovery para a criação de um novo serviço dedicado que fará a comunicação entre o Slack e a Finopping. Este serviço futuro será responsável por toda a orquestração e padronização das notificações.
3. Opções Consideradas
Inicialmente, três abordagens principais foram exploradas e avaliadas:
3.1 Opção A: Novo Projeto App Script (Clasp)
Descrição: Criar um projeto independente no Google Apps Script (utilizando Clasp para desenvolvimento local) que seria responsável por receber as requisições de notificação e interagir com o Slack e/ou Gmail. Funcionaria como um microsserviço dentro do ecossistema Google.
Vantagens Potenciais: Baixa complexidade para funcionalidades simples, integração nativa e facilitada com o ecossistema Google (Gmail, Sheets), pode ser mais ágil para prototipagem e desenvolvimento de MVP.
Desvantagens Potenciais: Manutenção de um novo codebase fora da stack principal da Finopping, possíveis limitações de escalabilidade para volumes muito altos, curva de aprendizado para quem não tem familiaridade com Apps Script.
3.2 Opção B: Integração com finopping-backend Existente (Opção Escolhida Inicialmente)
Descrição: Estender o finopping-backend atual com um novo módulo ou endpoint que gerencie o envio das notificações para o Slack e/ou serviço de e-mail. A lógica de notificação seria parte integrante do serviço de backend principal.
Vantagens Potenciais: - Reutilização da infraestrutura e stack tecnológica existentes - Aproveitamento de práticas de monitoring e segurança já implementadas - Código centralizado em um único repositório
Desvantagens Potenciais: - Risco de aumentar a complexidade ou o acoplamento do backend existente - Pode exigir um esforço de desenvolvimento maior para integração no backend atual se a arquitetura não for modular
3.3 Opção C: Nova API Independente (via API Gateway/Serverless Toolkit)
Descrição: Criar uma nova API de notificação totalmente independente, utilizando um framework de backend leve ou funções serverless (ex: AWS Lambda com API Gateway, Google Cloud Functions). Esta API teria seu próprio ciclo de vida e seria dedicada exclusivamente à função de notificação.
Vantagens Potenciais: - Separação de responsabilidades (microsserviço dedicado) - Alta escalabilidade e resiliência (especialmente com serverless) - Menor acoplamento com o finopping-backend e o ecossistema Google - Flexibilidade na escolha de tecnologias
Desvantagens Potenciais: - Requer configuração de nova infraestrutura (Gateway, funções) - Aumento da complexidade de gerenciamento de múltiplos serviços/repositórios - Pode exigir mais tempo para setup inicial de CI/CD
4. Critérios de Avaliação e Desafios
Os critérios para a escolha da opção incluem:
- Facilidade de Desenvolvimento e Manutenção: Qual opção exige menos esforço para ser construída e mantida a longo prazo
- Segurança: Como cada opção lida com autenticação e autorização para as APIs externas
- Escalabilidade: A capacidade da solução de lidar com um volume crescente de solicitações
- Observabilidade: A facilidade de monitorar logs e métricas da solução
Desafios Adicionais: - Formato da Notificação: Definir o conteúdo e o formato ideal da mensagem no Slack/e-mail (link para aprovação, informações do denominador) - Persistência do Estado: Como gerenciar o estado da aprovação (pendente, aprovado, rejeitado) e garantir a rastreabilidade
5. Implicações
5.1 Ganhos
- Redução significativa do tempo de aprovação de denominadores
- Melhora na rastreabilidade e auditoria das aprovações
- Liberação da equipe para tarefas de maior valor agregado
5.2 Riscos
- Complexidade na integração com sistemas legados ou com a Finopping existente
- Dependência de APIs externas (Slack, serviço de e-mail)
6. Subtarefas para o Desenvolvimento
6.1 Fase Inicial (Concluída - Extensão do finopping-backend)
- Analisar qual das três opções (App Script, Extensão do finopping-backend, ou Nova API Independente) é a mais adequada para o escopo inicial e o futuro da plataforma. (Decisão: Extensão do finopping-backend)
- Criar um Desenho Técnico inicial do processo automatizado de aprovação, ilustrando a opção escolhida
- Documentar o fluxo de integração end-to-end para a aprovação do gestor
- Definir a estrutura de dados (payload) para as requisições de notificação
- Prototipar a integração com o Slack/e-mail na opção escolhida para validar a comunicação
6.2 Próximos Passos (Fase de Discovery)
- Início da fase de discovery para a criação de um novo serviço/código que fará toda a comunicação padronizada entre Slack e a Finopping
- Definição da arquitetura e das tecnologias a serem utilizadas para o novo serviço de comunicação
- Elaboração do desenho técnico detalhado para este novo componente
7. Referências
Última Atualização: 08/09/2025
Versão: 1.0
Autores: Carolina Bratos
Revisores: Gabriel Pepe, Eduardo Alcebiades e Adriano Valerio