Da invisibilidade à decisão: a cadeira que o DBA precisa ocupar

No texto anterior, comentei como banco de dados e a área de Infraestrutura em geral permanecem invisíveis quando funcionam e como o DBA costuma ser lembrado apenas quando algo falha e vira emergência. Lendo Infraestrutura e Desenvolvimento no Brasil, percebi que essa lógica não é exclusiva da Infraestrutura de TI. As telecomunicações seguem a mesma lógica: sustentam silenciosamente a economia, a vida urbana e a transformação digital, mas só entram no debate público quando limitam o crescimento, revelam desigualdades ou entram em colapso.

O texto mostra que o Brasil construiu uma das maiores infraestruturas de telecomunicações do mundo, com investimentos privados da ordem de R$ 1 trilhão desde a privatização, cobertura 4G para mais de 95% da população e centenas de milhões de acessos. Ainda assim, essa infraestrutura permanece fora do campo de visão enquanto funciona, e reaparece apenas quando a baixa velocidade média, a ausência de fibra em parte dos municípios, a carga tributária excessiva ou os entraves regulatórios passam a frear produtividade, inovação e inclusão. A infraestrutura, portanto, não cria o problema, ela apenas o revela quando chega ao seu limite.

É a partir deste ponto que mudamos a discussão, o ponto central deixa de ser “por que o DBA só aparece na crise?” e passa a ser em que espaço decisório ele não estava quando o risco foi criado, acredito eu que a Arquitetura é esse espaço.

Ao longo da minha carreira participei de muitas reuniões para discutir arquitetura de banco de dados, e na grande maioria percebi que sempre há uma expectativa silenciosa: alguém espera que o DBA valide a melhor solução técnica e também percebi o quanto este enquadramento é limitado. Arquitetura não se trata de escolher a tecnologia mais moderna e sim onde se decide como a instituição vai operar, crescer e lidar com seus próprios riscos nos próximos anos

Nós, profissionais de dados de hoje, assumimos que projetar arquiteturas é, na verdade, uma gestão consciente de riscos, e não a sua extinção. Ao centralizarmos, ganhamos controle, mas aceitamos a vulnerabilidade de um impacto sistêmico. Ao distribuirmos, fomentamos a agilidade das equipes, exigimos maior maturidade operacional pois assumimos o desafio de uma operação complexa. Reconhecemos que cada caminho carrega seu próprio peso e responsabilidade. E, como argumenta Andrew Feenberg (Coletânea: A teoria crítica de Andrew Feenberg: racionalização democrática, poder e tecnologia), decisões técnicas nunca são apenas técnicas: elas carregam valores, prioridades e relações de poder, mesmo quando apresentadas como escolhas racionais.

Quando discutimos arquitetura de banco de dados, cada escolha cria limites claros. Optar por um banco gerenciado reduz esforço operacional aumentando a dependência do fornecedor enquanto no autogerenciamento teremos mais controle, mas exigiremos equipe, processo e disciplina. Buscar alta disponibilidade reduz indisponibilidade, mas aumenta complexidade e custo. A arquitetura nunca será sobre maximizar tudo e sim sobre priorizar o que importa para aquele negócio, naquele contexto institucional.

Neste cenário o papel do DBA não é defender produto, versão ou fabricante. É explicitar trade-offs. É trazer à mesa perguntas que normalmente ficam fora do slide: quem vai operar isso no dia a dia? Onde a falha é aceitável e onde ela é inegociável? O que precisa ser previsível todos os dias e o que pode ser flexível? Temos que tomar cuidado para que essas perguntas não sejam invisíveis e sejam empurradas para depois, pois irá virar emergência.

Arquiteturas saudáveis devem aproximar a decisão de operação. Quando decisões são tomadas sem ouvir quem vive a operação, o risco não desaparece, ele é apenas empurrado para debaixo do tapete e se torna invisível para quem decide. É exatamente esse mecanismo que os estudos sobre infraestrutura mencionados anteriormente descrevem: a dissociação entre quem decide e quem sustenta o funcionamento do cotidiano. O DBA moderno não deve ser um entrave à inovação; ele é a memória operacional da instituição.

Vejo com frequência em grupos de whatsapp, telegram, fóruns técnicos (sim, ainda participo e recomendo) debates simplificados entre centralização e distribuição de dados, como se fosse uma escolha ideológica (por um lado é), na prática não é. Centralizar pode facilitar compliance, auditoria e consistência. Distribuir pode melhorar a performance local e autonomia dos times. O papel do DBA é ajudar a definir onde faz sentido centralizar e onde distribuir, entendendo o impacto em latência, governança, custo e risco institucional, não apenas em performance imediata.

O mesmo vale para as chamadas boas práticas em arquitetura de dados. Elas ajudam enquanto funcionam como acordos vivos, revisáveis e tornam-se perigosas quando viram dogma. Arquitetura que não pode ser questionada deixa de ser decisão e passa a ser herança. A crítica de Feenberg à ideia de neutralidade técnica ajuda a entender porque questionar decisões não é fragilidade, mas maturidade, pois toda técnica envolve escolhas e escolhas precisam ser revisitadas.

Outro ponto é que a arquitetura deve ser tratada como comunicação. Diagramas de dados, modelos lógicos, decisões de particionamento, estratégia de retenção e integração precisam ser compreensíveis. Se só o arquiteto ou o DBA entende a arquitetura, a instituição não consegue sustentá-la a longo prazo. O que não é entendido não é governável e o que não é governável tende a falhar em silêncio.

Neste papel, decidir a arquitetura também significa assumir consequências futuras. Quando surgem problemas de performance, indisponibilidade, inconsistência ou custos fora do controle, raramente é um “problema técnico inesperado”. Na maioria das vezes é o efeito acumulado de escolhas feitas anos antes, quando a infraestrutura ainda era invisível. Na arquitetura madura reconhecemos isso e trataremos falhas como feedback e não como surpresa.

Por isso, defendo que as arquiteturas de bancos de dados precisam ser revisáveis. Nenhuma decisão deveria ser definitiva. O uso real sempre revela limites que o desenho inicial não previu. Criar rituais de revisão arquitetural com dados, métricas e experiência operacional é uma prática de maturidade institucional.

Neste contexto, o DBA já não é mais o guardião isolado do banco e passa a ser o ator estratégico, alguém que traduz impacto técnico em risco institucional, conecta estratégia de negócio com realidade operacional e ajuda a instituição a decidir melhor. A autoridade aqui não vem do cargo, mas da capacidade de tornar visíveis as consequências antes que elas se manifestem como crise.

No final veremos que não iremos escolher a tecnologia perfeita, mas assumir escolhas conscientes que vão moldar o futuro da instituição. Organizações maduras não tentam eliminar riscos, elas escolhem quais riscos conseguem sustentar e o DBA moderno é uma das poucas figuras capazes de tornar essas escolhas explícitas antes que a invisibilidade da infraestrutura volte a cobrar o seu preço.