Erik Gfesser, Arquitecto Principal para la Práctica de Datos de SPR – Serie de Entrevistas

Erik se unió a la práctica de datos del Grupo de Tecnología Emergente de SPR como Arquitecto Principal en 2018.

Erik se especializó en datos, desarrollo de código abierto utilizando Java, y arquitectura empresarial práctica, incluyendo la creación de pruebas de concepto, prototipos y productos mínimamente viables.

¿Qué te atrajo inicialmente a la inteligencia artificial?

Su capacidad para permitir que las aplicaciones aprendan continuamente. Comencé mi carrera de desarrollo como analista de datos senior utilizando SPSS en lo que se convirtió en una empresa de investigación de mercado global, y más tarde incorporé el uso de un motor de reglas de negocio llamado Drools en aplicaciones que construí para clientes, pero la salida de todo este trabajo era esencialmente estática.

Más tarde, trabajé a través de una capacitación de mejora de procesos, durante la cual los instructores demostraron en detalle cómo habían podido mejorar, a través de estadísticas y otros métodos, los procesos comerciales utilizados por sus clientes, pero aquí nuevamente la salida se centró principalmente en puntos en el tiempo. Mi experiencia al trabajar para mejorar un producto de atención médica que mis colegas y yo construimos durante el mismo período es lo que me mostró por qué el aprendizaje continuo es necesario para tales esfuerzos, pero los recursos disponibles en ese momento no existían.

Curiosamente, mi atracción por la inteligencia artificial ha vuelto a su punto de partida, ya que mi asesor de posgrado me advirtió en contra de una especialización en lo que entonces se llamaba inteligencia artificial, debido al invierno de la IA en ese momento. Opté por utilizar términos como ML porque estos conllevan menos connotaciones, y porque incluso AWS reconoce que su capa de servicios de IA es en realidad una abstracción de nivel superior construida sobre su capa de servicios de ML. Aunque algo del hype de ML es irrealista, proporciona capacidades poderosas desde la perspectiva de los desarrolladores, siempre y cuando estos mismos practicantes reconozcan el hecho de que el valor que proporciona ML es solo tan bueno como los datos procesados por él.

¿Eres un gran defensor del código abierto, podrías discutir por qué el código abierto es tan importante?

Un aspecto sobre el código abierto que he necesitado explicar a ejecutivos a lo largo de los años es que el beneficio principal del código abierto no es que el uso de dicho software esté disponible sin costo monetario, sino que el código fuente esté disponible de forma gratuita.

Además, los desarrolladores que utilizan este código fuente pueden modificarlo para su propio uso, y si se aprueban los cambios sugeridos, pueden hacer estos cambios disponibles para otros desarrolladores que lo utilicen. De hecho, el movimiento detrás del software de código abierto comenzó debido a que los desarrolladores esperaban durante mucho tiempo a que las empresas comerciales realizaran cambios en los productos que licenciaban, por lo que los desarrolladores se tomaron la tarea de escribir software con la misma funcionalidad, abriéndolo para que otros desarrolladores lo mejoraran.

El código abierto comercializado aprovecha estos beneficios, siendo la realidad que muchos productos modernos utilizan código abierto bajo la superficie, incluso si las variantes comerciales de dicho software suelen proporcionar componentes adicionales no disponibles como parte de una versión de código abierto, proporcionando diferenciadores así como soporte si es necesario.

Mis primeras experiencias con código abierto tuvieron lugar mientras construía el producto de atención médica que mencioné anteriormente, utilizando herramientas como Apache Ant, utilizado para construir software, y un producto de DevOps temprano llamado Hudson (la base de código de la cual más tarde se convirtió en Jenkins). La razón principal detrás de nuestra decisión de utilizar estos productos de código abierto fue que estos proporcionaban mejores soluciones a las alternativas comerciales, o eran soluciones innovadoras que no se ofrecían en las entidades comerciales, sin mencionar que la licencia comercial de algunos de los productos que habíamos estado utilizando era excesivamente restrictiva, lo que llevaba a una excesiva burocracia cuando era necesario obtener más licencias, debido a los costos involucrados.

