Analytics by design: como o iti revolucionou sua forma de trabalhar com o auxílio de dados

Este artigo foi escrito em conjunto com Marcelo Sousa.

No início de 2019, recebemos a missão de construir uma plataforma de dados para um novo produto do Itaú que estava sendo concebido, o iti. Um produto, que surgiu com a proposta de transformar a relação das pessoas com o dinheiro, tornar fácil o que hoje é difícil e burocrático, fazer o caro ser acessível. Entre seus principais pilares e ambição estão a simplicidade e a democratização de serviços financeiros para uma parcela da população que vive à margem do sistema financeiro atual, seja voluntaria ou involuntariamente. O iti trabalha para ir muito além do que existe atualmente nos grandes bancos e fintechs: queremos atender e entender clientes que não têm histórico no mercado com profundidade, porque sabemos o valor dessas pessoas na economia e as dificuldades que enfrentam. E nesse contexto, o uso de dados em larga escala desempenha um papel essencial para que o iti consiga atingir seu objetivo de ser uma plataforma financeira democrática.

Como engenheiros de dados, apaixonados por tecnologia e entusiasmados com esse desafio, começamos a trabalhar pensando na melhor solução utilizando todos recursos possíveis: processamento em tempo real, esteira de MLOps, sandbox para cientistas, data pipelines escaláveis etc. Mas, logo fizemos uma pausa e nos perguntamos: será que precisamos de tudo isso desde o início? A resposta, reforçada por mais de um ano e meio de caminhada foi: não. Não precisamos de tudo isso, conseguimos gerar muito valor com pouco, seguindo os pilares:

· Entregas incrementais orientadas ao negócio.

· Analytics by design a partir de uma cultura data-driven.

· Analytics é código.

· Governança, privacidade e qualidade como valores.

Entregas incrementais orientadas ao negócio

Não é segredo para ninguém, que toda iniciativa de tecnologia deve ter um objetivo bem definido de negócio e seguir seu desenvolvimento a partir de entregas incrementais. O que nem sempre fica claro para as empresas, ou passa batido, é que essa mesma lógica deve ser adotada, rigorosamente, também em frentes estruturantes, como a de construção de uma plataforma de dados.

Toda construção e evolução da plataforma têm que ser pautadas a partir de um objetivo de negócio e suas entregas devem alavancar seus resultados. Ou seja, é preciso ficar atento aos famosos OKRs (Objectives and key results): o time estruturante da plataforma de dados deve ter objectives alinhados às estratégias de negócio e key results que possibilitem uma medição e acompanhamento da evolução e da geração de valor das entregas. Sem uma medição clara do valor gerado para o negócio, corre-se o risco de construir tecnologia por tecnologia e não algo que de fato gere retorno. Não caia no erro de definir metas de evoluções técnicas, que não conversam com as estratégias do produto.

É comum entre apaixonados por tecnologia querer construir soluções elegantes e o mais próximas do estado da arte. Isso é ótimo, e deve ser usado como balizador para garantir entregas com qualidade, mas o time não pode perder o foco no que realmente importa (e os OKRs ajudam muito nisso) — gerar valor para nossos clientes. Inclusive, nos ajudam a evitar o BDUF (Big Design Up Front): com objetivos semestrais e anuais, a construção da plataforma deve focar nesse horizonte, sem gastar muita energia num desenho futuro muito distante.

Analytics by design a partir de uma cultura data-driven

Para que qualquer iniciativa com dados tenha sucesso é preciso primeiro criar um ambiente em que todos compreendam a sua importância e reconheçam o valor na sua utilização. Assim, a jornada do dado, desde sua concepção ao seu uso, deve ser conhecida por todos.

O primeiro passo para construção desse ambiente deve ser fornecido pela alta liderança: o patrocínio dos executivos e a defesa dessa cultura são fundamentais para que ela seja adotada por todos os setores. E esse patrocínio e defesa devem significar total comprometimento dessa alta liderança, traduzidos em ações e não apenas em discursos.

Partindo do ponto supracitado tem-se um ambiente propício para a criação de uma estratégia de dados e para a adoção do conceito de analytics by design. Em que as próprias features do produto possam nascer integradas à plataforma de dados, enviando informações relevantes, e em um formato que possibilite o seu uso em analytics. Tudo isso só é possível com uma cultura data-driven madura, na qual os times de produto vejam valor no uso dos dados, e também se preocupem com o tema.

