El dilema arquitectónico: criterios para elegir entre plataformas de datos unificadas y plataformas de lago de datos en la empresa latinoamericana

 Autor: Eduardo Castro Martínez, D.C.E.

Filiación: Doctor en Ciencias Económicas y Empresariales · Consultor en Datos y Analítica

Tipo de trabajo: Documento de criterio técnico

Línea temática: Innovación digital · Arquitectura de plataformas de datos

Palabras clave: Microsoft Fabric, Databricks, arquitectura de datos, decisión tecnológica, lago de datos

Ensayo de divulgación técnica de acceso abierto.

La elección entre dos plataformas de datos no es un problema técnico que admita una respuesta universal, sino una decisión institucional que depende de quién operará la plataforma y para qué.

Una de las preguntas que con mayor frecuencia me plantean los responsables de tecnología de las organizaciones latinoamericanas se refiere a la elección entre dos grandes familias de plataformas de datos. Por un lado se sitúan las plataformas unificadas de datos, que integran en un solo entorno la ingesta, el almacenamiento, el procesamiento, la analítica y la visualización, ofreciendo una experiencia coherente y de baja fricción. Por otro, las plataformas centradas en el lago de datos y el procesamiento distribuido, que ofrecen un mayor control de ingeniería, una flexibilidad superior y una capacidad notable para las cargas de trabajo de gran escala y de ciencia de datos avanzada. La pregunta suele formularse en términos de cuál de las dos es la mejor, y mi respuesta, que a algunos interlocutores decepciona por su falta de contundencia, es que la pregunta, formulada así, está mal planteada.

Este artículo se propone explicar por qué la pregunta está mal planteada y, sobre todo, ofrecer un modo correcto de plantearla. La decisión entre plataformas de datos es demasiado importante, y demasiado costosa de revertir, como para tomarla a partir de una comparación mal concebida.

Por qué la pregunta está mal planteada

La superioridad de una plataforma de datos no es una propiedad intrínseca de la plataforma, sino una propiedad relacional, que depende del contexto en el que la plataforma se evalúe. Esta afirmación es el núcleo del artículo, y conviene desarrollarla con cuidado, porque contradice la forma habitual de plantear la decisión.

Cuando se pregunta cuál plataforma es mejor, se supone implícitamente que la respuesta es la misma para cualquier organización, como si la calidad de una plataforma pudiera medirse en abstracto. Pero la experiencia muestra que no es así. Una plataforma unificada resulta superior para una organización cuyo equipo de datos es pequeño, cuyo personal proviene en mayor medida del análisis de negocio que de la ingeniería de software, y cuya prioridad es entregar tableros y reportes con rapidez y con un mantenimiento manejable. Para esa organización, la integración y la baja fricción de la plataforma unificada son una ventaja decisiva. Una plataforma de lago de datos con procesamiento distribuido resulta superior, en cambio, para una organización que dispone de ingenieros de datos con experiencia, que necesita controlar de manera fina el ciclo de vida de los modelos analíticos, y que opera cargas de trabajo de gran escala o de ciencia de datos avanzada. Para esa organización, el control y la flexibilidad de la plataforma de lago de datos son lo que verdaderamente importa.

La superioridad, en consecuencia, se predica del par formado por la plataforma y la institución, y no de la plataforma considerada en sí misma. Preguntar cuál plataforma es mejor, sin especificar para qué organización, equivale a preguntar cuál herramienta es mejor sin especificar para qué tarea. La pregunta correcta no es cuál plataforma es la mejor, sino cuál plataforma es la mejor para esta organización concreta, con este equipo, estas cargas de trabajo y estos objetivos.

Los criterios de decisión

He llegado a sintetizar la decisión en torno a un conjunto de criterios que conviene examinar en orden, porque cada uno aporta una dimensión del análisis.