Con el tiempo, he visto que las ofertas de código abierto continúan evolucionando, proporcionando la innovación necesaria. Por ejemplo, muchos de los problemas con los que mis colegas y yo luchamos al construir este producto de atención médica se resolvieron más tarde con un innovador producto de Java de código abierto que comenzamos a utilizar llamado Spring Framework, que sigue siendo fuerte después de más de una década, y cuyo ecosistema ahora se extiende mucho más allá de algunas de las innovaciones que inicialmente proporcionó, ahora vistas como comunes, como la inyección de dependencias.

¿Has utilizado código abierto para la construcción de pruebas de concepto, prototipos y productos mínimamente viables? ¿Podrías compartir tu experiencia con algunos de estos productos?

Como expliqué en uno de los principios rectores que presenté a un cliente reciente, los despliegues para la plataforma de datos que construimos para ellos deben seguir realizándose de forma iterativa según sea necesario con el tiempo. Los componentes construidos para esta plataforma no deben esperarse que permanezcan estáticos, ya que las necesidades cambian y se harán disponibles nuevos componentes y características de componentes con el tiempo.

Al construir la funcionalidad de la plataforma, siempre comience con lo mínimamente viable antes de agregar campanas y silletas innecesarias, lo que en algunos casos incluso incluye la configuración. Comience con lo que es funcional, asegúrese de entenderlo, y luego evólvelo. No desperdicie tiempo y dinero construyendo lo que tiene poca probabilidad de ser utilizado, pero haga un esfuerzo por anticiparse a las necesidades futuras.

El MVP que construimos para este producto necesitaba expresamente ser construido de tal manera que se pudieran seguir construyendo casos de uso adicionales sobre él, aunque vino empaquetado con la implementación de un solo caso de uso, para la detección de anomalías de gastos. A diferencia de este cliente, un producto anterior que construí tenía algo de historia detrás de él antes de mi llegada. En este caso, los stakeholders habían estado debatiendo durante tres años (!) cómo deberían abordar un producto que estaban buscando construir. Un ejecutivo del cliente me explicó que una de las razones por las que me trajo fue para ayudar a la empresa a superar algunos de estos debates internos, especialmente porque el producto que él estaba buscando construir necesitaba satisfacer la jerarquía de organizaciones involucradas.

Descubrí que estas guerras de territorio estaban en gran medida asociadas con los datos propiedad del cliente, sus filiales y sus clientes externos, por lo que en este caso toda la lista de características del producto giraba en torno a cómo se ingerirían, almacenarían, asegurarían y consumirían estos datos para un solo caso de uso que generaba redes de proveedores de atención médica para análisis de costos.

Al comienzo de mi carrera, llegué a entender que una calidad arquitectónica llamada “usabilidad” no se limitaba solo a los usuarios finales, sino también a los propios desarrolladores de software. La razón por la que esto es así es porque el código que se escribe necesita ser usable, al igual que las interfaces de usuario necesitan ser usables por los usuarios finales. Para que un producto se vuelva usable, es necesario construir pruebas de concepto para demostrar que los desarrolladores podrán hacer lo que se proponen hacer, especialmente cuando se relaciona con las elecciones de tecnología específicas que están haciendo. Pero las pruebas de concepto son solo el comienzo, ya que los productos son mejores cuando evolucionan con el tiempo. En mi opinión, la base para un MVP, sin embargo, debería idealmente construirse sobre prototipos que exhiban algo de estabilidad, para que los desarrolladores puedan seguir evolucionándolo.

Mientras revisaba el libro ‘Machine Learning at Enterprise Scale’ mencionaste que ‘el uso de productos, marcos y lenguajes de código abierto junto con una arquitectura ágil compuesta por una mezcla de componentes de código abierto y comerciales proporciona la agilidad que muchas empresas necesitan pero no realizan de inmediato’. ¿Podrías entrar en algunos detalles sobre por qué crees que las empresas que utilizan código abierto son más ágiles?

