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 inicialmente o atraiu para o aprendizado de máquina?

É a capacidade de permitir que as aplicações 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, posteriormente, incorporei o uso de um mecanismo de regras de negócios chamado Drools em aplicações que eu construí para clientes, mas a saída de todo esse trabalho era essencialmente estática.

Posteriormente, trabalhei na melhoria de processos, durante a qual os instrutores demonstraram em detalhes como eles conseguiam 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 era 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 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, minha atração 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, em vez disso, 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 alto nível construída em cima de sua camada de serviços de ML. Embora parte do 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 usam esse código-fonte podem modificá-lo para seu próprio uso e, se as alterações sugeridas forem aprovadas, torná-las disponíveis a outros desenvolvedores que o usam. Na verdade, o movimento por trás do software de código aberto começou porque os desenvolvedores estavam esperando por muito tempo para que as empresas comerciais fizessem alterações nos produtos que eles licenciavam, então os desenvolvedores decidiram escrever software com a mesma funcionalidade, abrindo-o para que outros desenvolvedores o aprimorassem.

O código aberto comercializado aproveita esses benefícios, sendo que a realidade é que muitos produtos modernos usam código aberto por baixo, 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 diferenciais, bem como suporte se necessário.

Minhas primeiras experiências com código aberto ocorreram enquanto eu construía o produto de saúde que mencionei anteriormente, usando ferramentas como Apache Ant, usada para construir software, e um produto de DevOps 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 eles forneciam soluções melhores do que as alternativas comerciais ou eram soluções inovadoras não oferecidas por entidades comerciais, além de o licenciamento comercial de alguns dos produtos que estávamos usando ser excessivamente restritivo, levando a muito burocracia quando se tratava de obter mais licenças devido aos custos envolvidos.

Com o 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 para construir esse produto de saúde foram posteriormente resolvidos por um inovador produto de Java de código aberto que começamos a usar chamado Spring Framework, que ainda está forte após mais de uma década, com seu ecossistema agora se estendendo muito além de algumas das inovações que 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 esperados para permanecer estáticos, à medida que as necessidades mudam e novos componentes e recursos de componentes estarão disponíveis ao longo do tempo.

Quando se constrói funcionalidades de plataforma, sempre comece com o que é minimamente viável antes de adicionar sinos e assobios desnecessários, o que, em alguns casos, inclui até mesmo configuração. Comece com o que é funcional, certifique-se de que você entende, e então evolua. Não desperdice tempo e dinheiro construindo o que tem baixa probabilidade de ser usado, mas faça um esforço para antecipar as 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 em cima dele, mesmo que viesse 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 um histórico por trás dele antes da minha chegada. Nesse caso, as partes interessadas 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 trincheiras estavam amplamente associadas aos dados de propriedade do cliente, suas subsidiárias e seus clientes externos, então, nesse caso, o backlog do produto inteiro 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 custos.

Anteriormente 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 fazer, especialmente quando relacionado às escolhas de tecnologia específicas que 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. Em minha opinião, a base para um MVP, no entanto, deve idealmente ser construída em 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 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, 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 já 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 à mesa. Produtos comercialmente disponíveis que consistem principalmente em código fechado, ou mesmo código aberto que é amplamente usado apenas por produtos comerciais específicos, frequentemente exigem treinamento por parte desses fornecedores 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 em que 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 de tais produtos. As empresas sempre estarão inclinadas a incorporar o que elas veem como diferenciais competitivos, mas muitos desenvolvedores não querem usar produtos que sejam completamente novos, porque isso se prova desafiador para se mudar 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, dado 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 ao build 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 elas 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ão construindo, muitos fatores normalmente entram em jogo, não apenas sobre o produto em si e o que 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 se necessário. No entanto, muitos desses aspectos caem ao lado em ausência de comunidades de desenvolvedores fortes.

Você revisou centenas de livros em seu site, poderia recomendar três para 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 normalmente fornece alternativas melhores por meio de fóruns de discussão e documentação. Muitos dos livros que eu leio agora são disponibilizados gratuitamente para mim, seja por meio de boletins de tecnologia aos quais eu me inscrevo, autores e publicistas que me procuram, ou os que a Amazon (AMZN ) me envia. Por exemplo, a Amazon me enviou uma prova de pré-publicação não corrigida de “O Início 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 uma extremidade, para análise na outra extremidade, com cargas de trabalho de processos operacionais e inteligência 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 oscilante” 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 curta 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 maneira 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, pode fazer sentido adotar uma abordagem de “esperar e ver” porque as tecnologias em risco de interrupção são investimentos arriscados devido a seus prazos de vida útil abreviados.

(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, grandes empresas que precisavam mesclar suas estratégias com o mundo em explosão da computação. Como eu comentei em minha revisão, o que distingue este livro de outros esforços relacionados são duas características aparentemente opostas: amplitude em toda a indústria e intimidade que só está disponível por meio de interação face a face.

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 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 principal é impulsionar a entrega de soluções para os clientes, liderando a arquitetura e o desenvolvimento para os projetos, e isso muitas vezes significa usar outros chapéus, como dono do 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 chamado 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 meus colegas arquitetos na 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 os encontros internos, por assim dizer, para essa outra empresa, envolvessem toda a prática de tecnologia, não apenas específica para 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 desenhando diagramas sobre isso, percebendo, é claro, que essas outras tarefas também são importantes.

Em minha opinião, essas três especializações se sobrepõem entre si 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 a ferramenta entre esses dois espaços convergiu e parcialmente porque, como resultado dessa convergência, o próprio trabalho de dados se tornou em grande parte um esforço de desenvolvimento de software. No entanto, desde que os praticantes de dados tradicionais 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 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 liderada pelo CIO, o objetivo era que essa plataforma fosse 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 em 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. Portanto, 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 o código aberto, a SPR ou outro projeto em que você está trabalhando?

Outro projeto (leia sobre ele aqui e aqui) que eu recentemente liderou envolveu a implementação bem-sucedida da Databricks Unified Analytics Platform 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 de consumidores que pode ser esperado para vários produtos de seguros, com alguns tendo sido migrados do SAS alguns anos antes, quando a empresa mudou para usar o 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 documentação e suporte imaturos da Databricks em 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 desafios principais, 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 de migrar os 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 o código aberto. Os leitores que desejam aprender mais podem visitar o site corporativo da SPR ou o site de Erik Gfesser.