Voltar para Insights

A Arquitetura do Data Office as a Service

Um breakdown técnico de como projetamos o DOaaS para substituir equipes de dados fragmentadas por um modelo operacional unificado e code-first — cobrindo decisões de stack, estrutura de custos e tradeoffs de governança.

A maioria das organizações que se dizem “data-driven” são, na prática, data-burdened. Têm uma conta Snowflake que ninguém entende completamente, um tenant Power BI com 400 relatórios sem convenção de nomenclatura, três ferramentas de ETL concorrentes, e um único analista sênior segurando a operação inteira na base da memória institucional.

Foi nesse ambiente que o Data Office as a Service (DOaaS) nasceu — não de uma visão de whiteboard, mas da exposição repetida ao mesmo padrão de falha organizacional em dezenas de clientes.

O Que o DOaaS Realmente É

DOaaS não é staff augmentation com nome bonito. É uma função de dados operada externamente que assume a arquitetura, governança, pipelines e camada analítica do ecossistema de dados do cliente. O cliente retém expertise de domínio e autoridade decisória. Nós ficamos com a engenharia.

A distinção importa porque modelos tradicionais de consultoria inserem pessoas na disfunção existente. O DOaaS substitui a disfunção em si, impondo um modelo operacional padronizado entre clientes.

O Modelo Operacional

O DOaaS opera sobre três pilares:

1. Autoridade Arquitetural Nós definimos e impomos a arquitetura de dados. Isso inclui seleção de bancos (PostgreSQL para transacional, ClickHouse para analítico), ferramentas de orquestração de pipelines, padrões de modelos semânticos e procedimentos de deploy. O cliente não escolhe suas próprias ferramentas — nós prescrevemos o que funciona baseado na escala e restrições dele.

2. Governança Codificada Cada pipeline, cada transformação, cada modelo semântico segue uma especificação versionada. Usamos Spec-Driven Development (SDD) internamente para garantir que regras de negócio sejam capturadas em Markdown antes de virarem código. Isso elimina o problema do “conhecimento tribal” que assombra a maioria das equipes de dados.

3. Continuidade Operacional Diferente de um engagement de consultoria que termina quando o contrato expira, o DOaaS mantém propriedade persistente. Monitoramos saúde dos pipelines, utilização de capacidade e qualidade dos dados continuamente. Quando uma capacidade Fabric começa a sofrer throttling às 3 da manhã, nossos alertas automatizados capturam — não um e-mail desesperado do CFO na manhã seguinte.

A Stack Por Trás do Serviço

Construir uma prática DOaaS exige fazer apostas tecnológicas agressivas. A nossa:

Camada de Dados

ComponenteTecnologiaJustificativa
BD TransacionalPostgreSQLConformidade ACID, ecossistema maduro, compatibilidade com Django ORM
BD AnalíticoClickHouseArmazenamento colunar, agregações sub-segundo em bilhões de linhas
Fila de TarefasCelery + RedisIngestão assíncrona previne bloqueio do backend durante ETL pesado
OrquestraçãoMage.aiEditor visual de DAGs para transparência de pipelines com o cliente

Camada de Aplicação

ComponenteTecnologiaJustificativa
Backend APIDjango + DRFMonolito modular com DDD, autenticação battle-tested
FrontendFlutter (Dart)Renderização nativa bypassa gargalos do DOM para UIs de dados pesadas
Visualização BIApache SupersetConexão direta ao ClickHouse, dashboards embeddáveis

Infraestrutura

ComponenteTecnologiaJustificativa
ContainersDocker ComposeAmbientes reproduzíveis entre dev, staging, produção
CI/CDGitHub ActionsDeploy via SSH para VPS, integrado com validação de specs SDD
SecretsGitHub Secrets + .envZero credenciais hardcoded em qualquer repositório

Por Que Não Contratar um Time de Dados?

Essa é a pergunta que todo cliente potencial faz. A resposta honesta: contratar funciona se você consegue bancar, reter o talento, e fornecer direção arquitetural suficiente para prevenir entropia.

A maioria das empresas mid-market não consegue fazer as três coisas simultaneamente.

A Aritmética de Custos