Muchos productos de datos comerciales utilizan componentes clave de código abierto bajo la superficie, y permiten a los desarrolladores utilizar lenguajes de programación populares como Python. Las empresas que construyen estos productos saben que los componentes de código abierto que han elegido incorporar les dan un impulso inicial, ya que estos ya son ampliamente utilizados por la comunidad.

Los componentes de código abierto con comunidades fuertes son más fáciles de vender, debido a la familiaridad que estos traen a la mesa. Los productos comercialmente disponibles que consisten principalmente en código cerrado, o incluso código abierto que es utilizado principalmente por productos comerciales específicos, a menudo requieren capacitación por parte de estos vendedores, o licencias para utilizar el software.

Además, la documentación para dichos componentes no se hace disponible públicamente, lo que fuerza a los desarrolladores a depender continuamente de estas empresas. Cuando componentes de código abierto ampliamente aceptados como Apache Spark son el enfoque central, como con productos como Databricks Unified Analytics Platform, muchos de estos elementos ya están disponibles en la comunidad, minimizando las partes en las que los equipos de desarrollo necesitan depender de entidades comerciales para hacer su trabajo.

Además, debido a que componentes como Apache Spark son ampliamente aceptados como herramientas de industria de facto, el código también se puede migrar más fácilmente entre implementaciones comerciales de dichos productos. Las empresas siempre estarán inclinadas a incorporar lo que consideran diferenciadores competitivos, pero muchos desarrolladores no quieren utilizar productos que sean completamente novedosos porque esto resulta desafiante para moverse entre empresas, y tiende a cortar sus lazos con las comunidades fuertes que han llegado a esperar.

Por experiencia personal, he trabajado con dichos productos en el pasado, y puede ser desafiante obtener un soporte competente. Y esto es irónico, dado que dichas empresas venden sus productos con la expectativa del cliente de que se proporcionará soporte de manera oportuna. He tenido la experiencia de enviar una solicitud de extracción a un proyecto de código abierto, con la corrección incorporada en la compilación el mismo día, pero no puedo decir lo mismo sobre ningún proyecto comercial con el que he trabajado.

Algo más que crees sobre el código abierto es que conduce a ‘acceso a comunidades de desarrolladores fuertes’. ¿Cuán grandes son algunas de estas comunidades y qué las hace tan efectivas?

Las comunidades de desarrolladores alrededor de un producto de código abierto determinado pueden alcanzar cientos de miles. Las tasas de adopción no necesariamente apuntan a la fuerza de la comunidad, pero son un buen indicador de que esto es el caso debido a su tendencia a producir ciclos virtuosos. Considero que las comunidades son fuertes cuando producen discusiones saludables y documentación efectiva, y cuando se lleva a cabo un desarrollo activo.

Cuando un arquitecto o desarrollador senior trabaja a través del proceso para elegir qué productos incorporar en lo que están construyendo, muchos factores suelen entrar en juego, no solo sobre el producto en sí y cómo se ve la comunidad, sino sobre los equipos de desarrollo que adoptarán estos, si estos son una buena opción para el ecosistema que se está desarrollando, qué se ve en la hoja de ruta y, en algunos casos, si se puede encontrar soporte comercial en caso de que sea necesario. Sin embargo, muchos de estos aspectos caen en saco roto en ausencia de comunidades de desarrolladores fuertes.

¿Hay tres libros que podrías recomendar a nuestros lectores?

Estos días leo muy pocos libros de programación, y aunque hay excepciones, la realidad es que estos suelen estar obsoletos muy rápidamente, y la comunidad de desarrolladores suele proporcionar mejores alternativas a través de foros de discusión y documentación. Muchos de los libros que leo actualmente se me proporcionan de forma gratuita, ya sea a través de boletines de tecnología a los que me suscribo, autores y publicistas que se comunican conmigo, o los que Amazon me envía. Por ejemplo, Amazon me envió una prueba de imprenta antes de la publicación de “The Lean Startup” para mi revisión en 2011, introduciéndome al concepto de MVP, y recientemente me envió una copia de “Julia for Beginners”.

