Erik Gfesser, Arquiteto Principal para a Prática de Dados da SPR – Série de Entrevistas

Erik se juntou à prática de dados do Grupo de Tecnologia Emergente da SPR como Arquiteto Principal em 2018.

Erik se especializou em dados, desenvolvimento de código aberto usando Java e arquitetura de empresa prática, incluindo a construção de PoCs, protótipos e MVPs.

O que o atraiu inicialmente para o aprendizado de máquina?

Sua capacidade de permitir que os aplicativos aprendam continuamente. Eu comecei minha carreira de desenvolvimento como analista de dados sênior usando SPSS em uma empresa de pesquisa de mercado global, e mais tarde incorporei o uso de um mecanismo de regras de negócios chamado Drools em aplicativos que eu construí para clientes, mas a saída de todo esse trabalho era essencialmente estática.

Mais tarde, trabalhei em treinamento de melhoria de processos, durante o qual os instrutores demonstraram em detalhes como eles foram capazes de melhorar, por meio de estatísticas e outros métodos, os processos de negócios usados por seus clientes, mas aqui novamente a saída foi amplamente focada em pontos no tempo. Minha experiência trabalhando para melhorar um produto de saúde que meus colegas e eu construímos durante o mesmo período é o que me mostrou por que o aprendizado contínuo é necessário para tais esforços, mas os recursos agora disponíveis não existiam naquela época.

Interessantemente, meu interesse pelo aprendizado de máquina veio em círculo completo, pois meu orientador de pós-graduação me alertou contra uma especialização no que era então chamado de inteligência artificial, devido ao inverno da IA na época. Eu escolhi usar termos como ML porque esses têm menos conotações e porque mesmo a AWS reconhece que sua camada de serviços de IA é basicamente uma abstração de nível superior construída em cima de sua camada de serviços de ML. Embora alguma das hype do ML lá fora seja irrealista, ele fornece capacidades poderosas do ponto de vista dos desenvolvedores, desde que esses mesmos praticantes reconheçam o fato de que o valor que o ML fornece é apenas tão bom quanto os dados processados por ele.

Você é um grande defensor do código aberto, poderia discutir por que o código aberto é tão importante?

Um aspecto sobre o código aberto que eu precisei explicar a executivos ao longo dos anos é que o benefício principal do código aberto não é que o uso de tal software é disponibilizado sem custo monetário, mas que o código-fonte é disponibilizado gratuitamente.

Além disso, os desenvolvedores que fazem uso desse código-fonte podem modificá-lo para seu próprio uso e, se as alterações sugeridas forem aprovadas, torná-las disponíveis para outros desenvolvedores que o utilizam. De fato, o movimento por trás do software de código aberto começou devido a desenvolvedores que esperavam por muito tempo para que empresas comerciais fizessem alterações em produtos que eles licenciavam, então os desenvolvedores decidiram escrever software com a mesma funcionalidade, abrindo-o para ser melhorado por outros desenvolvedores.

O código aberto comercializado aproveita esses benefícios, sendo que a realidade é que muitos produtos modernos fazem uso de código aberto por baixo dos panos, mesmo quando as variantes comerciais de tal software normalmente fornecem componentes adicionais não disponíveis como parte de uma determinada versão de código aberto, fornecendo diferenciadores, bem como suporte, se necessário.

Minhas primeiras experiências com código aberto ocorreram enquanto construíamos o produto de saúde que mencionei anteriormente, fazendo uso de ferramentas como Apache Ant, usada para construir software, e um produto de DevOps inicial chamado Hudson (a base de código do qual mais tarde se tornou Jenkins). A principal razão por trás de nossas decisões de usar esses produtos de código aberto foi que esses forneciam melhores soluções para alternativas comerciais ou eram soluções inovadoras não oferecidas por entidades comerciais, sem mencionar que a licença comercial de alguns dos produtos que estávamos usando era excessivamente restritiva, levando a excessiva burocracia quando se tratava de precisar de mais licenças, devido aos custos envolvidos.