Um time de dados competente para uma operação de médio porte tipicamente requer:

  • 1 Data Engineer (sênior): R$ 15.000-25.000/mês
  • 1 Analytics Engineer: R$ 12.000-18.000/mês
  • 1 BI Developer: R$ 10.000-15.000/mês
  • Overhead de infraestrutura (ferramentas, licenças, cloud): R$ 5.000-10.000/mês
  • Overhead de gestão (contratação, onboarding, retenção): ~20% dos custos salariais

Total: aproximadamente R$ 50.000-80.000/mês antes de considerar tempo de ramp-up, risco de turnover e a dívida arquitetural acumulada durante a curva de aprendizado.

O DOaaS comprime isso em um fee mensal previsível que inclui a arquitetura, o framework de governança, as decisões de ferramentas e a execução operacional. O cliente não paga por alguém aprendendo ClickHouse no trabalho — paga por um time que já construiu e opera isso em produção.

O Gap de Competência

Além do custo, existe uma assimetria de competência. Um provedor DOaaS encontra e resolve a mesma classe de problemas em múltiplos clientes. Os padrões viram memória muscular: como estruturar um star schema para dados de POS no varejo, como particionar telemetria time-series no ClickHouse, como prevenir throttling de capacidade Fabric através de scripts de governança automatizados.

Um time interno encontra esses problemas uma vez, resolve parcialmente, e segue para o próximo incêndio.

Como Fazemos o Onboarding

O processo segue um ciclo estruturado de 4 semanas:

Semana 1 — Auditoria. Executamos scans automatizados contra a infraestrutura de dados existente. Para tenants Power BI, isso significa rodar nossos scripts Python do catálogo contra a Admin REST API para mapear cada workspace, dataset e relatório. Para bancos de dados, perfilamos padrões de query, uso de índices e distribuição de armazenamento.

Semana 2 — Design da Arquitetura. Baseado nos achados da auditoria, produzimos um documento de arquitetura target-state. Não é um PowerPoint de 50 slides. São arquivos de especificação SDD-compliant que descrevem cada fluxo de dados, regra de transformação e padrão de acesso.

Semana 3 — Build da Fundação. Deployamos a infraestrutura core: instâncias de banco, orquestração de pipelines, hooks de CI/CD e monitoramento. Tudo roda em containers, tudo é versionado.

Semana 4 — Migração & Handoff. Migramos pipelines e relatórios existentes para a nova arquitetura, validamos integridade de dados através de checks de reconciliação automatizados, e treinamos os especialistas de domínio do cliente em padrões de consumo self-service.

Governança como Feature do Produto

Governança na maioria das organizações é um slide de PowerPoint mostrado uma vez por trimestre. No DOaaS, governança é infraestrutura automatizada.

Todo modelo semântico deployado através do nosso pipeline passa por checks automatizados do Best Practice Analyzer. Toda medida DAX é validada contra convenções de nomenclatura. Todo pipeline de dados tem garantias de idempotência e monitoramento automatizado de SLA.

Quando um desenvolvedor submete um Pull Request contendo um arquivo de projeto Power BI (.pbip) com cross-filtering bidirecional ou colunas de foreign key não-escondidas, o pipeline de CI/CD rejeita antes de chegar à produção. Isso não é uma sugestão cultural — é um enforcement arquitetural.

As Limitações Honestas

DOaaS não é universalmente aplicável.

Organizações com times de dados fortes e práticas de governança maduras não precisam. Empresas em indústrias altamente reguladas (bancos, saúde) podem enfrentar restrições de compliance em torno de processamento externo de dados que tornam o DOaaS completo impraticável — embora modelos híbridos funcionem.

O modelo também exige confiança. Entregar autoridade arquitetural para um parceiro externo é desconfortável, e deveria ser. Mitigamos isso através de transparência radical: toda especificação é legível por stakeholders não-técnicos, todo pipeline é observável através de dashboards compartilhados, e toda mudança passa por Pull Requests versionados que o cliente pode revisar.

O Que Isso Muda

DOaaS não promete tornar dados “fáceis.” Dados são inerentemente bagunçados, e qualquer um vendendo simplicidade está vendendo ficção.

O que o DOaaS entrega é previsibilidade. Custos previsíveis, arquitetura previsível, governança previsível. A liderança do cliente para de se preocupar se a infraestrutura de dados vai sobreviver ao próximo trimestre e começa a focar no que os dados realmente dizem sobre o negócio deles.

Essa mudança — de ansiedade com dados para utilidade dos dados — é o ponto inteiro.