(1) Un libro de O’Reilly que he recomendado es “In Search of Database Nirvana”. El autor cubre en detalle los desafíos para que un motor de consulta de base de datos admita cargas de trabajo que abarcan el espectro de OLTP en un extremo, hasta análisis en el otro extremo, con cargas de trabajo de inteligencia empresarial operativa y comercial en el medio. Este libro se puede utilizar como una guía para evaluar un motor de base de datos o una combinación de motores de consulta y almacenamiento, orientado a cumplir con los requisitos de carga de trabajo, ya sea transaccional, analítico o una mezcla de estos dos. Además, la cobertura del autor del “péndulo de base de datos” en los últimos años es especialmente bien hecha.

(2) Aunque mucho ha cambiado en el espacio de datos en los últimos años, ya que se siguen introduciendo nuevos productos de análisis de datos, “Disruptive Analytics” presenta un enfoque accesible, una breve historia de los últimos 50 años de innovación en análisis que no he visto en otro lugar, y discute dos tipos de interrupción: innovación disruptiva dentro de la cadena de valor del análisis, y la interrupción de la industria por innovaciones en el análisis. Desde la perspectiva de las startups y los practicantes de análisis, el éxito se habilita al interrumpir sus industrias, porque el uso del análisis para diferenciar un producto es una forma de crear un modelo de negocio disruptivo o de crear nuevos mercados. Desde la perspectiva de invertir en tecnología de análisis para sus organizaciones, adoptar un enfoque de “esperar y ver” puede tener sentido porque las tecnologías en riesgo de interrupción son inversiones arriesgadas debido a sus vidas útiles abreviadas.

(3) Uno de los mejores textos de negocios de tecnología que he leído es “The Limits of Strategy”, de un cofundador de Research Board (adquirido por Gartner), un think tank internacional que investiga los desarrollos en el mundo de la computación y cómo las corporaciones deben adaptarse. El autor presenta notas muy detalladas de muchas de sus conversaciones con líderes empresariales, proporcionando análisis perspicaz en todo momento sobre sus experiencias al construir (con su esposa) un grupo de clientes, empresas importantes que necesitaban combinar sus estrategias con el mundo explosivo de la computación. Como comenté en mi revisión, lo que distingue a este libro de otros esfuerzos relacionados son dos características aparentemente opuestas: amplitud de industria y la intimidad que solo está disponible a través de la interacción cara a cara.

¿Podrías describir qué hace SPR?

SPR es una consultoría de tecnología digital con sede en el área de Chicago, que entrega proyectos de tecnología para una variedad de clientes, desde empresas Fortune 1000 hasta startups locales. Construimos experiencias digitales de extremo a extremo utilizando una serie de capacidades tecnológicas, desde desarrollo de software personalizado, experiencia del usuario, datos y infraestructura en la nube, hasta coaching de DevOps, pruebas de software y gestión de proyectos.

¿Cuáles son algunas de tus responsabilidades con SPR?

Como arquitecto principal, mi responsabilidad principal es impulsar la entrega de soluciones para los clientes, liderando la arquitectura y el desarrollo de proyectos, y esto a menudo significa usar otros sombreros, como dueño de producto, porque ser capaz de relacionarse con cómo se construyen los productos desde una perspectiva práctica pesa mucho en cuanto a cómo se debe priorizar el trabajo, especialmente cuando se construye desde cero. También me llaman a discusiones con clientes potenciales cuando se necesita mi experiencia, y la empresa me pidió recientemente que iniciara una serie continua de sesiones con mis colegas arquitectos en la práctica de datos para discutir proyectos de clientes, proyectos laterales y qué están haciendo mis colegas para mantenerse al tanto de la tecnología, similar a lo que había organizado para una consultoría anterior, aunque las reuniones internas, por así decirlo, para esta otra empresa involucraban toda la práctica de tecnología, no específica de trabajo de datos.

Durante la mayor parte de mi carrera, me he especializado en desarrollo de código abierto utilizando Java, realizando una cantidad creciente de trabajo de datos en el camino. Además de estas dos especializaciones, también hago lo que mis colegas y yo hemos llegado a llamar “arquitectura empresarial práctica” o “pragmática”, lo que significa realizar tareas de arquitectura en el contexto de lo que se va a construir, y realmente construyéndolo, en lugar de solo hablar de ello o dibujar diagramas sobre ello, reconociendo por supuesto que estas otras tareas también son importantes.

