Una sólida arquitectura empresarial libera la implementación para crear valor.

Valor de protección

Hace unos meses, The Open Group nos pidió a algunos de nosotros que actualizáramos el Listas de verificación para la revisión del cumplimiento de la arquitectura. El documento anterior tenía un grave defecto. Implicaba que una lista de verificación de cumplimiento no se había extraído explícitamente de la Arquitectura Objetivo. Implicaba que las restricciones no en la arquitectura debe ser evaluado porque eran buenas ideas. Esto no es gobernanza que protege el valor. Esto es aplicar opiniones, preferencias y pensamiento perezoso. Nunca confunda opinión y preferencia con gobernanza de la arquitectura.

Para corregir el error, nos inclinamos hacia el Lista de verificación de gobernanza para la implementación de TOGAF primera pregunta:

• ¿Interpretó la organización que emprendió el cambio de forma razonable las directrices y limitaciones de la arquitectura objetivo?
  Si es así, acepte su interpretación como conforme y aborde cualquier problema mediante un cambio en la arquitectura.

Qué pregunta tan poderosa. ¿Interpretaron razonablemente las personas que ejecutaron el cambio las directrices y las restricciones en la arquitectura objetivo? Esto es Gobernanza de la implementación 101—expectativas de desempeño, limitaciones y tolerancia al riesgo.

Orientación y limitaciones será:

• Especificaciones de arquitectura
  Propiedad, principio, patrón, estándar, regla
• Brecha o paquete de trabajo
• Criterios de aceptación para un VRP

Dentro de la arquitectura, todo orientación y limitaciones son rastreables hasta:

• Beneficios que queremos ganar
• Aspectos negativos que queremos evitar
• Incertidumbre que debemos mitigar

S55 y P33 como guía y restricciones

Al observar las propiedades básicas de Capacidad (Competencia, Agilidad, Automatización y Eficiencia), las directrices y las restricciones saltan a la vista.

S (Superior) significa que queremos estar más allá de la frontera de productividad y inventar las próximas mejores prácticas. En lo que respecta al software, se trata de un desarrollo a medida. No puedes comprar algo mejor que los demás.. Alguna vez.

P (Paridad) Quiero estar en el punto óptimo de la frontera de productividad. Justo donde la curva de costos para el siguiente incremento deja de ser lineal y se curva hacia arriba. Sabes que cuando pisas el acelerador, el tacómetro salta otras 1000 RPM. Pero el velocímetro apenas se mueve un poco. Eso es más allá de la paridad. Cuando empiezas a trabajar demasiado para el siguiente incremento. En términos de software, busco un conjunto que abarque toda la capacidad. Donde las prácticas y métricas estándar de la industria estén preconfiguradas. Donde pueda contratar a cualquiera de entre un sinfín de consultores que tienen un manual de procedimientos predefinido.

La eficiencia me indica cuán importante es la productividad. ¿Puedo gastar más para obtener el resultado comercial esperado? ¿O tengo que invertir para lograr una entrega más eficiente? ¿La misma calidad? Nuestro modelo mental se centra en la fabricación: pasar de herramientas manuales a un torno y luego a una máquina CNC. Después, externalizar la fabricación de la CNC para obtener un componente adicional por cada $.

La eficiencia me indica que no debo buscar una mayor calidad ni agilidad. A menudo, la eficiencia está ligada a la automatización, pero no siempre. Una alta eficiencia puede indicarme que no debo automatizar. No ganamos eficiencia con los robots forestales. El precio por árbol simplemente aumenta.

Como un arquitecto empresarial acostumbrado a trabajar con Navegar por y modelos formales, Cuando veo que las directrices y restricciones de A35, P33 o P43 saltan a la vista, me confundo al olvidar qué propiedades están en la notación abreviada.

Trabajando en Fase F En la transición entre arquitectura e implementación, utilice el concepto TOGAF de contrato de arquitectura. Expresar claramente las inferencias en directrices y restricciones explícitas.

