Así pues, esta semana nos alejamos de las hojas de ruta y volvemos al combustible digital: Arquitectura de datos.
Si recuerdas nuestro Serie de datos del otoño pasado, Admití que siempre he tenido una relación difícil con la arquitectura de datos. Es fundamental. No hay grandes arquitectura empresarial existe sin datos y arquitectura de seguridad. Sin embargo, la típica discusión árida y obtusa suele desviarse del tema principal.
Nos apoyamos mucho en el modelo de datos empresariales de DAMA porque simplemente funciona. Esas pocas páginas de DMBOK son oro puro. Tres modelos sencillos...Modelo de sujeto, Modelo de Área Temática (SAM), y Modelo lógico de datos (LDM) Te ofrecemos un modelo de datos empresarial completo. Con 8 a 20 temas y aproximadamente 20 entidades en el SAM, tendrás la base para comprender la gobernanza de datos, el flujo de datos y las necesidades de datos con tan solo 160 a 400 palabras. Eso es todo.
Luego llegamos a un producto digital.
Ya conoces el producto digital que ofrece tu empresa. A veces, toda la empresa está organizada en torno a él, como ServiceNow. Otras veces está profundamente integrado, como en el caso de Apple. Fotos. A veces se ubica junto a los servicios que ofrece su empresa.
Cuando aplicamos el modelo DAMA clásico, tiene dificultades; francamente, se desmorona. Un Sujeto es una actividad empresarial. Comencemos con las actividades empresariales centrales como Venta, Envío, Facturación, y Apoyo. Genial. Aquí tenemos absoluta claridad sobre la gobernanza de datos centrales. El jefe de envíos posee datos de envío. El jefe de ventas Gestiona las ventas. Planifica, vende, envía, factura y ofrece soporte. Los datos fluyen secuencialmente a través de límites organizativos bien definidos.
Por supuesto, la mayoría de los equipos tropiezan con palabras como cliente. Porque comenzaron con datos, no con negocios. Cuando comienzas con el tema (actividad comercial) descubres que las palabras son comprador, receptor, pagador y operador. Cada uno con diferentes relaciones con su empresa: mapee la relación correcta, no un término vago como cliente y todo queda claro.
Aquí se muestra un panorama de datos empresariales. Impresionante. La gobernanza y el flujo de datos saltan a la vista. Se dispone de un vocabulario compartido y claro con la empresa. El "Producto" es simplemente una entidad que se entrelaza con los demás sujetos, estableciendo relaciones de datos adicionales.
Luego, obtienes un producto digital. Tu cliente accede a tu software y escribe sus esperanzas, miedos y sueños (redes sociales). O gestiona su ecosistema de TI (ServiceNow). O su teléfono toma fotografías con fecha y ubicación, y almacena la imagen en tu repositorio de datos.
¿Cómo encajan en su modelo de datos empresariales la expresión de una esperanza, la dirección IP utilizada por el navegador, la dirección IP interna del CI del cliente y la ubicación del teléfono del cliente a las 23:25 del viernes por la noche?
Un lío enredado
La lucha con los productos digitales
Un producto digital es fundamentalmente diferente porque el cliente es adentro La máquina. El producto es integrado en la actividad. El cliente a menudo realiza la actividad sin nosotros.
Pensemos en ServiceNow, una plataforma de operaciones de TI de uso generalizado. El cliente la utiliza para ingresar sus elementos de configuración (CI) y su cartera de aplicaciones. Si no establecemos una distinción clara entre producto y tema, nos enfrentamos a un círculo vicioso. Tampoco podemos aplicar nuestros temas (actividades empresariales) dentro del producto.
Los CI fueron fáciles. Podemos ver claramente que ServiceNow Corporation puede tener un CI utilizado para operar el producto y que no tiene nada que ver con lo que hay dentro del producto. El desafío son los datos que cruzan la línea. Cuando el cliente participa en nuestro proceso de negocio, cuando el cliente crea un ID de ServiceNow utilizado para administrar tickets y proporcionar acceso al producto, ese ID ahora es material para ServiceNow. Sujeto de seguridad, Tema de facturación, Tema de atención al cliente.
Cruzamos el horizonte de sucesos cuando utilizamos datos relevantes para el producto en nuestras operaciones. Las cosas se ponen muy raras cuando se cruza el horizonte de sucesos.
Sencillamente, no cruces el horizonte de sucesos.
Separe explícitamente la arquitectura de datos del producto de la arquitectura de datos de la empresa. En el momento en que comenzamos ese camino, nos topamos con el elefante en la habitación: Condiciones de uso de los datos.
¿Eres la oficina de correos o Facebook?
Separar los datos del producto de los datos empresariales plantea la restricción fundamental: ¿cuáles son los términos de uso de los datos? Utilizamos términos de uso en todas partes. Navegar por Porque nos proporciona una restricción arquitectónica clave. En la época de la arquitectura orientada a servicios, usaba la "prueba del autobús" para explicar las condiciones de uso. Un autobús es un servicio compartido con condiciones de uso estrictas. Un billete da derecho a un pasajero. Un billete en una parada da derecho a un pasajero en una ruta preprogramada. Ese billete, ruta y parada solo son válidos en los horarios programados.
El conductor no pregunta adónde quieres ir, cuándo quieres llegar ni si quieres que te lleven a casa. Tampoco permitirá que un cebra use el billete. Condiciones de uso claras.
Utilizamos una comparación simple y contundente en nuestra trabajos de consultoría. Cuando creas un producto digital, ¿Somos Correos o somos Facebook?
El servicio postal ofrece un servicio vital: el enrutamiento de mensajes desde el remitente hasta el destinatario. Para ello, necesita metadatos muy específicos: la dirección de destino, la dirección de retorno y el nivel de servicio contratado. Pero aquí radica la limitación absoluta: Nunca miran dentro del sobre. Su arquitectura, su gobernanza y sus modelos de datos se basan en la premisa de que el contenido de la correspondencia no les incumbe. Si un empleado de correos abre el correo para analizar tus cartas y venderte publicidad personalizada, eso no es una estrategia de monetización inteligente. Es un delito.
Ahora, Facebook. Facebook es exactamente lo contrario. Sí, al igual que el servicio postal, median la comunicación. Hacen un seguimiento de los metadatos relevantes para operar el servicio. Pero el contenido de tus mensajes Es el motor principal de su modelo de negocio. Abren cada mensaje y lo analizan. Rastrean las acciones del destinatario. Comparan remitentes, destinatarios, temas y todo lo demás. Es como si rebuscaran en nuestro cajón de calcetines para monetizar el contenido, la marca, el tipo y el uso. Porque los Términos de Uso les permiten hacerlo.
Cualquier término de uso puede funcionar. Algunos términos de uso, como los de WhatsApp, están diseñados para una privacidad extrema. Otros, otorgan acceso a todo. Recuerda que esto no es privacidad; ni siquiera Facebook lo hace. publicar Tus esperanzas, sueños y obsesiones. Pero los utilizan. Los utilizan porque los términos del producto se lo permiten. Cuando se infringen los términos de uso, se produce un fallo arquitectónico gravísimo. No se ha logrado establecer los límites.
Los términos de uso siempre los establece el dueño. Propietario del servicio, propietario del producto, propietario de las instalaciones, propietario del área de negocio. Da igual. En la práctica, recurrimos al Propietario del Producto. No a cualquier representante de un equipo ágil, sino a la persona responsable del producto que ofrecemos a nuestros clientes. La persona que puede equilibrar las condiciones de uso aceptables para los clientes con las condiciones aceptables para la empresa. Recuerde, muchos usuarios del transporte público desean un conductor a tiempo completo. Alguien que los espere pacientemente para llevarlos a donde quieran ir. Y ese servicio existe, pero a un precio diferente.
La asamblea como máximo mecanismo de aplicación de la ley
Las condiciones de uso establecen límites que se pueden controlar. La tensión reside en cada límite. La arquitectura prospera al abordar las condiciones límite.
La función "Recuerdos" de fotos de Apple genera tensión. Apple proporciona almacenamiento y uso compartido comunes en su plataforma, lo que se parece mucho a la mediación comunitaria de Facebook. Sin embargo, la propuesta de valor principal de Apple es la privacidad. Defienden ferozmente sus términos de uso. Llegarán incluso a retirar servicios de los mercados cuando no puedan garantizar que nadie pueda acceder a su información. Cajón de calcetines de manzana sin tu participación activa.
En el lado interno no gastan ni un centavo procesando datos de clientes para ejecutar una orden judicial. Porque no puedo mirar. Afirman en el tribunal: No hay puerta trasera.
Luego ofrecen un servicio que revisa y selecciona tus fotos para ti: recuerdos. Sin embargo Sus términos de uso garantizan una privacidad absoluta..
Abordan estas duras limitaciones (Apple no puede mirar y tus fotos son seleccionadas) con fuertes arquitectura de la aplicación. En términos de Navigate, simplemente está usando el Modelo de montaje.
El ensamblaje de funcionalidades es una tarea fundamental para un arquitecto de aplicaciones. Este ensamblaje define los límites de la integración, el ciclo de vida y las dependencias; es el desafío crítico de la arquitectura de aplicaciones. Sabemos que la funcionalidad puede ubicarse en cualquier lugar. Literalmente en cualquier lugar. Se puede integrar en una aplicación empresarial, exponer en un microservicio o incluso incorporar directamente en un ASIC.
Para cumplir con los Términos de uso de datos, Apple opta deliberadamente por implementar la funcionalidad de AI Worker directamente en el dispositivo periférico: tu iPhone. Al concentrar el procesamiento y los datos en un solo lugar, Apple se desvincula físicamente de estos últimos. Renuncian conscientemente a la posibilidad de monetizar al cliente.
Ignora lo que has declarado y las consecuencias negativas te acecharán como buitres. La responsabilidad obliga a recurrir a medidas de protección posteriores, generando complejidad, aumentando la deuda técnica y los costes, además de dejar un cabo suelto en un rincón oscuro.
Cuando tengas términos de uso para tu producto digital, sigue el ejemplo de Apple. Crea la arquitectura de la aplicación, la arquitectura tecnológica y la arquitectura de seguridad que cumplan con los requisitos.
Conclusión: Corta el nudo
Si no se parte de los datos del producto y no se conocen las condiciones del servicio (Facebook, que se dedica a espiar para ganarse la vida; Correos, que lo hace cuando se le indica; o Apple, que no puede espiar), la arquitectura inevitablemente deriva hacia la responsabilidad.
Los desafíos más complejos surgen cuando las operaciones de tu negocio mejoran gracias al uso de los datos del producto. Un ejemplo sencillo es utilizar las identidades que tus clientes mantienen dentro de tu producto SaaS para gestionar el control de acceso o la autorización.
Nunca desatarás el nudo modificando tus temas de "Ventas", "Soporte" u "Operaciones de TI". Eso es como tirar más fuerte de la cuerda. Solo aprieta el nudo. No es diferente a tener una reunión más sobre quién es el dueño del cliente.
Mi desafío esta semana es analizar sus productos digitales. ¿Separan de forma clara y precisa los productos digitales en la arquitectura de su aplicación? ¿Y su arquitectura de datos? ¿O lo mezclan todo en un enredo con los datos para operar? su negocio y soporte de aplicaciones su ¿Negocio? Empiece a destacar sus productos digitales como sujetos. Empiece a indicar explícitamente los Términos de uso. Empiece gobernando su arquitectura siguiendo las instrucciones que se le han dado.
La semana que viene, les mostraré exactamente cómo lo hacemos. Analizaremos cómo definir los límites y establecer restricciones claras. Simplemente, comenzaremos extendiendo el modelo de datos empresariales DAMA estándar y trataremos cada producto digital como un sujeto DAMA.
Como siempre, agradezco sus opiniones y comentarios.
¡Qué tengas un lindo día!
Saludos,
Dave Dave Hornford Conexiam
PD. Si desenredar su arquitectura de datos es fundamental para usted, consulte nuestra Taller de fundamentos de arquitectura de datos. Le ayudaremos a definir sus sujetos, a establecer sus contratos de datos y a garantizar que sus términos de uso guíen su arquitectura, en lugar de perjudicarla.