[ ICYMI Lea la Parte 1 La plataforma de datos no escalable ]

En la actualidad, muchas plataformas de datos se construyen de abajo hacia arriba, comenzando por recopilar datos que “podrían ser útiles más adelante” y, gradualmente, se van uniendo soluciones a medida que surgen las necesidades. Este enfoque conduce inevitablemente a una implementación fragmentada, costos crecientes y deuda técnica. El diseño de sistemas de datos requiere conocimientos especializados en modelado de datos, sistemas distribuidos, seguridad y cumplimiento normativo. La mayoría de las empresas simplemente no pueden permitirse contar con equipos de infraestructura de datos dedicados en sus inicios y tienen que construir y adaptar sus sistemas de datos a medida que crecen.

Sin embargo, el camino para hacer evolucionar los sistemas existentes puede ser bastante complicado. Los equipos a menudo tienen que elegir entre largas migraciones manteniendo múltiples sistemas duplicados o una costosa reestructuración completa del sistema. La decisión de Netscape de reescribir su motor de navegador en 1997 les costó su negocio de navegadores y el dominio del mercado a manos de Internet Explorer, ya que no podían competir con los rápidos lanzamientos de funciones de Internet Explorer, lo que finalmente llevó a su disminución de la cuota de mercado. Muchas empresas comienzan con soluciones personalizadas y migran a plataformas de proveedores a medida que crecen; sin embargo, incluso a una escala en la que las empresas pueden permitirse plataformas de proveedores, es posible que aún no se adapten a sus casos de uso y los usuarios internos deben adaptarse a nuevos flujos de trabajo. Muchas empresas terminan creando soluciones personalizadas sobre plataformas de proveedores a medida que continúan escalando. Los equipos de infraestructura interna ahora tienen que mantener sus sistemas originales, operar plataformas de proveedores y brindar soporte a implementaciones personalizadas sobre esas plataformas, al mismo tiempo que capacitan a los usuarios en diferentes herramientas y manejan la seguridad y las integraciones en múltiples sistemas. Debido a la falta de planificación y progreso orgánico a medida que la empresa escala, lo que comenzó como una solución más barata se vuelve significativamente más costoso y complejo de operar.

Hoy en día, diseñar plataformas de datos que puedan escalar con el crecimiento empresarial es más factible que antes. Durante la última década, muchas organizaciones han establecido patrones claros de uso de datos: los equipos de productos necesitan datos sobre el comportamiento de los usuarios, los equipos de marketing rastrean el rendimiento de las campañas, los equipos financieros monitorean las métricas de ingresos y los equipos de seguridad analizan los patrones de amenazas. Estos casos de uso comunes están bien establecidos en términos de qué datos necesitan y con qué rapidez los necesitan. En lugar de descubrir requisitos a través de migraciones costosas y la modernización de las soluciones de los proveedores, es posible construir una plataforma de datos que pueda escalar de manera sostenible en términos de costo y eficiencia operativa.

Diseño de plataformas de datos

En esencia, una plataforma de datos se puede definir mediante dos componentes fundamentales: qué datos se necesitan (modelos de datos) y con qué rapidez se necesitan (requisitos de latencia). Incluso con un caso de uso definido de forma imprecisa, comprender estos dos componentes nos permite derivar sistemáticamente los mecanismos de recopilación de datos y las necesidades de infraestructura.

Tomemos como ejemplo la detección del riesgo de fraude. Normalmente, el riesgo de fraude requiere tres componentes de datos: identidad, transacción y gestión de casos.

Cada componente de datos se puede asignar a la infraestructura en función de las necesidades de latencia. La verificación de identidad y transacciones requiere procesamiento de flujo para la detección de fraudes en tiempo real, el procesamiento de bases de datos maneja el monitoreo y las alertas constantes, y los lagos de datos respaldan tareas de mayor duración, como el análisis de patrones y el entrenamiento de modelos.

Modelos de datos

Un modelo de datos define cómo se deben organizar y estandarizar los datos. Especifica un conjunto de campos y sus características: el formato, el tipo y las reglas para cada campo. Los esquemas permiten el descubrimiento de datos, mientras que las definiciones de campos individuales determinan las políticas de gobernanza y los requisitos de cumplimiento.

