Repensando as estratégias de dados nas organizações

Na última década, a tecnologia tornou-se tão complexa e ubíqua que só é explicável, frequentemente, recorrendo a metáforas, que muitas vezes proporcionam uma visão incompleta, quando não enviesada, da realidade subjacente. Assim, temos as "nuvens", os "nevoeiros", as "piscinas de recursos" ou os "lagos de dados", e isto apenas para referir termos de utilização recente.

Tomemos como exemplo os "lagos de dados", ou "data lakes", no original, esses repositórios de dados organizacionais, cuja definição é tão flexível que difere, e muito, na prática, de organização para organização, de fornecedor para fornecedor. Para algumas organizações, os "data lakes" são o futuro dos "data warehouses" (neste caso, os "armazéns" são, também, uma metáfora), enquanto que para outras, são um complemento, podendo coexistir ambos por tempo indefinido.

Há ainda os céticos, que neles mais não encontram do que repositórios para dados que nunca serão convertidos em informação. Entre as empresas nativas da Internet, algumas tentaram criar "data warehouses" baseadas em aproximações tradicionais (caso do Facebook) para, rapidamente, concluírem que não são viáveis quando o volume de dados é da ordem dos milhares de petabytes, crescendo a um ritmo de centenas de milhar de terabytes por dia.

Acabaram por desenvolver de raiz as suas próprias plataformas -- sendo que, depois, muitas vezes colocaram o código desenvolvido em "open source", dando por sua vez origem a expansões significativas dos respetivos âmbitos de aplicação. Muitos dos atuais projetos de plataformas de "big data" desenvolvidos sob a capa da Apache Foundation tiveram, como base, desenvolvimentos iniciados no Facebook, no Twitter, no Linkedin, para além de um conjunto deles, fundamentais, que tiveram origem na Google, desde as primeiras iterações do Hadoop, até ao caso mais recente de Kubernetes e que se destinaram, precisamente, a suprir as limitações das tecnologias tradicionais para armazenamento e processamento de grandes volumes de dados. Mas estes foram, nas respetivas organizações, projetos estruturantes, consumidores de recursos, que tiveram muitos anos de desenvolvimento antes de chegarem à comunidade.

Um desafio comum a muitas organizações é o de não ser por adotarem a metáfora que o benefício se segue automaticamente. Não é por virtualizarem as suas plataformas que constroem uma cloud, tal como não é por criarem um data lake que extraem valor dos dados. Por mais que a ideia seja apelativa, até mesmo a tecnologia mais avançada não é um atalho, se não tiver uma ideia estruturada a suportá-la. É certo que poucas empresas estão dispostas a abraçar projetos de sistemas de informação que durem mais de seis meses ou, quantas vezes, mais do que três.

A implementação rápida, que se confunde indevidamente com "agilidade", o "quick win", é um requisito da maioria dos projetos atuais de IT. O problema é que muitas vezes as questões estruturais são escamoteadas, e os resultados ficam aquém das expetativas. Não era por acaso que os projetos de "data warehouse" era longos e complexos e que o trabalho de ETL (extração, transformação e carregamento) era, de longe, a respetiva parte mais complexa. Um "data lake" não elimina esta complexidade: apenas faz a mudança temporal, passa para jusante em vez de se encontrar a montante.

Não, a mudança de metáfora não é a panaceia para a complexidade organizacional, para o investimento que tem que ser feito na qualidade dos dados antes da análise. A mudança de metáfora deve ser um pretexto para repensar, para alinhar, para planear as estratégias de dados nas organizações. Seja em "piscinas" seja em "lagos", "depois logo se vê" não é - decididamente - estratégia.

Henrique Carreiro | Docente de Cloud Computing e Mobilidade Empresarial na Nova
Information Management School