Analytics é código

O contexto de engenharia/ciência de dados deve ser tratado com o mesmo rigor que, por exemplo, é tratado o do desenvolvimento do backend de um sistema transacional. Em outras palavras: anlytics é código como qualquer outro e deve ser tratado como tal. Isso significa que a construção de um pipeline ETL ou a criação de um modelo não pode ser tratada como um trabalho artesanal, único, demorado e não replicável. Ao contrário disso, eles precisam ser ágeis, replicáveis e de fácil desenvolvimento.

Como exemplo, a título de ilustração, uma plataforma de dados madura precisa ter uma esteira de Dev&MLOps, com todos os gates que se espera dela, uso de infra como código e um portfólio de aceleradores de desenvolvimento, como building blocks e scaffolds. Chegando ao ponto em que seja fácil, rápido e seguro desenvolver dentro e para a plataforma.

Governança, privacidade e qualidade como valores

Tudo o que foi apresentado até agora é suficiente para o sucesso dessa empreitada desde que tratemos os dados da plataforma de forma a garantir a sua governança, privacidade e qualidade. Entendemos que esses pontos são tão importantes, que devem ser considerados como valores. A ponto de nenhum objetivo de negócio, por exemplo, poder suplantar o uso seguro e governado da plataforma e de seus dados. Quanto à qualidade, a máxima garbage in garbage out fala por si só: se eu não conheço o meu dado nem garanto um nível mínimo de serviço, a chance de ele gerar mais problema do que valor será alta.

Por isso é muito importante, desde a sua concepção, ter ferramentas e processos, que garantam esses três valores. E, claro, se todo o time não os reconhecer como valores, não há ferramenta ou processo que proporcione êxito na empreitada.

O uso de um catálogo, a definição dos esquemas de dados dos produtos já na ingestão e a segregação granular de acesso aos dados, além de logs de rastreabilidade e data lineage, são alguns exemplos de funcionalidades que ajudam a garantir a aderência a esses pontos.

Legal, mas e na prática?

Agora você deve estar se questionando: como conseguimos aplicar todos esses pilares na prática, levando em conta todas as dificuldades e complexidades de desenvolver grandes iniciativas de tecnologia?

Quando começamos o desenvolvimento da plataforma de dados, no iti, já com esses pilares que descrevemos em mente, tomamos as seguintes decisões técnicas: (1) ser 100% serverless usando apenas serviços que o provedor de cloud (AWS) tenha para oferecer; (2) todo desenvolvimento feito obrigatoriamente com GitFlow, CI/CD e infra como código, no caso, GitLab, GitLab CI e Terraform.

Essas decisões técnicas e todas as outras que tomamos em sequência sempre foram pautadas a partir dos objetivos definidos para/pelo o time de dados. Objetivos esses construídos e validados em parceria com o time de negócio do iti. Como exemplo, alguns dos nossos objetivos eram: aumentar o número de clientes ativos e, também, aumentar a nossa capacidade de fornecer crédito para a parcela da população que hoje não tem acesso a esse tipo de serviço. Dessa forma, todo o time de engenharia é constantemente levado à seguinte reflexão: como a plataforma de dados pode contribuir para alcançar esses objetivos?

Sempre focados na estratégia de entregas incrementais e de olho nos objetivos, optamos por fazer nosso primeiro fluxo de dados em lambda, com armazenamento no S3, e construir todo o arcabouço em torno: módulos de Terraform, pipeline do GitLab CI e bulding blocks em Python. A ponto de, em menos de um mês, ter uma primeira versão da plataforma funcional, com fluxos de dados tempestivos e nossos usuários realizando consultas no Athena.

Quanto à cultura, hoje é seguro dizer que o iti, tanto como produto quanto equipe, respira dados, lançando novas features já integradas com a plataforma, fazendo análises de dados para definir estratégia, ou fazendo uso de modelos de advanced analytics. Esse grau de maturidade foi alcançado primeiro pelo patrocínio e engajamento dos nossos heads, tanto de negócio quanto de tecnologia, que desde o início garantiram que a disciplina de dados fosse tratada como prioritária e parte integrante do produto e não como “uma prestadora de serviços”.