Los modelos de datos bien definidos permiten la recopilación y el procesamiento estandarizados de datos en toda la organización. Tomemos como ejemplo los datos de los usuarios: el marketing los necesita para el seguimiento de las campañas, el servicio de atención al cliente para la gestión de casos, los equipos de productos para el análisis del comportamiento y los equipos de riesgo para la detección de fraudes. Sin un modelo de datos de usuarios compartido, cada equipo crea su propia versión de los perfiles de usuario y la lógica de seguimiento. Los equipos terminan creando integraciones complicadas para resolver y conciliar los datos de los usuarios entre sistemas. Un modelo de datos compartido que sirva como una única fuente de verdad simplifica la recopilación e implementación de datos, mientras que los estándares consistentes hacen que la seguridad y el cumplimiento sean mucho más fáciles de gestionar.

A menudo, definir modelos de datos integrales resulta difícil para los equipos individuales, ya que normalmente se centran en sus necesidades inmediatas. Los equipos de marketing se centran en los campos relacionados con las campañas, mientras que los equipos de riesgo se centran en los atributos de verificación de identidad. Sin una visión holística de cómo los mismos datos cumplen distintas funciones, los equipos suelen crear modelos de datos incompletos o con un enfoque limitado que requieren un mayor procesamiento e integraciones entre sistemas.

Requisitos de tiempo

Los requisitos de tiempo definen la rapidez con la que se deben procesar y poner a disposición los datos. Las ventanas de procesamiento varían desde tiempo real (segundos) para decisiones inmediatas, hasta tiempo casi real (minutos) para monitoreo, o procesamiento por lotes (horas) para análisis y aplicaciones de IA/ML. Estos requisitos de tiempo se asignan a opciones de infraestructura específicas: transmisión en tiempo real, bases de datos para tiempo casi real y lagos de datos para procesamiento por lotes.

Sin un marco de trabajo, los equipos de productos suelen crear infraestructura redundante para necesidades similares: un equipo puede usar Kafka mientras que otro usa MSK para la transmisión, o un equipo puede elegir DynamoDB mientras que otro usa Cassandra para las bases de datos. Esto genera una complejidad innecesaria, ya que los equipos mantienen varios sistemas con controles de seguridad e integraciones duplicados.

Al estandarizar los componentes de infraestructura, los equipos de productos ya no necesitan implementar su propia infraestructura y los equipos de plataformas pueden reducir los gastos operativos al mantener menos sistemas. Esta estandarización también permite mejores controles de seguridad, integraciones optimizadas, observabilidad simplificada y costos optimizados.

Plataforma de datos genéricos

Un marco de arquitectura de plataforma de datos nos permite derivar sistemáticamente especificaciones de recopilación de datos, requisitos de infraestructura, controles de seguridad y capacidades de integración. Esto aborda directamente la complejidad y la espiral de costos que enfrentan muchas organizaciones en la actualidad. En lugar de que los equipos creen sistemas separados que los equipos de plataforma tienen dificultades para soportar, un marco coherente simplifica la seguridad, el cumplimiento, la integración y la gestión de costos en toda la organización.

Sin una implementación consistente, los equipos de plataformas se ven constantemente obligados a elegir entre mantener los sistemas existentes, realizar migraciones costosas o crear nuevas funciones. Los equipos de plataformas terminan dedicando la mayor parte de su tiempo a mantener sistemas dispares y a gestionar migraciones en lugar de ofrecer capacidades críticas para el negocio. Un enfoque basado en marcos de trabajo permite a las organizaciones escalar sus plataformas de datos sin migraciones disruptivas. Las organizaciones más pequeñas pueden comenzar con los componentes necesarios y expandirse a medida que crecen, y las organizaciones más grandes pueden estandarizar sus sistemas existentes de una sola vez sin tener que reescribirlos constantemente.

Próximamente

En la Parte 3 de la serie “One Off to One Data Platform” , analizaremos cómo se puede implementar este marco en un nivel práctico. Analizaremos cómo se pueden ensamblar componentes comunes de la plataforma de datos, como streaming, bases de datos, almacén de datos y lago de datos, para respaldar diferentes casos de uso comercial con controles de seguridad y cumplimiento consistentes. A medida que las organizaciones crecen, este enfoque modular permite a los equipos escalar componentes individuales de forma independiente mientras mantienen interfaces y controles estandarizados, lo que elimina la necesidad de migraciones constantes. Con un marco de arquitectura de plataforma de datos claro, las organizaciones pueden crear aplicaciones de datos que crezcan con su negocio en lugar de limitarlo.