El primer criterio es el perfil del equipo. Una plataforma que exige competencias de ingeniería que el equipo no posee se convertirá en una fuente de frustración, por más capaz que sea esa plataforma en abstracto. Conviene examinar con honestidad de qué perfiles dispone la organización, qué formación tienen, qué experiencia acumulan y qué disposición muestran al aprendizaje de nuevas herramientas. Una plataforma poderosa operada por un equipo que no la domina rinde menos que una plataforma modesta operada por un equipo que la domina. Conviene además considerar no solo el equipo presente, sino el equipo que la organización puede razonablemente formar o atraer. Una organización situada en un mercado laboral donde los perfiles de ingeniería de datos avanzada son escasos y costosos debe ponderar esa escasez, porque una plataforma que depende de perfiles difíciles de conseguir la expone a una vulnerabilidad operativa, la de quedar a merced de la disponibilidad de un talento que no abunda. El perfil del equipo, en suma, no es una fotografía del presente, sino una previsión realista de lo que la organización podrá sostener.

La naturaleza de las cargas y la disciplina de ingeniería

El segundo y el tercer criterio merecen un desarrollo conjunto, porque se relacionan estrechamente.

El segundo criterio es la naturaleza de las cargas de trabajo. Las necesidades de la reportería de negocio, que requiere transformaciones de datos relativamente estables y una entrega ágil de tableros, difieren de las necesidades del entrenamiento y el despliegue de modelos de ciencia de datos, que requieren control sobre entornos de cómputo, gestión de experimentos y ciclos de vida complejos. Conviene caracterizar con precisión qué cargas de trabajo predominan en la organización, y cuáles se prevén para el futuro próximo, porque la plataforma adecuada para un perfil de cargas puede no serlo para otro.

El tercer criterio es la disciplina de integración y de despliegue continuo. Las organizaciones que han desarrollado prácticas maduras de control de versiones, de pruebas automatizadas y de despliegue continuo obtienen más valor de las plataformas que ofrecen un control de ingeniería detallado, porque disponen de la disciplina para aprovecharlo. Las organizaciones que no han desarrollado esas prácticas pueden encontrar ese control no como una ventaja, sino como una complejidad que no saben administrar.

El cuarto criterio es la estructura de costos, que merece, por su frecuente mal entendimiento, una sección propia.

El costo como criterio mal entendido

El criterio de costo es, probablemente, el peor comprendido de todos, y conviene una advertencia explícita. Las comparaciones de costo que circulan en el mercado suelen confrontar precios de lista de las plataformas, lo cual induce a un error de apreciación considerable. El precio de lista de una plataforma es solo uno de los componentes de su costo, y rara vez el más importante.

El costo verdadero de una plataforma de datos, el que la organización debe considerar, incluye varios componentes que el precio de lista no captura. Incluye el costo del personal que la opera, que puede variar enormemente según la complejidad de la plataforma y la escasez de los perfiles que requiere. Incluye el costo del tiempo de aprendizaje, durante el cual la organización invierte esfuerzo sin obtener aún el rendimiento pleno. Incluye el costo de los errores derivados de una mala configuración o de un uso inexperto, que en algunas plataformas puede ser significativo. Incluye, finalmente, el costo de oportunidad de las decisiones que la plataforma permite o impide, que es difícil de cuantificar pero que es real.

Cuando se consideran todos estos componentes, una plataforma aparentemente más cara por su precio de lista puede resultar más económica en su costo total, si reduce de manera sustancial el costo del personal especializado que requiere su operación o si acorta el tiempo de aprendizaje. La comparación honesta no es la comparación de los precios de lista, sino la comparación del costo total a lo largo del ciclo de vida, y esa comparación solo puede hacerse para una organización concreta, porque depende de sus perfiles, de su escala y de su contexto. Una organización que decide su plataforma comparando precios de lista está, casi con seguridad, comparando la magnitud equivocada.

La ilusión de la decisión definitiva y el valor de la reversibilidad

Existe una creencia, implícita en la forma en que muchas organizaciones abordan esta decisión, según la cual la elección de una plataforma de datos es un compromiso definitivo, una puerta que se cierra detrás de la organización y que determina su futuro tecnológico por muchos años. Esta creencia genera una ansiedad considerable, que a su vez conduce a postergar la decisión o a tomarla con una rigidez excesiva.

