Por: Andrew Brust
En la tecnología, durante mucho tiempo ha existido un debate entre el control centralizado y descentralizado de plataformas, enfoques e implementaciones. Ambos paradigmas tienen validez: el control centralizado asegura la consistencia y el cumplimiento normativo a nivel corporativo, mientras el empoderamiento descentralizado aumenta la probabilidad de que las soluciones tecnológicas sean significativas, contextualmente relevantes y bien adoptadas a nivel de unidad de negocio.
En el mundo de los datos y el análisis de hoy, esta pregunta es muy recurrente. El fuerte impulso hacia las operaciones y la toma de decisiones basadas en datos, provocado por la rápida transformación digital, lo que significa que los trabajadores del conocimiento individual deben hacer que el análisis forme parte de su enfoque diario. Eso, a su vez, impulsa la necesidad de soluciones de análisis que funcionen bien en el contexto del dominio de un equipo en particular. Pero también acelera la implementación de análisis en toda la organización y aumenta la necesidad de que esas implementaciones estén coordinadas y visibles de forma centralizada, para garantizar el cumplimiento de las normas de protección de datos.
¿Conflicto de intereses?
Las unidades de negocio, a veces llamadas “dominios”, tienen responsabilidades (incluidas pérdidas y ganancias) y necesidades específicas. La analítica no es simplemente una búsqueda tecnológica: es un medio para lograr el éxito y el crecimiento. Los dominios comerciales entienden mejor que nadie, incluida la TI, la semántica de sus datos y la forma exacta en que deben estructurarse, combinarse y limpiarse. Los dominios también entienden cuál es la mejor manera de aplicar los datos para uso analítico, y necesitan la libertad para trabajar con sus datos como les plazca, para extraer el máximo valor de ellos y usarlos para optimizar su propio rendimiento y resultados.
Mientras tanto, a TI le gusta mantener el control, la uniformidad y la coherencia entre los sistemas y la forma en que se utilizan en las diferentes unidades de negocio. Eso puede parecer al principio una preferencia arbitraria. Pero en muchas organizaciones, si no se mantiene ese entorno limpio y organizado, TI es responsable de ello.
La mayor parte del tiempo es axiomático: TI debe diseñar y mantener una estrategia y estructura de datos para toda la organización. Y aunque es posible que TI no entienda las minucias de los datos de un dominio en particular, sí tiene y debe tener una comprensión funcional de los datos de la organización de manera más amplia. El hecho de que el dominio comercial sepa mejor qué hacer con sus propios datos no significa que TI no esté informada, que no se preocupe o que actúe voluntariamente como un obstáculo para los objetivos del dominio.
Ambos tienen razón
Aparentemente, estos dos conjuntos de necesidades están en conflicto. Pero este es un asunto de toma y da, no de bien y mal. Los dominios comerciales necesitan autonomía y, al mismo tiempo, TI necesita mantener un control significativo sobre sí mismo.
Incluso si requiere la suspensión de la incredulidad, debemos considerar si se pueden atender ambos conjuntos de necesidades, porque las agendas y las perspectivas de ambos grupos son válidas, importantes y, en un sentido muy real, correctas. Ninguno puede triunfar sobre el otro. Deben coexistir, no solo pasivamente sino cooperativamente.
Los clientes necesitan un equilibrio de enfoques centralizados y descentralizados para recopilar, modelar, transformar, publicar y analizar datos. Lo que puede parecer preocupaciones conflictivas deben combinarse y armonizarse.
Soluciones propuestas
Este debate ha dado lugar a arquitecturas y paradigmas, como Data Fabric, Data Mesh y otros, que reconocen la naturaleza dispersa de los datos, las diversas necesidades de las unidades comerciales y la necesidad de organizar los esfuerzos analíticos en toda la empresa.
Pero estas soluciones todavía tienen una tendencia al desequilibrio. Data Mesh imagina un mundo en el que TI central proporciona y mantiene la infraestructura de datos y tiene el control del gobierno de datos. Prácticamente todo lo demás se delega a los dominios comerciales, incluida la ingesta de datos, el modelado y la transformación en el lado de la creación, y la publicación, producción, evangelización y soporte de conjuntos de datos y fuentes de datos en el lado del análisis. En el mundo de Data Mesh, los dominios comerciales tienen una responsabilidad interfuncional y no solo una autonomía de autoservicio.
Data Fabric, por otro lado, reconoce la distribución física y organizacional de los datos, pero aún puede orientarse hacia la unificación centralizada en la capa lógica. El agregar diferentes servicios de datos y la virtualización de datos permite que permanezcan en su lugar. Pero los modelos de datos siguen siendo universales, y todo el trabajo de innovación e implementación aún puede estar centralizado.
Entonces, todavía nos quedamos con el mismo rompecabezas: ¿cómo en el mundo estos dos intereses aparentemente en conflicto se pueden acomodar al mismo tiempo? ¿Cómo podemos resolver este problema intelectualmente? Y entonces, ¿cómo podemos encontrar una solución adecuada, tecnológicamente?
¿Todos juntos?
Como sucede con muchas cosas en la tecnología, la respuesta radica en la integración cooperativa y las capas de abstracción. Por ejemplo, en el desarrollo de software, la noción de orientación a objetos y herencia permite la creación de clases base, a partir de las cuales se pueden derivar nuevas subclases, muy a menudo definidas dentro del ámbito de un dominio. Las subclases pueden aumentar las clases base, cambiar algunos de sus comportamientos y/o anular elementos de su estructura. Y si algo cambia en la clase base, todas las clases derivadas heredan esos cambios.
Eso es instructivo y alentador porque, en muchas organizaciones, TI debe poder diseñar un modelo de datos para toda la organización que sirva mínimamente como una plantilla de referencia. Sin embargo, los modelos y conjuntos de datos específicos del dominio se pueden construir sobre el organizacional. Esto asegura un nivel predeterminado de definición semántica, incluidas las jerarquías analíticas. Y en lugar de que los dominios comerciales tengan que comenzar desde una “página en blanco”, tienen un punto de partida desde el cual tienen la opción de construir su propia capa semántica, sus propias canalizaciones de datos, sus propios conjuntos de datos materializados y/o virtualizados. vistas de datos
A partir de esos activos, los dominios pueden desarrollar productos de datos completos. Y también pueden promoverlos, apoyarlos, mantenerlos y mejorarlos. Estos productos de datos luego pueden ser utilizados por otros dominios y pueden servir como plataformas de la misma manera que lo hace la capa de datos centralizada. Esto cumple exactamente con lo que prescribe y respalda la metodología Data Mesh.
Aparentemente, entonces, el camino hacia el servicio de análisis centralizado y descentralizado es la composición y la derivación. Permite la autonomía a nivel de dominio sin soluciones fragmentadas, aisladas o separadas.
Un poco de espacio
En el mundo de SAP, esta realidad en capas y autoridad delegada se admite directamente en SAP Data Warehouse Cloud (DWC), a través de la provisión de “Espacios”. Los espacios pueden ejecutarse en cualquier nube. Los espacios se corresponden fácilmente con los dominios comerciales y cada uno puede proporcionar sus propias interfaces y esquemas para las herramientas de análisis y los usuarios. Los espacios de nivel de dominio se pueden construir sobre un espacio centralizado proporcionado por TI, y diferentes espacios de nivel de dominio comercial pueden compartir datos entre sí.
Esto significa que el modelo de datos físicos a nivel raíz puede coexistir con modelos lógicos a nivel de dominio. Esto también funciona lateralmente, de modo que los datos proporcionados en un dominio pueden ser consumidos, enriquecidos e incluso expuestos de manera diferente por otro. Cada dominio comercial tiene control total de su corpus de datos y la capacidad de crear sus propios productos de datos. Esta capacidad se proporciona sin privar a TI del desarrollo y mantenimiento de un marco de datos de toda la organización, y sin impedir que otros dominios tengan su propio control, incluso cuando algunos datos se superponen en varios dominios.
El complemento completo
Un espacio es un contenedor para el conjunto completo de datos y semántica de un dominio. Dentro de cada espacio DWC, se pueden crear tablas, vistas, modelos y flujos de datos específicos de dominio o audiencia. Las capacidades completas de ingesta, transformación, modelado y análisis de datos están habilitadas a nivel de dominio, en lugar de que el negocio se limite a un subconjunto de funcionalidad “paralizado”. Un espacio implementa un modelo semántico completo para los datos de un dominio, en un entorno que es independiente y, sin embargo, no está aislado. Esto brinda a las organizaciones de nivel de dominio (como líneas de negocios o incluso equipos de LOB cruzados) un lienzo sin restricciones para expresar su semántica de datos y desarrollar sus modelos de datos. También evita que esos equipos creen sus productos de datos de forma aislada y garantiza la visibilidad de su trabajo para TI.
Y donde se lleva a cabo un trabajo de dominio, los activos de toda la organización nunca están fuera de alcance. La conectividad y la reutilización de activos en SAP BW se proporciona en DWC, lo que evita la duplicación de esfuerzos y conserva el modelado y los permisos configurados en ese entorno. La conectividad a tablas remotas en fuentes de SAP (incluido HANA, por supuesto) y sistemas que no son de SAP (incluidos lagos de datos, bases de datos y aplicaciones SaaS) proporciona una garantía de reutilización similar.
Recuerde, alrededor del 90 % de todas las transacciones comerciales se realizan a través de aplicaciones de SAP, lo que convierte a BW en un repositorio de análisis autorizado (y a las tablas remotas en una fuente transaccional perfecta) para datos comerciales operativos. Ambos puentes facilitan la independencia a nivel de dominio sin renunciar a la reutilización de los activos de nivel empresarial.
El resultado: las capas de datos centralizadas y descentralizadas no solo coexisten; se federan, cooperan y están compuestos, por lo que son consistentes, aunque distintos.
¡Llegamos!
Se puede otorgar autonomía a nivel de dominio y control creativo, incluso mientras se retiene la participación central de TI. Los entornos de nivel de dominio, incluso cuando están altamente personalizados, aún se pueden coordinar. La TI delegada no tiene por qué ser TI en la sombra, y la innovación no tiene por qué ser “falsa”. La cultura de datos se puede facilitar dentro de las unidades de negocio mientras se mantienen el cumplimiento y la organización en toda la empresa. Los requisitos previos a nivel central no impiden avances a nivel de dominio.
La estratificación y la composición son la clave para equilibrar los requisitos de centralización con la propiedad e independencia a nivel de dominio. El resultado es establecer verdaderas operaciones basadas en datos, en toda la organización y unidad de negocio por unidad de negocio.
Facebook / Twitter / LinkedIn / Instagram
© 2022 SAP SE. All rights reserved. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other countries. Please see http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
