Ninguno de estos términos de uso es mejor ni bueno. Simplemente son diferentes. Tu arquitectura debe respetar la propuesta de valor y los términos de uso. Si te comprometiste con la privacidad absoluta, como Apple, más te vale asegurarte de que no sea una declaración vacía. Si prometiste una mejor experiencia, como Facebook, más te vale implementar y poner en práctica todo lo que sabes.
La semana pasada, te dije que empezaras con dos cosas: una modelo de sujeto para su producto digital y el condiciones de uso de los datos. Te dije que acudieras al verdadero propietario del producto, o gerente de producto, o como sea que llames a la persona responsable en tu organización del éxito del producto en el mercado. Considera a esa persona como tu fuente de información fidedigna.
Este consejo funciona de maravilla cuando vendes el producto digital. La presión del mercado, la propuesta de valor, los ingresos y los costos convierten al propietario del producto en un guerrero feroz. Un verdadero problema de gobernanza de la arquitectura es que casi todos nuestros "productos digitales" son internos. arquitectos empresariales. Nos tocan los problemas difíciles.
Así que afrontemos los desafíos internos de frente. Empecemos por el mundo real.
Demasiados de nuestros responsables de producto terminan siendo meros supervisores del tablero de Jira.
Demasiados de nuestros productos digitales surgen de mandatos internos para "monetizar datos" o tomar mejores decisiones.
A demasiados de nuestros "clientes" se les proporcionan datos operativos mínimos generados por una función anterior que no sabe nada sobre la comunidad posterior.
No podemos simplemente escuchar la dura declaración de Marty Cagan (Silicon Valley Product Group) —si su cliente no puede irse y elegir a un competidor, probablemente sea la administración de TI, no la propiedad del producto— y darnos por vencidos. Nuestra profesión, arquitectura empresarial, existe para guiar el cambio que aborde los problemas que enfrenta nuestra empresa
Utilizamos conceptos como producto digital y monetización para solucionar problemas aún peores que los de un tecnólogo que intenta construir una red de datos sin gobernanza ni control de calidad. Sí, todos hemos vivido esa situación.
Necesitamos comenzar con los datos del producto: sujeto. Pero trazar un límite en una pizarra blanca es lo más fácil. Lo sé, uso una elegante pizarra Microsoft Surface de 50 pulgadas todos los días. Con un simple clic, dibujo cajas, círculos y líneas de conexión. Ahora necesitamos que esos modelos proporcionen una guía práctica.
Esta semana cubriremos el Colisión de línea amarilla. Esas líneas amarillas pintadas que gritan advertencia sobre peligros potenciales al otro lado. Equipos afilados o fuerza aplastante en una fábrica. Trenes a toda velocidad en el metro. O la línea amarilla que divide la autopista.
Casi siempre podemos cruzar la línea. Sin embargo, sin previo aviso, sucede lo malo.
Siempre debemos mirar hacia adelante. El tráfico que viene de frente puede ser mortal.
¿Tráfico en sentido contrario?
Ilusión de CDO
Los límites tienen dueños. Los productos digitales comerciales tienen defensores acérrimos. En nuestra empresa, vivimos en ilusiones. Imaginamos clientes y dueños. Creemos que el organigrama siempre nos indica quién tiene la autoridad para tomar decisiones.
Los propietarios de productos comerciales, que son muy exigentes, son partes interesadas clave. Se les ha asignado un área de responsabilidad: el producto. Tienen objetivos muy claros. Direcciones: expectativas, restricciones, apetito de riesgo. Pueden evaluar el valor de los cambios y, a menudo, formulan requisitos muy claros. Trabajé con un responsable de producto digital que necesitaba reducir los costos transaccionales (95%) de su plataforma. No se trataba de nuevas funcionalidades, ni solo de una mejora de costos. Necesitaban reducir los costos de la plataforma para mantenerse competitivos.
Con propietarios de productos como este gobernanza de la arquitectura Es un sueño. Tienes una parte interesada clara y con autoridad. Alguien que entiende la autoridad que se le ha delegado y el contexto completo de esa autoridad.
Luego tenemos nuestros productos internos. Comenzamos con una línea difusa entre el producto y los datos. A menudo tenemos principios que sugieren compartir los datos. Implicamos que, dado que existen datos, el Enterprise es su propietaria..
En el organigrama encontramos un Director de Datos o una Oficina de Gobernanza de Datos. La mentalidad predominante se dirige al Director de Datos para preguntar y explicar. Dan por sentado que el Director de Datos posee mágicamente todos los datos. Lo más perjudicial es la suposición de que cualquier trabajo para "monetizar", democratizar y crear "mejores decisiones" es indudablemente valioso.
Simultáneamente, en el desarrollo a menudo confundimos agregar una API o ejecutar una extracción con volcar datos en el lago de datos virtual con cambio que mejora nuestra organización.
Cuando nos fijamos en el "Propietario del Producto", nos encontramos con un analista de negocios glorificado, atrapado entre los tecnólogos y una comunidad de usuarios molesta. Llaman a la comunidad de usuarios clientes, aunque Marty nos dice que el cliente debe pagar y puede irse. Estos "propietarios del producto" están ocupados moviendo tickets de Jira. No tienen autoridad. No entienden el valor. Imagínense que supieran que la viabilidad dependía de una reducción de gastos operativos (OpEX) según el código 95%, e impulsaran esa reducción a través del programa digital.
Con propietarios de productos como este gobernanza de la arquitectura está en soporte vital. Tenemos que usar el soporte completo. gobernanza de la arquitectura Conjunto de herramientas para identificar las limitaciones del producto, los objetivos del producto y lo que la organización espera de la función empresarial del consumidor.
Sabemos que nuestra organización es una compleja red de interacciones. Navegar por, para simplificar la complejidad en la que nos apoyamos Modelo de riesgo de SABSA y el concepto de arquitectura superior que se encuentra en TOGAF.
Lo único que busco es el mismo conocimiento y las mismas directrices que preocupan hasta el sueño a mis acérrimos responsables de productos comerciales: mercado, posicionamiento, precio, competencia.
Lo único que busco es alguien que pueda evaluar el potencial alcista, el potencial bajista, el valor, el coste y el riesgo.
Lo único que quiero son los principios básicos de una buena gobernanza: el objetivo, las expectativas de desempeño, las limitaciones y la tolerancia al riesgo.
Y quiero eso para todos los productos digitales.
La colisión de la línea amarilla
Una vez que establecemos la estructura de gobernanza del producto digital, comienza la tensión.
La mayor parte del tiempo trabajamos internamente. Estarás rodeado de ideas de personas que no se rigen por las normas del mercado. Personas que afirman estar alineadas con cualquier estrategia, iniciativa o declaración de liderazgo. Personas que utilizan esa alineación para justificar sus preferencias o mejoras locales.
Ya conocen el argumento de la alineación letal. Se centra en cómo apoyan algo, sin aportar nada significativo. Sabemos que el valor reside en los beneficios que justifican el esfuerzo, sobre todo teniendo en cuenta la incertidumbre asociada a la obtención de dichos beneficios y la incertidumbre del coste.
En el ámbito interno, se prioriza la tecnología. Se presta especial atención a aspectos como la mecánica de extracción de datos de una base de datos operativa. El costo se evalúa de forma tan económica como el de una integración urgente.
Los principios básicos de la calidad y el flujo de datos se desvanecen ante la prisa por hacer algo.
Su organización está utilizando el lenguaje del producto para conducir de forma peligrosa.
Analicemos dos riesgos críticos de los productos de datos.
No puedes vender lo que has robado.
Todo aquel que vende productos de datos vende metodología y procedencia.
Todos.
Cuando no se tienen términos de uso claros que permitan reutilizar los datos, estos son robados.
Los datos robados nunca tienen una procedencia ni una metodología sólidas, en términos de arquitectura de datos: fuente de datos y flujo de datos.
Los datos robados no se monetizan, se almacenan. Estos almacenes ofrecen grandes descuentos porque nadie puede utilizar los bienes robados en el mercado convencional.
En la empresa, los datos robados contaminan incluso un lago de datos virtual. A simple vista, los datos de baja calidad, al carecer de metodología, parecen idénticos a los de alta calidad. Sin embargo, requieren constantemente más refinamiento y posprocesamiento para que resulten útiles.
Con el tiempo, los datos robados generan problemas de cumplimiento normativo, generalmente relacionados con información personal identificable, secretos de clientes o cuestiones jurisdiccionales. En consecuencia, es necesario invertir más dinero para limpiar lo que antes era simplemente un conjunto de datos costosos y sin valor.
Si quieres divertirte un poco, analiza detenidamente el rendimiento de tus compostadores. Como en la mayoría de los compostadores domésticos, apuesto a que verás a gente echando diligentemente las cáscaras en el compostador y yendo a la tienda de jardinería a comprar fertilizante y tierra.
La restricción de custodia
Solucionamos estos problemas mediante una buena arquitectura.
Estamos empezando a crear temas en torno a los datos del producto. Especialmente datos donde nuestro producto digital captura información del cliente. En Navegar por utilizamos una propiedad del modelo para distinguir Datos bajo custodia—datos que pertenecen a otra organización y que solo pueden utilizarse en estricta conformidad con el contrato.
Esta propiedad es el primer pilar de su cerca. Estos límites restringen considerablemente la integración y requieren medidas de seguridad.
La semana pasada mencioné brevemente ServiceNow. Los CI son obviamente custodia, son utilizadas por la aplicación, pero el proveedor de la aplicación nunca tiene motivo para mirar. ¿Qué tal si...? nombres de usuario?
Sí, nombres de usuario. En un sistema de gestión de operaciones de TI SaaS, el cliente los configurará para integrar personas en flujos de procesos, habilitar aprobaciones e incluso enviar alertas mediante llamadas al teléfono personal del usuario. ¿Puede ServiceNow utilizarlos?
Obviamente es conveniente utilizarlos para el acceso y la licencia. Pero si los derechos están restringidos, inmediatamente vuelves al problema de Apple y es posible que necesites encontrar una manera de evitar que los datos se filtren fuera de la red. entorno del cliente. Vimos que Apple usó buenas solicitud y arquitectura de infraestructura centrándose en el límites de ensamblaje. Garantizan la privacidad de tus recuerdos procesándolos en tu dispositivo. Recuerda, prometen no espiar, aunque esta vez te sientas feliz.
Aplique las mismas consideraciones internamente. ¿Qué datos pertenecen al producto digital? ¿Qué medidas se requieren para garantizar que se procesen dentro del producto, para el producto o por el producto?
¿Qué datos están disponibles? ¿Qué datos necesita la empresa?
Uno de nuestros clientes de productos digitales tiene un departamento financiero corporativo muy reducido. Cada familia de productos es responsable de su propia contabilidad y gestión de costes. Los datos financieros que llegan al departamento corporativo son muy limitados.
Este diseño, aparentemente ineficiente, permite que los distintos productos optimicen sus operaciones comerciales y fiscales. El director general puede pasearse por el pasillo y hacer preguntas muy directas. Se espera que los responsables de pérdidas y ganancias conozcan y optimicen todo. No hay lugar para excusas. Debemos aplicar esta misma disciplina a todos nuestros productos digitales.
Defensa de la arquitectura: Recomendación de incumplimiento
A través de esta conversación, he estado destacando cómo persigues los límites. He estado resaltando que los productos digitales son simplemente un problema de gobernanza especializado.
Trátelos como un sujeto, un área de negocio. Al mismo tiempo, trátelos como un dominio de riesgo o gobernanza. Confío en que vea que cada sujeto de datos es también un dominio de gobernanza. Un lugar donde existen objetivos únicos, expectativas de rendimiento, limitaciones y tolerancia al riesgo. Un lugar donde hay una sólida principal interesado.
No dije un solo responsable de la toma de decisiones, dije un sólida parte interesada clave. Los grupos de interés siempre actúan en conjunto. Siempre existen intereses contrapuestos, superposición de autoridad y directrices divergentes. Si fuera sencillo, no necesitaríamos arquitectura empresarial.
Todos mis ejemplos han sido casos en los que necesitábamos proteger el producto digital. Casos en los que utilizamos el ensamblaje para procesar dentro del producto o junto con él. Ese es un caso, y es necesario saber cuándo se aplica.
El otro caso es igualmente cierto: al propietario del producto —la parte interesada clave, el responsable del dominio de gobernanza y el responsable del tema— se le ha indicado que se integre en un todo mayor. Se le pide que utilice el sistema financiero de servicios compartidos.
Ambos modelos son válidos. Cualquiera de los dos puede ser la arquitectura de tu producto digital.
Cuando la gente deja de seguir la arquitectura optimizada para tu negocio y su estrategia de comercialización única, están cruzando la Línea Amarilla. Tarde o temprano, habrá tráfico en sentido contrario.
Para evitar la colisión de la línea amarilla, nosotros, el arquitectos empresariales Ponte en la línea de fuego.
En términos de métodos realizamos gobernanza de la implementación y crear un Recomendación de incumplimiento. Identificar el problema es fácil, pero poco útil. Una recomendación les indica a las partes interesadas qué deben hacer para recuperar el valor que aportaba la entidad objetivo. Ya saben qué beneficios aporta el incumplimiento.
Todo incumplimiento se reduce a:
- Hacer cumplir el objetivo: Modificar para ofrecer el valor esperado de la arquitectura objetivo.
- Conceder ayuda temporal: Posponer la solución del problema.
- Cambiar la arquitectura: Acepte la pérdida del valor original y cree una nueva expectativa de valor con un nuevo objetivo.
Planteamos las opciones para que los líderes adecuados —las partes interesadas— tomen una decisión informada. ¡Y listo! Tendrás la mejor organización posible y el mejor cambio posible. Es un lugar ideal.
Conclusión del caso de la línea amarilla
A menudo asumimos que hay virtud en que las partes interesadas valientes mantengan la posición y hacer cumplir el objetivo. A menudo hay una. A menudo el incumplimiento es una optimización local. O un equipo de proyecto que toma un atajo para lograrlo. día de lanzamiento. O un equipo ágil que se atribuye la victoria. En todos estos casos, están destruyendo el valor que aporta el objetivo.
No tengo la arrogancia de creerme omnisciente. Sé que el mundo se mueve y cambia. Aparecen nuevos enfoques, nuevas herramientas. La suma total del poder creativo empequeñece mi capacidad de razonamiento. un equipo de consultoría increíble. Lo más importante es que cada mañana nuestra empresa es una compañía nueva en una posición nueva.
Yo creo hojas de ruta dinámicas Para darles a mis partes interesadas el control para que tomen las riendas. Utilizo cada incumplimiento como una nueva oportunidad dinámica. Cuando vemos un camino mejor hacia un objetivo mejor, lo adoptamos. Inmediatamente. ¡Y luego lo celebramos! Aprovechamos toda la creatividad y brillantez disponibles. Mi arquitectura es verde y está en crecimiento. ¡Hurra!
Este es mi reto para esta semana: ¿Quién puede responder con autoridad sobre sus productos digitales? ¿Quién asume las ventajas y desventajas de cada decisión? ¿Cuál es la posición en el mercado (contexto empresarial) y los indicadores de éxito (direcciones) de cada producto? ¿Qué limitaciones arquitectónicas superiores imponen a estos productos?
Úsalo para saber dónde está la línea amarilla. Y para extender la metáfora, ¿qué tipo de línea? Esas líneas amarillas dobles en las carreteras de montaña con señales de velocidad reducida son una pista. Encuentra las restricciones que realmente importan.
La próxima semana, en la parte final de este análisis sobre datos y productos digitales, examinaremos la técnica. Las herramientas de trabajo del arquitecto. En concreto, exploraremos dos aspectos. Primero, las estructuras del modelo de Documento Lógico para superar la frontera entre la empresa y un producto digital. Segundo, las especificaciones de arquitectura para traducir los términos de uso y ensamblaje de datos en directrices concretas.
Como siempre, agradezco sus opiniones y comentarios.
¡Qué tengas un lindo día!
Saludos,
Dave
Dave Hornford
Conexiam