Conviene matizar esta creencia, sin caer en el extremo contrario. Es cierto que cambiar de plataforma de datos tiene un costo, y que ese costo no es despreciable, porque implica migrar datos, reescribir procesos y formar al equipo en un nuevo entorno. Pero también es cierto que las arquitecturas modernas, cuando se diseñan con cuidado, pueden reducir ese costo de cambio. Una organización que almacena sus datos en formatos abiertos y estándar, que separa la lógica de sus transformaciones de las particularidades de la plataforma, y que documenta con rigor sus procesos, conserva un grado de reversibilidad que una organización que se ata profundamente a las particularidades de una plataforma no conserva. La reversibilidad no es absoluta, pero tampoco es nula, y conviene tenerla en cuenta como un criterio adicional. Entre dos plataformas que se ajustan razonablemente a la organización, la que preserva un mayor grado de reversibilidad ofrece una ventaja, porque reduce el costo de una eventual corrección de rumbo. Diseñar pensando en la reversibilidad es una forma de prudencia que las organizaciones rara vez valoran hasta que necesitan cambiar.

La decisión como proceso institucional, no como veredicto técnico

Conviene cerrar con una reflexión sobre la naturaleza de esta decisión, porque de ella depende quién debe tomarla y cómo. La elección de una plataforma de datos suele tratarse como una decisión técnica, que corresponde al área de tecnología y que se resuelve mediante una comparación de capacidades. Esta concepción es incompleta.

La elección de una plataforma de datos es, en rigor, una decisión institucional, porque sus consecuencias exceden con amplitud el ámbito técnico. La plataforma condiciona qué perfiles profesionales necesitará la organización y, por tanto, sus decisiones de contratación y de formación. Condiciona la velocidad con que la organización podrá responder a las necesidades analíticas del negocio. Condiciona la estructura de costos tecnológicos durante años. Una decisión con consecuencias de este alcance no puede ser un veredicto técnico emitido por un área; debe ser un proceso institucional en el que participen quienes comprenden el negocio, quienes comprenden el equipo y quienes comprenden la tecnología. El área de tecnología aporta a ese proceso un insumo indispensable, el de la evaluación técnica de las opciones, pero la decisión, por su alcance, corresponde a la institución en su conjunto. Comprender esto cambia la manera de conducir la elección, porque la convierte de una comparación de fichas técnicas en una deliberación informada sobre el futuro de la organización.

Una recomendación de método

En lugar de recomendar una plataforma, que sería traicionar la tesis de este artículo, lo más recomendable es un método. La organización que enfrenta esta decisión debe, en primer lugar, describir con honestidad su propia realidad, esto es, su equipo, sus cargas de trabajo, su madurez de ingeniería y su horizonte de costos. Esta descripción honesta es el insumo fundamental, y conviene que sea genuinamente honesta, sin sobreestimar las capacidades del equipo ni subestimar la complejidad de las plataformas.

En segundo lugar, una organización debe evaluar las opciones disponibles de plataformas con respecto al estado actual de su realidad, preguntándose para cada plataforma qué tan bien se ajusta a su equipo, a sus cargas y a sus objetivos. La plataforma adecuada será la que mejor se ajuste a esa descripción, y no necesariamente la más avanzada ni la más mencionada en los foros.

He visto fracasar proyectos costosos, y conviene decirlo con franqueza, porque la organización eligió la plataforma que estaba de moda, o la que había adoptado una empresa de referencia, en lugar de la plataforma que correspondía a su propia realidad. El resultado de esas elecciones desajustadas es predecible, una plataforma poderosa pero subutilizada, un equipo frustrado que no logra dominarla, y una inversión que no rinde lo prometido. La madurez de un responsable de tecnología no se mide por su capacidad de nombrar la plataforma más avanzada del mercado, sino por su capacidad de elegir la plataforma adecuada para su contexto, aunque esa elección sea menos vistosa. Esa es, y no otra, la decisión que la innovación digital verdaderamente exige, porque la innovación que no se ajusta a la realidad de la organización no es innovación, sino gasto.