Ao longo do tempo, eu vi as ofertas de código aberto continuarem a evoluir, fornecendo a inovação necessária. Por exemplo, muitos dos problemas com os quais meus colegas e eu lutamos ao construir esse produto de saúde foram mais tarde resolvidos por um produto de Java de código aberto inovador que começamos a usar chamado Spring Framework, que ainda está forte após mais de uma década, o ecossistema do qual agora se estende muito além de algumas das inovações que ele inicialmente forneceu, agora vistas como comuns, como injeção de dependência.

Você usou código aberto para a construção de PoCs, protótipos e MVPs. Poderia compartilhar sua jornada por trás de alguns desses produtos?

Como expliquei em um dos princípios orientadores que apresentei a um cliente recente, as construções para a plataforma de dados que construímos para eles devem continuar a ser realizadas de forma iterativa conforme necessário ao longo do tempo. Os componentes construídos para essa plataforma não devem ser considerados estáticos, pois as necessidades mudam e novos componentes e recursos de componentes serão disponibilizados ao longo do tempo.

Quando se constrói a funcionalidade da plataforma, sempre comece com o que é minimamente viável antes de adicionar sinos e assobios desnecessários, o que, em alguns casos, até inclui configuração. Comece com o que é funcional, certifique-se de que você entende, e então evolua. Não perca tempo e dinheiro construindo o que tem baixa probabilidade de ser usado, mas faça um esforço para se antecipar às necessidades futuras.

O MVP que construímos para esse produto precisava ser construído de forma que casos de uso adicionais pudessem continuar a ser construídos sobre ele, mesmo que viesse embalado com a implementação de um único caso de uso, para detecção de anomalias de despesas. Ao contrário desse cliente, um produto anterior que eu construí tinha alguma história por trás dele antes da minha chegada. Nesse caso, os stakeholders haviam debatido por três anos (!) sobre como abordar um produto que estavam procurando construir. Um executivo do cliente explicou que uma das razões pelas quais ele me trouxe foi para ajudar a empresa a superar alguns desses debates internos, especialmente porque o produto que ele estava procurando construir precisava satisfazer a hierarquia de organizações envolvidas.

Eu descobri que essas guerras de trincheira estavam amplamente associadas aos dados de propriedade do cliente, suas subsidiárias e seus clientes externos, então, nesse caso, toda a lista de produtos girava em torno de como esses dados seriam ingeridos, armazenados, protegidos e consumidos para um único caso de uso que gerava redes de provedores de saúde para análises de custo.

Mais cedo em minha carreira, eu vim a entender que uma qualidade arquitetônica chamada “usabilidade” não se limitava apenas a usuários finais, mas também a desenvolvedores de software. A razão disso é que o código que é escrito precisa ser usável, assim como as interfaces de usuário precisam ser usáveis por usuários finais. Para que um produto se torne usável, provas de conceito precisam ser construídas para demonstrar que os desenvolvedores serão capazes de fazer o que pretendem, especialmente quando relacionado às escolhas de tecnologia específicas que eles estão fazendo. Mas provas de conceito são apenas o começo, pois os produtos são melhores quando evoluem ao longo do tempo. Na minha opinião, a fundação para um MVP, no entanto, deve idealmente ser construída sobre protótipos que exibam alguma estabilidade, para que os desenvolvedores sejam capazes de continuar a evoluí-los.

Enquanto revisava o livro ‘Aprendizado de Máquina em Escala Empresarial’, você afirmou que ‘o uso de produtos, estruturas e linguagens de código aberto, ao lado de uma arquitetura ágil composta por uma mistura de componentes de código aberto e comerciais, fornece a agilidade que muitas empresas precisam, mas não percebem imediatamente no início’. Poderia entrar em mais detalhes sobre por que você acredita que as empresas que usam código aberto são mais ágeis?

Muitos produtos de dados comerciais usam componentes de código aberto importantes por baixo dos panos e permitem que os desenvolvedores usem linguagens de programação populares, como Python. As empresas que constroem esses produtos sabem que os componentes de código aberto que eles escolheram incorporar lhes dão um impulso quando esses são amplamente usados pela comunidade.