Haz lo básico: documenta los criterios de adquisición. Al fin y al cabo, Parity exige que establezcamos puntos de referencia y alcancemos el punto en el que la curva de calidad deja de ser lineal. El departamento de compras debería buscar una suite estándar con cobertura lista para usar, junto con un implementador con un manual de instrucciones. Una A (Ventaja) exige un paquete especializado y un implementador con experiencia demostrada en la optimización de la productividad.

Si confundimos estas directrices de adquisición, pagaremos de más por el producto y no lograremos el beneficio esperado.

Mezclar estas directrices de adquisición significa que no pudimos brindar el apoyo necesario. arquitectura empresarial. Punto final. No logramos apoyar el negocio. Fracasamos en nuestro propósito profesional.

Analicemos esto detenidamente. La orientación en materia de adquisiciones es fundamental. Para una funcionalidad de paridad, no importa lo sofisticado que sea el software especializado, ni la excelente asesoría del consultor de vanguardia. Al final, estabas comprando clavos de platino para marcos. Un desperdicio de 100%.

Si te equivocas con las instrucciones para obtener una A (Ventaja), no lograste entregar el trabajo. valor requerido. Valor requerido que exigía un resultado especial. Francamente, decirme qué gran oferta conseguiste en una implementación empaquetada es testificando para la fiscalía en su juicio.

Ve más allá, documenta un paquete de trabajo. Siempre pienso en los "criterios de aceptación" cuando documento un paquete de trabajo. Dile al implementador cómo hacerlo. saber cuándo están terminados. Esto es muy importante cuando se utiliza un punto de transición. Es necesario indicarle explícitamente al implementador que detener. La mayoría de los implementadores asumirán que deben llegar hasta el objetivo final. Por lo tanto, añadirán trabajo extra de forma encubierta.

Hace unos años, estábamos mejorando un equipo de operaciones de TI. Transición 1 El objetivo era implementar la observabilidad elástica en un centro de datos. Necesitábamos demostrar una mejora en las operaciones antes de escalar Elastic a todas las instalaciones. Durante gobernanza de la implementación, Hubo un millón de intentos por parte del equipo de implementación para Haz lo obvio y desplegar Elastic en todas partes. Vieron el algo obvio, y observé un esfuerzo deliberado por postergar la adquisición de la experiencia y los cambios en las prácticas operativas que justificaban la expansión de la presencia.

Tomémonos un momento para explicar la ecuación de valor.

El valor no era Observabilidad elástica instalada. Ese es un proyecto tarea. El proceso de aprobación es sencillo: el producto está instalado, los usuarios están capacitados y se ejecutan los casos de prueba.

El valor era mejores operaciones. Esto no es una tarea de proyecto, es desarrollo de capacidades. ¿Cuándo empezamos? usando ¿Elastic encuentra problemas que activan al SRE para realizar cambios y prevenir interrupciones y ralentizaciones? ¿Cuándo empieza el equipo de desarrollo? usando Elastic ¿Busca problemas de rendimiento y un uso costoso de la infraestructura? Entonces trátelos como defectos en la lista de tareas pendientes. El valor provino de cambios operativos.

Sé que puedes ver cómo lo obvio de abajo hacia arriba Esto reduce activamente el valor esperado. La prisa por ampliar la presencia de Elastic retrasa el momento en que la empresa empiece a obtener beneficios de su inversión en Observability.

Elastic era solo un medio para un fin. Sin el valor entregado, estábamos preparados para abandonar Elastic—para cambiar de rumbo.

Conclusión de Liberar la Implementación para Crear Valor