En mi opinión, estas tres especializaciones se superponen entre sí y no son mutuamente excluyentes. He explicado a ejecutivos en los últimos años que la línea que había sido tradicionalmente dibujada por la industria de la tecnología entre el desarrollo de software y el trabajo de datos ya no está bien definida, parcialmente porque la herramienta entre estos dos espacios ha convergido, y parcialmente porque, como resultado de esta convergencia, el trabajo de datos en sí se ha convertido en gran medida en un esfuerzo de desarrollo de software. Sin embargo, dado que los practicantes de datos tradicionales generalmente no tienen antecedentes en desarrollo de software, y viceversa, ayudo a llenar esta brecha.

¿Hay un proyecto interesante en el que estás trabajando actualmente con SPR?

Recientemente, publiqué la primera publicación en una serie de estudios de caso sobre la plataforma de datos que mi equipo y yo implementamos en AWS desde cero el año pasado para el director de información de una consultoría global con sede en Chicago. Esta plataforma consiste en tuberías de datos, lago de datos, modelos de datos canónicos, visualizaciones y modelos de aprendizaje automático, para ser utilizados por departamentos corporativos, prácticas y clientes finales del cliente. Si bien la plataforma central se iba a construir por la organización de TI corporativa dirigida por el director de información, el objetivo era que esta plataforma se utilizaría por otras organizaciones fuera de TI corporativa también para centralizar los activos de datos y el análisis de datos en toda la empresa utilizando una arquitectura común, construyendo sobre ella para satisfacer las necesidades de caso de uso de cada organización.

Como en muchas empresas establecidas, el uso de Microsoft Excel era común, con hojas de cálculo comúnmente distribuidas dentro y entre organizaciones, así como entre la empresa y los clientes externos. Además, las unidades comerciales y las prácticas de consultoría se habían vuelto fragmentadas, cada una haciendo uso de procesos y herramientas dispares. Por lo tanto, además de centralizar los activos de datos y el análisis de datos, otro objetivo era implementar el concepto de propiedad de datos y permitir el intercambio de datos entre organizaciones de manera segura y consistente.

¿Hay algo más que te gustaría compartir sobre código abierto, SPR o algún otro proyecto en el que estés trabajando!?

Otro proyecto (lea sobre él aquí y aquí) que lideré recientemente implicó implementar con éxito Databricks Unified Analytics Platform y migrar la ejecución de modelos de aprendizaje automático a ella desde Azure HDInsight, una distribución de Hadoop, para el director de ingeniería de datos de un gran asegurador.

Todos estos modelos migrados estaban destinados a predecir el nivel de adopción del consumidor que se puede esperar para varios productos de seguros, con algunos que habían sido migrados de SAS hace unos años, cuando la empresa se mudó a utilizar HDInsight. El mayor desafío fue la mala calidad de los datos, pero otros desafíos incluyeron la falta de versionado integral, el conocimiento tribal y la documentación incompleta, y la documentación y el soporte inmaduros de Databricks con respecto al uso de R en ese momento (la implementación de Azure de Databricks había sido puesta a disposición general solo unos meses antes de este proyecto).

Para abordar estos desafíos clave, como seguimiento de nuestro trabajo de implementación, hice recomendaciones sobre automatización, configuración y versionado, separación de preocupaciones de datos, documentación y alineación necesaria en sus equipos de datos, plataforma y modelado. Nuestro trabajo convenció a un científico de datos principal inicialmente muy escéptico de que Databricks es el camino a seguir, con su objetivo declarado después de nuestra partida ser la migración de sus modelos restantes a Databricks lo antes posible.

Esta ha sido una entrevista fascinante que ha tocado muchos temas, siento que he aprendido mucho sobre código abierto. Los lectores que puedan desear aprender más pueden visitar el sitio web corporativo de SPR o el sitio web de Erik Gfesser.