Componentes de código aberto com comunidades fortes são mais fáceis de vender, devido à familiaridade que esses trazem para a mesa. Produtos comercialmente disponíveis que consistem principalmente em código fechado, ou até mesmo código aberto que é amplamente usado por produtos comerciais específicos, frequentemente exigem treinamento por esses vendedores ou licenças para usar o software.

Além disso, a documentação para tais componentes é amplamente não disponibilizada publicamente, forçando a dependência contínua dos desenvolvedores dessas empresas. Quando componentes de código aberto amplamente aceitos, como Apache Spark, são o foco central, como nos produtos Databricks Unified Analytics Platform, muitos desses itens já estão disponíveis na comunidade, minimizando as partes sobre as quais as equipes de desenvolvimento precisam depender de entidades comerciais para fazer seu trabalho.

Além disso, porque componentes como Apache Spark são amplamente aceitos como ferramentas padrão da indústria, o código também pode ser mais facilmente migrado entre implementações comerciais desses produtos. As empresas sempre estarão inclinadas a incorporar o que elas consideram diferenciadores competitivos, mas muitos desenvolvedores não querem usar produtos que são completamente novos, porque isso prova ser desafiador para se mover entre empresas e tende a cortar seus laços com as comunidades fortes que eles vieram a esperar.

Por experiência pessoal, eu trabalhei com tais produtos no passado e pode ser desafiador obter suporte competente. E isso é irônico, considerando que essas empresas vendem seus produtos com a expectativa do cliente de que o suporte será fornecido de forma oportuna. Eu tive a experiência de enviar uma solicitação de pull para um projeto de código aberto, com a correção incorporada à compilação no mesmo dia, mas não posso dizer o mesmo sobre nenhum projeto comercial com o qual eu trabalhei.

Outra coisa que você acredita sobre o código aberto é que ele leva ao ‘acesso a comunidades de desenvolvedores fortes’. Quão grandes são algumas dessas comunidades e o que as torna tão eficazes?

Comunidades de desenvolvedores em torno de um determinado produto de código aberto podem chegar a centenas de milhares. As taxas de adoção não apontam necessariamente para a força da comunidade, mas são um bom indicador de que isso é o caso, devido à sua tendência de produzir ciclos virtuosos. Eu considero as comunidades fortes quando essas produzem discussões saudáveis e documentação eficaz e onde o desenvolvimento ativo está ocorrendo.

Quando um arquiteto ou desenvolvedor sênior trabalha no processo de escolher quais produtos incorporar no que está sendo construído, muitos fatores normalmente entram em jogo, não apenas sobre o produto em si e como a comunidade parece, mas sobre as equipes de desenvolvimento que adotarão esses, se esses são um bom ajuste para o ecossistema que está sendo desenvolvido, o que o roadmap parece, e em alguns casos se o suporte comercial pode ser encontrado, caso isso seja necessário. No entanto, muitos desses aspectos caem em segundo plano na ausência de comunidades de desenvolvedores fortes.

Você revisou centenas de livros em seu site, há três que você poderia recomendar aos nossos leitores?

Esses dias eu leio muito poucos livros de programação e, embora haja exceções, a realidade é que esses normalmente estão desatualizados muito rapidamente e a comunidade de desenvolvedores geralmente fornece alternativas melhores por meio de fóruns de discussão e documentação. Muitos dos livros que eu atualmente leio são disponibilizados gratuitamente para mim, seja por meio de newsletters de tecnologia às quais eu me inscrevi, autores e publicistas que me procuram ou os que a Amazon me envia. Por exemplo, a Amazon me enviou uma prova de impressão não corrigida de “A Startup Lean” para minha revisão em 2011, me apresentando ao conceito de MVP e, recentemente, me enviou uma cópia de “Julia para Iniciantes”.