Com esse respaldo, o time de dados conseguiu influenciar de forma positiva toda a equipe do iti. Garantindo, por exemplo, que fosse um critério de aceite de toda nova funcionalidade a integração com a plataforma de dados: hoje recebemos eventos pensados para o uso na plataforma de todas as funcionalidades. Isso permite um lead-time curtíssimo entre a extração e o seu uso, uma vez que aquele dado já foi pensado para melhor atender esse contexto e sua integração foi feita antes mesmo de entrar com a funcionalidade em produção.

Duas importantes estratégias que seguimos desde o início da plataforma nos possibilitaram ficar sempre aderentes aos nossos valores de governança, privacidade e qualidade: definição do esquema dos eventos e governança por exceção. No caso, também como critério de aceite, todos eventos enviados para a plataforma de dados precisam ter seus esquemas declarados, não só com o layout e a tipagem, mas também com a descrição funcional dos campos e um sinalizador de PII (Personally Identifiable Information). Esse esquema é utilizado em três momentos diferentes: no registro do nosso catálogo de dados, no batimento entre evento recebido e esperado e, por fim, na anonimização dos campos PII. O catálogo garante a governança e uma faceta da qualidade, tornando fácil encontrar e entender nossos dados, o batimento garante a qualidade técnica dos eventos e a anonimização a privacidade e, também, a governança. No caso, a anonimização habilita a criação de uma camada com todos os dados sem a identificação de nossos clientes, permitindo o uso mais seguro e controlado dos dados. Essa camada foi definida como ponto de partida para exploração. Lembrando que toda captura de dados e liberação de acesso à plataforma segue a LGPD — com seu princípio de minimização, deleção e expurgo dos dados, além da necessidade de justificar o uso a partir de um motivo e finalidade.

Casos de sucesso

Até aqui foi possível ver e entender como colocamos isso tudo em prática. Agora, serão expostos alguns exemplos que demonstram como essa estratégia foi bem sucedida no iti, possibilitando que o time de dados gerasse enorme valor aos nossos clientes.

Bem no início da nossa história, quando a nossa esteira de CI/CD suportava apenas o deploy de lambdas, criamos um fluxo que encapsulava nossos modelos mais leves para serem executados a partir deles. Isso abriu um leque de possibilidades e com menos de um mês de existência estávamos com modelos em produção, que iam desde a predição de ativação e inativação dos nossos clientes até modelos que customizavam nossa experiência de cadastro.

Hoje, com nossa plataforma já madura, auxiliamos uma série de áreas críticas do iti. É o caso, por exemplo, do nosso fluxo de transações financeiras, em que todas as transações são avaliadas por nossos modelos para identificação de potenciais fraudes. E o mais legal: com baixíssimo impacto em nossos clientes. Além disso, nosso time de SRE (Site Reliability Engineer) conta com um motor que antecipa, também usando modelos, possíveis falhas nos nossos principais fluxos, como o de cadastro e de transação. O que diminui, e muito, nossas falhas e seus impactos.

Conclusão

A plataforma de dados, hoje, conta com diversos recursos como: data lake em camadas, data marts, data pipelines online e batch com data quality, modelos de machine learning online e batch, esteira de MLOps, sandbox para os cientistas etc. Além disso, nós estamos sempre revendo e alinhando nossos objetivos e decisões técnicas, podendo citar como exemplo dessa prática, a não restrição de nossos desenvolvimentos apenas aos serviços AWS, que têm sua expansão para ferramentas open-source.

Em resumo, seguindo essa linha de entregas incrementais direcionadas por objetivos alinhados ao negócio, com uma cultura forte de dados, que direciona o analytics by design, e valorizando governança, a qualidade e a privacidade, conseguimos gerar muito valor para o iti e, como consequência e não finalidade, construímos uma plataforma de dados de ponta, com recursos avançados, a qual temos hoje muito orgulho. Foi uma jornada desafiadora, mas muito gratificante, que envolveu todo o time do iti. Uma jornada de muito aprendizado que está bem longe do fim. Com tudo isso em mente, podemos deixar aqui a seguinte frase: no iti somos apaixonados por tecnologia, uma tecnologia que faça sentido e gere valor para os nossos clientes, uma tecnologia que conta com o apoio de uma cultura orientada a dados para prover nossos serviços, que estão sempre e cada vez melhor!