Cuando mi arquitectura objetivo aprobada dice P33, mi parte interesada decidió explícitamente obtener Parity y automatización y eficiencia promedio. Lo están diciendo explícitamente: '''Renunciaré a las optimizaciones extravagantes que sean posibles.." ¡Explícitamente! Están diciendo que reservarán nuestros escasos recursos intelectuales y capital para donde nuestra organización exige más. Hasta el punto en que no podemos simplemente aprovechar la funcionalidad OOTB y los servicios empaquetados.

Donde nosotros exige más Quiero aprovechar el poder creativo de mis implementadores. Son los más cercanos a mí. haciendo el trabajo. Invariablemente tienen conocimiento más profundo del dominio. Sin embargo, cada directriz y restricción elimina un grado de libertad.

Mis restricciones deben ser rastreables hasta el valor del implementador. no puede ver y no tendrá valor. Nunca necesito decirle a un equipo de producto digital sólido que... deleitar al usuario. Pasan tiempo con el usuario. Pueden ver ceños fruncidos, sonrisas y todo tipo de gestos divertidos. La mayoría de los usuarios incluso les contarán sus placeres secretos.

Necesito decir: "Estos son los tres patrones aceptables de implementación de datos maestros". Necesito que utilicen estos tres patrones. incluso si provoca que los usuarios se lamenten. Debo decir: "Utilizarás una integración basada en mensajes (porque necesito la libertad de agregar, eliminar y modificar a cada jugador en el proceso.)." Impondré la integración basada en mensajes aunque genere más trabajo. Aunque los usuarios se queden afónicos llorando.

De nuevo, detengámonos un momento para explicar la ecuación de valor. A veces, mi función de apoyo a las partes interesadas exige mano dura. Cuando mis partes interesadas buscan Agilidad 4 o 5, no quieren libertad; la exigen. Están dispuestos a pagar facturas y aceptar que otras prioridades se vean afectadas para conseguir esa libertad.

Libertad para reaccionar al éxito de ventas e incorporar un servicio completamente nuevo al producto. Libertad para reemplazar a esos usuarios con un ejército de bots de IA. Libertad para reemplazar a los consumidores de mensajes posteriores con un tercero.

Hace unas semanas dije:'Cuando mis partes interesadas tomen una decisión firme, la asumiré como si fuera la mejor idea del mundo..'Agilidad 4 o 5 es una decisión resuelta; me dijeron que la prioridad es la libertad de reaccionar ante cualquier amenaza u oportunidad. Para asumir la decisión resuelta, diseñaré un valla de agilidad empresarial. Cuando diseño un valla de agilidad, Esa valla importa más que cualquier baile de mesa local. Estoy dispuesto a hacerla cumplir. Aunque haya lamentos y crujir de dientes. Aunque el equipo de sprint publique comentarios sarcásticos sobre EA en Slack.

Me haré responsable de las decisiones firmes de cada parte interesada. Durante todo el día.

Mi desafío de esta semana se centra en el valor. Observa tu trabajo de arquitectura actual. Observa los productos digitales en desarrollo. Observa un proyecto en curso. ¿Sabes cuál es el valor esperado? valor empresarial ¿Sabes cómo ese trabajo mueve la cartera necesaria? ¿Puedes rastrear la guía de adquisiciones hasta una P? ¿Y hasta una A o una S? ¿Proporcionaste esta guía?

La pregunta realmente difícil: ¿sabes cuándo intervenir? ¿Cuándo llevar a los implementadores ante una parte interesada? Hacer que expliquen por qué creen que usar los escasos recursos de la parte interesada no garantiza valor esperado para las partes interesadas Es un comportamiento aceptable. Hazlo un par de veces y sucederán dos cosas: tus partes interesadas te enviarán regalos y recibirás menos comentarios sarcásticos sobre EA en Slack. Sí, los regalos para las partes interesadas son algo real.

La semana que viene vamos a volver a usar los puntos de reposo de valor para detener, pivote, y incluso continuar. Todos los demás dan por sentado que el mundo seguirá igual, que la continuidad es un hecho. Usted y sus partes interesadas observan cómo se desarrolla el mundo real. El mundo real tiene infinitas oportunidades emocionantes y amenazas aterradoras. Su hojas de ruta de arquitectura están llenos de rampas de salida. Exploraremos la mecánica de detener, pivote, y continuar.

¡Que tengas una gran semana! Mañana es Día de Canadá!

Como siempre, agradezco sus comentarios y preguntas.

Saludos,

Dave
Dave Hornford
Conexiam

PD: Mach 2 a $10,000 por asiento redujo el Atlántico, para los pocos que lo necesitaban. Todos los demás vuelan en clase económica en un Boeing. Invertir en Superior o Parity es una decisión deliberada de diseño empresarial. Cuando nuestros grupos de interés toman esa decisión, están dando instrucciones inequívocas. Aproveche nuestra Guía de planificación basada en las capacidades.