(1) Um livro da O’Reilly que eu recomendei é “Em Busca do Nirvana de Banco de Dados”. O autor cobre em detalhes os desafios para um mecanismo de consulta de banco de dados para suportar cargas de trabalho que variam do espectro de OLTP em um extremo para análise no outro extremo, com cargas de trabalho de inteligência operacional e de negócios no meio. Esse livro pode ser usado como um guia para avaliar um mecanismo de banco de dados ou uma combinação de mecanismos de consulta e armazenamento, orientado para atender às necessidades de carga de trabalho, sejam elas transacionais, analíticas ou uma mistura dessas duas. Além disso, a cobertura do autor do “pêndulo de banco de dados” nos últimos anos é especialmente bem feita.

(2) Embora muito tenha mudado no espaço de dados nos últimos anos, desde que novos produtos de análise de dados continuam a ser introduzidos, “Análise Disruptiva” apresenta uma abordagem acessível, uma breve história dos últimos 50 anos de inovação em análise que eu não vi em outro lugar e discute dois tipos de interrupção: inovação disruptiva dentro da cadeia de valor da análise e interrupção da indústria por inovações na análise. Do ponto de vista de startups e praticantes de análise, o sucesso é habilitado pela interrupção de suas indústrias, porque usar análise para diferenciar um produto é uma forma de criar um modelo de negócios disruptivo ou criar novos mercados. Do ponto de vista de investir em tecnologia de análise para suas organizações, adotar uma abordagem de “esperar e ver” pode fazer sentido, porque as tecnologias em risco de interrupção são investimentos arriscados devido a suas vidas úteis abreviadas.

(3) Um dos melhores textos de negócios de tecnologia que eu li é “Os Limites da Estratégia”, de um co-fundador do Research Board (adquirido pela Gartner), um think tank internacional que investiga desenvolvimentos no mundo da computação e como as corporações devem se adaptar. O autor apresenta notas muito detalhadas de muitas de suas conversas com líderes de negócios, fornecendo análise perspicaz ao longo do caminho sobre suas experiências ao construir (com sua esposa) um grupo de clientes, empresas importantes que precisavam mesclar suas estratégias com o mundo explosivo da computação. Como eu comentei em minha revisão, o que distingue esse livro de outros esforços relacionados são duas características aparentemente opostas: amplitude de toda a indústria e intimidade que só está disponível por meio de interação cara a cara.

Você é o Arquiteto Principal para a prática de dados da SPR. Poderia descrever o que a SPR faz?

A SPR é uma consultoria de tecnologia digital com sede na área de Chicago, que entrega projetos de tecnologia para uma variedade de clientes, desde empresas do Fortune 1000 até startups locais. Nós construímos experiências digitais de ponta a ponta usando uma gama de capacidades de tecnologia, desde desenvolvimento de software personalizado, experiência do usuário, dados e infraestrutura de nuvem, até coaching de DevOps, teste de software e gerenciamento de projetos.

Quais são algumas de suas responsabilidades com a SPR?

Como arquiteto principal, minha responsabilidade-chave é impulsionar a entrega de soluções para os clientes, liderando a arquitetura e o desenvolvimento de projetos e isso muitas vezes significa usar outros chapéus, como proprietário de produto, porque ser capaz de se relacionar com como os produtos são construídos a partir de uma perspectiva prática pesa muito na forma como o trabalho deve ser priorizado, especialmente quando se está construindo do zero. Eu também sou puxado para discussões com clientes potenciais quando minha especialização é necessária e a empresa recentemente solicitou que eu começasse uma série contínua de sessões com arquitetos da prática de dados para discutir projetos de clientes, projetos paralelos e o que meus colegas estão fazendo para se manterem atualizados sobre a tecnologia, semelhante ao que eu havia executado para uma consultoria anterior, embora as reuniões internas, por assim dizer, para essa outra empresa envolvessem toda a prática de tecnologia, não específica do trabalho de dados.

Para a maior parte da minha carreira, eu me especializei em desenvolvimento de código aberto usando Java, realizando uma quantidade crescente de trabalho de dados ao longo do caminho. Além dessas duas especializações, eu também faço o que meus colegas e eu chamamos de “arquitetura de empresa prática” ou “pragmática”, o que significa realizar tarefas de arquitetura no contexto do que está sendo construído e realmente construindo, em vez de apenas falar sobre isso ou desenhar diagramas sobre isso, percebendo, é claro, que essas outras tarefas também são importantes.

Na minha opinião, essas três especializações se sobrepõem umas às outras e não são mutuamente exclusivas. Eu expliquei a executivos nos últimos anos que a linha que havia sido tradicionalmente traçada pela indústria de tecnologia entre desenvolvimento de software e trabalho de dados não está mais bem definida, parcialmente porque as ferramentas entre esses dois espaços convergiram e parcialmente porque, como resultado dessa convergência, o trabalho de dados em si tornou-se amplamente um esforço de desenvolvimento de software. No entanto, desde que os praticantes tradicionais de dados normalmente não têm antecedentes em desenvolvimento de software e vice-versa, eu ajudo a preencher essa lacuna.

Qual é um projeto interessante que você está trabalhando atualmente com a SPR?

Acabei de publicar a primeira postagem em uma série de estudos de caso em várias partes sobre a plataforma de dados que minha equipe e eu implementamos na AWS do zero no ano passado para o CIO de uma consultoria global com sede em Chicago. Essa plataforma consiste em pipelines de dados, lago de dados, modelos de dados canônicos, visualizações e modelos de aprendizado de máquina, para serem usados por departamentos corporativos, práticas e clientes finais do cliente. Embora a plataforma central fosse ser construída pela organização de TI corporativa executada pelo CIO, o objetivo era que essa plataforma seria usada por outras organizações fora da TI corporativa, bem como para centralizar ativos de dados e análise de dados em toda a empresa, usando uma arquitetura comum, construindo sobre ela para atender às necessidades de caso de uso de cada organização.

Como muitas empresas estabelecidas, o uso do Microsoft Excel era comum, com planilhas comumente distribuídas dentro e entre organizações, bem como entre a empresa e clientes externos. Além disso, unidades de negócios e práticas de consultoria se tornaram isoladas, cada uma fazendo uso de processos e ferramentas divergentes. Então, além de centralizar ativos de dados e análise de dados, outro objetivo era implementar o conceito de propriedade de dados e permitir o compartilhamento de dados entre organizações de forma segura e consistente.

Há algo mais que você gostaria de compartilhar sobre código aberto, SPR ou outro projeto que você está trabalhando?

Outro projeto (leia sobre ele aqui e aqui) que eu recentemente liderou envolveu a implementação bem-sucedida da Plataforma de Análise Unificada da Databricks e a migração da execução de modelos de aprendizado de máquina para ela, a partir do Azure HDInsight, uma distribuição Hadoop, para o diretor de engenharia de dados de um grande segurador.

Todos esses modelos migrados tinham como objetivo prever o nível de adoção do consumidor que pode ser esperado para vários produtos de seguro, com alguns tendo sido migrados do SAS alguns anos antes, quando a empresa mudou para fazer uso do HDInsight. O maior desafio foi a má qualidade dos dados, mas outros desafios incluíam a falta de versionamento abrangente, conhecimento tribal e documentação incompleta e a documentação e suporte imaturos da Databricks com relação ao uso do R na época (a implementação do Azure da Databricks havia sido disponibilizada apenas alguns meses antes desse projeto).

Para abordar esses principais desafios, como um follow-up ao nosso trabalho de implementação, eu fiz recomendações em torno de automação, configuração e versionamento, separação de preocupações de dados, documentação e alinhamento necessário entre suas equipes de dados, plataforma e modelagem. Nosso trabalho convenceu um Cientista de Dados Chefe inicialmente muito cético de que a Databricks é o caminho a seguir, com o objetivo declarado após nossa partida ser a migração de seus modelos restantes para a Databricks o mais rápido possível.

Essa foi uma entrevista fascinante que tocou em muitos assuntos, sinto que aprendi muito sobre código aberto. Os leitores que desejam aprender mais podem visitar o site corporativo da SPR ou o site de Erik Gfesser.