Comencemos con una realidad incómoda. Los límites obligatorios nunca coinciden con las preferencias locales. Si así fuera, no los necesitaríamos. Necesitamos estos límites para brindar los beneficios que un responsable de la toma de decisiones local, especialmente un equipo de implementación local, jamás verá.
La otra dura realidad es que la mayoría de las indicaciones son una distracción de las preferencias locales. Piénsalo, La semana pasada mi ejemplo CEO Dirigió a la familia de productos A a vender más cosas a su mercado actual, Familia B a aumentar los precios con éxito, y la familia C a reducir sus costos. Nadie consiguió el trabajo genial y emocionante de inventar productos nuevos e increíbles, o de conquistar nuevos mercados exóticos.
Las familias de productos A, B y C fueron sometidas a un trabajo arduo y a límites estrictos.
Se les dieron expectativas y limitaciones de desempeño claras. El director ejecutivo utilizó los principios básicos de buen gobierno.
El director ejecutivo tampoco dejó escapar a las unidades de negocio de apoyo. A TI se le asignó una misión compleja. La máxima prioridad era... menores costos de TI en relación con los ingresos. Debajo subyacía el requisito fundamental de justificar continuamente la existencia de TI. La entrega de las actividades principales (Producto) ofrecía una ventaja de eficiencia gracias a la escalabilidad de un servicio compartido. Al fin y al cabo, sin esta ventaja, la justificación para dar soporte a la unidad de negocio se desvanecía.
Esta es la incómoda raíz de TI en la sombra, Finanzas en la sombra, y Recursos Humanos en la sombra—No superaron la prueba de ventaja competitiva. Se permiten los servicios compartidos en la sombra cuando los equipos principales tienen que hacer algo innecesario: distraerse de la satisfacción del cliente y replicar los servicios de un proveedor de servicios compartidos deficiente.
Toda esta fricción y complejidad para obtener lo mejor de ambos mundos: atención focalizada, creatividad y las limitaciones necesarias.
Ya conoces mi tesis, nuestra profesión arquitectura empresarial Existe para superar la fricción y la complejidad.
Como un arquitecto empresarial, Mi trabajo consiste en ayudar a quienes toman las decisiones a comprender cuándo un requisito de servicio compartido, aparentemente irrazonable, representa el mayor valor. Mi trabajo también consiste en maximizar el margen de decisión local.
Me gano la vida en los límites del espacio negativo de Carver. Ofreciendo la menor restricción posible. Impulsando la mayor libertad local. La libertad local es donde obtenemos atención focalizada, creatividad y conocimiento especializado para lograr lo imposible.
Nuestras organizaciones no surgieron de un gigantesco y perfecto Plan Quinquenal soviético. Surgieron de mil millones de decisiones locales. Cada decisión local optimizó los beneficios y los costos reales.
Para maximizar la autoridad local, mi Equipo de consultoría de EA Cuestionamos activamente nuestras limitaciones. Nos preguntamos si son necesarias. Si lo son, ¿podemos simplificarlas? Podemos transformar una regla estricta en estándares, los estándares en patrones, los patrones en principios, y los principios en la ausencia total de limitaciones.
Nos burlamos unos de otros sobre nuestra infalibilidad y omnisciencia. ¿Probamos explícitamente si una elección diferente importa? Y, si importa, por qué?
Si no podemos afirmar por qué es importante, no podemos justificar la eliminación de la libertad local. Sin esa justificación, simplemente estamos cometiendo el error de privilegiar nuestra opinión. Entiendes la broma: privilegiar nuestras opiniones solo puede justificarse por nuestra omnisciencia e infalibilidad.
De manera pragmática, nos dirigimos por patrones de arquitectura—un enfoque exitoso y demostrado para un problema predecible. Si no puede encontrar un enfoque exitoso y demostrado para un problema predecible, probablemente debería esperar atención especializada, creatividad y conocimientos específicos. Entonces, espere lo imposible.
En el Plantilla de patrón de navegación insistimos en que parte difícil—las limitaciones y el trabajo requerido para el éxito del patrón. Después de todo, si no quieres, o no puedes, hacer el parte difícil El patrón es no es un enfoque que haya demostrado ser exitoso. Cuando no queremos, o no podemos, hacer la parte difícil Este diseño dará como resultado un cañón intransitable más costoso.
Pienso en los implementadores como mis implementadores. Parte de mi equipo. Especialistas capaces de aplicar atención focalizada, creatividad y profundo conocimiento—genio creativo aplicado.
Los implementadores que trabajan bajo dirección y con limitaciones son una maravilla. Cada día logran lo imposible.
Todo lo que necesito es explicarles las reglas del juego y cómo se lleva la puntuación: las expectativas y limitaciones de rendimiento. ¡Quítate del camino!
Esta semana profundizaremos en el uso de gobernanza de la implementación a conseguir lo imposible. Sé que el enfoque normal es lanzar gobernanza de la implementación como una batalla distópica entre implementadores astutos que engañan al arquitecto controlador y autoritario.
¡Disparates!
Hace unos segundos el cruce parecía seguro.
TOGAF afirma que los implementadores son responsables de las decisiones de implementación.
Justo en el Marco TOGAF Guía para profesionales Sección 15.2 (Funciones, deberes y derechos de decisión), ""Todos los derechos de decisión sobre las opciones de implementación propuestas, como el diseño, la selección del producto y la secuencia de cambios, recaen en el implementador.."
Sin ambigüedades. Los responsables de la implementación son dueños de todas las decisiones de implementación.
Tan inequívoco como ''Las partes interesadas son propietarias de la arquitectura. Proporcionan prioridad, preferencia y dirección. Todos los derechos de decisión sobre la Arquitectura Objetivo, así como cualquier alivio o cumplimiento de la misma, recaen en las partes interesadas..'
Sin ambigüedad. Los interesados son dueños de todo. decisiones de arquitectura.
Combinamos las declaraciones de la Sección 15.2 (derechos de decisión de las partes interesadas y derechos de decisión del implementador) con el espacio de decisión sin restricciones de Carver. Utilizando el lista de verificación de gobernanza de implementación y todo encaja a la perfección.
¿Interpretó razonablemente el implementador las directrices y restricciones de la arquitectura objetivo?En términos de Carver, ¿siguieron las expectativas y restricciones de desempeño explícitas que rodeaban su espacio de decisión?
Como ya he dicho, explícales cómo se juzga la victoria. Añade las restricciones mínimas. Apártate del camino. Espere excelencia.
Dar sus implementadores un problema fácil. Dales un problema difícil. Dales un problema endiablado. No importa, porque si lo saben las reglas del juego Lograrán todas las victorias posibles. Todas las victorias posibles. Siempre.
De ello se deduce que arquitectos empresariales definimos claramente las reglas del juego—cómo se lleva la puntuación y qué no está permitido. Nuestras herramientas de trabajo: brechas, paquetes de trabajo, VRP, hojas de ruta dinámicas y especificaciones arquitectónicas. Orientación, restricciones y máxima libertad local.
Francamente, apartándose del camino es una de las cosas más difíciles de las mejores prácticas arquitectos empresariales Sí. Somos solucionadores de problemas apasionados y comprometidos.
Para definir un objetivo, debo pensar en una forma plausible de alcanzarlo. Sin una implementación plausible, la incertidumbre aumenta exponencialmente, anulando por completo el beneficio.
Eso implementación plausible es la forma en que yo lo haría. Se ajusta a mi experiencia, preferencias y prejuicios. Puedo enumerar las razones obvias para hacer las cosas. a mi manera. Cuidado. Hay un paso muy corto de enamorarse de la la forma en que yo lo haría a pretender omnisciencia e infalibilidad.
Para desarrollar especificaciones de arquitectura, necesito deshacer la omnisciencia y la infalibilidad. Necesito cambiar la forma en que yo lo haría a reglas. Luego, transforma las reglas en estándares, los estándares en patrones, los patrones en principios. Siempre buscando la última transformación, la ausencia total de restricciones.
Enamorarse de mi enfoque lleva al fracaso de la arrogancia. Instintivamente, añadimos más y más restricciones. Cada restricción injustificada. Cada una erosionando nuestros implementadores' libertad. Cada uno limitando su creatividad y genialidad.
Haz una pausa y piénsalo. Cuando liberas la experiencia, la pasión, la creatividad y el genio del dominio sus implementadores Siempre te harán lucir bien. Muy bien.
Hacen que nuestras ideas se hagan realidad.
Hacen realidad las esperanzas y los sueños de las partes interesadas.
Transformarán nuestra organización.
Cuando las cosas salen mal
Las cosas siempre salen mal.
Puede ser algo tan simple como un flujo de datos heredado. Puede ser tan insidioso como una decisión de implementación tomada hace décadas. Puede ser la presión del tiempo.
Puede que me hayas escuchado y luego me hayas dado sus implementadores un problema difícil, un problema más difícil y, finalmente, un problema perverso. A veces, para seguir con mi metáfora deportiva, nuestros implementadores Simplemente no pueden meterla en la red. A veces no pueden ganar el partido.
En ese triste día pasamos a lista de verificación de gobernanza de implementación preguntas 2 a 7.
Las preguntas 2 a 7 son muy parecidas a desarrollar un objetivo. La diferencia es que ya estamos gastando, por lo que cada elección tiene costos que asumir. Nuestro papel es guardia el máximo beneficio.
Para pensar en el beneficio, corro hacia el Navegar por heurística de valor:
Valor = Beneficio/Incertidumbre - ((Costo_Implementación^Incertidumbre) + (Costo_Operaciones^Incertidumbre))
Recurro a la heurística porque cuando algo sale mal, sucede una de dos cosas:
- El beneficio esperado está desapareciendo.
- Los costos previstos están aumentando
O, en el peor de los casos, el beneficio desaparece y los costos aumentan. Sea cual sea el cálculo, el valor disponible se está esfumando.
Volvamos a mi sencillo Ejemplo de observabilidad elástica de EA fuerte. Estamos implementando Elastic. Esperamos dos beneficios. Primero, las operaciones de TI tendrán mejores perspectivas y podrán gestionar un mejor entorno de aplicaciones/infraestructura. Segundo, el desarrollo de aplicaciones tendrá mejor telemetría y podrá mejorar sus aplicaciones. Como arquitecto empresarial, No me importa nada de lo que esté dentro del espacio de decisión del implementador. Solo me importan el valor, los beneficios y las restricciones. la arquitectura impuesto al proyecto.
Todos conocemos la historia cuando algo sale mal. El equipo de implementación llega a la reunión de actualización con cara de tristeza. Nos dirán que una de estas cuatro cosas ha fallado.
- El proyecto solo puede ofrecer un cañón intransitable más estrecho: el beneficio se desploma.
- El proyecto necesita realizar trabajo adicional para cerrar la brecha: aumento de costos
- Una limitación arquitectónica está impidiendo el éxito: colapso de los beneficios ajenos al proyecto o aumento de los costos ajenos al proyecto.
- No lograron cumplir con una restricción arquitectónica: colapso de beneficios ajenos al proyecto o aumento de costos ajenos al proyecto.
Si tienes una debilidad arquitectura de cartera y gobernanza de la implementación, puedes esperar que los equipos de implementación disfracen la entrega de un cañón infranqueable más estrecho como una victoria. Destacarán que están reduciendo riesgos, cumpliendo con el cronograma e incluso ahorrando dinero. Desde un arquitectura de cartera Desde su perspectiva, están explicando por qué el proyecto no debería haber sido financiado y que están robando los fondos de la cartera.
En lista de verificación de gobernanza de implementación Las preguntas 2 a 7 tratan sobre cómo crear una recomendación de cumplimiento de arquitectura para las partes interesadas. El proyecto Elastic se financió para que SRE/Operaciones gestionaran un mejor entorno de aplicaciones/infraestructura y para que el desarrollo de aplicaciones mejorara la cartera de aplicaciones mediante telemetría.
Tienes tres opciones reales:
- Siga adelante con el trabajo adicional para reclamar el beneficio esperado. menor valor
- Reduzca las expectativas y relaje una restricción que reduzca el beneficio del proyecto o de la empresa. menor valor
- Concluir que el cálculo de beneficio/costo siempre será negativo y acabar con la iniciativa
Probar la recomendación
En lista de verificación de gobernanza de implementación Las preguntas 2 a 6 son simplemente pruebas para verificar si usted realizó su trabajo. La lista de verificación pregunta:
- Si las PYME están de acuerdo con los hechos y su interpretación (pregunta 2)
- Si las PYME están de acuerdo con su recomendación (pregunta 3)
- Si su análisis arquitectónico respalda su conclusión y recomendación (pregunta 4)
- Si existen cuestiones especiales que generen incertidumbre y que su parte interesada deba conocer (pregunta 5)
- Si sus partes interesadas comprenden el impacto que este problema tendrá en el valor esperado de la arquitectura (pregunta 6)
Lo sé, son preguntas difíciles sobre gobernanza. Todas las que se le hacen a la arquitecto empresarial, sobre el arquitectura.
Todo porque la pregunta 1 hizo añicos la aprobación del objetivo por parte de las partes interesadas.
Volvamos al principio Guía para profesionales Tabla 4: aprobado por las partes interesadas. interferir con una organización que, de otro modo, sería exitosa para obtener algo más. A cambio de ese beneficio, estaban dispuestos a trabajar y asumir riesgos. Los cálculos mostraron un valor suficiente tras ajustar por riesgo.
La pregunta 1 es muy abierta. Pregunta si están siguiendo la arquitectura. Esa pregunta es importante. Estará ligada a todo. inquietud Cada parte interesada tenía. Incluirá:
- ¿Están ofreciendo los beneficios esperados?
- ¿Están dentro del esfuerzo previsto?
- ¿Es sostenible su implementación?
- ¿Cumplieron con todas las restricciones?
Cada vez que nuestros implementadores no interpretan correctamente la arquitectura, es un día triste. No importa el motivo, el resultado es el mismo. Nuestros clientes no recibirán lo que acordaron pagar.
Por eso la arquitecto empresarial Tiene que volver a intervenir y presentar una recomendación al interesado sobre su objetivo. No se trata de una discusión con los implementadores sobre las opciones de implementación. No se trata de una negociación con el jefe de proyecto sobre el alcance. Se trata de una recomendación al interesado insatisfecho.
Odio estas recomendaciones. Odio tener que admitir ante mí mismo que ni siquiera mis implementadores podría hacer realidad mis ideas. Si mis implementadores Al no poder concretar la idea, me enfrento a la incómoda realidad de que mi análisis fue erróneo. Que asesoré mal a mi interlocutor.
Esta situación es muy diferente a cuando mi parte interesada No sigue mi recomendación. Entonces debo concluir que no comprendí las limitaciones, la tolerancia al riesgo ni las prioridades de las partes interesadas.
Cuando mi implementador Si no cumple con lo prometido, o bien fallé en la comunicación, o mi análisis no cumplió con mis estándares.
Integridad final del contrato no roto
Aquí mismo estamos en el centro de arquitectura empresarial de mejores prácticas. Por qué existe la profesión. Por qué existen sistemas complejos como el Marco TOGAF Existen. Por qué los usamos modelos formales. ¿Por qué trabajamos duro para construir? hojas de ruta de arquitectura. Por qué nos esforzamos tanto en reducir los riesgos de las iniciativas de cambio.
Arquitectura empresarial Es difícil. Es complejo. Guiar el cambio tiene un impacto real en nuestra organización.
Cada vez que debo elaborar una recomendación de incumplimiento, estamos en un aprieto. El proyecto de implementación ha consumido mucho dinero y sigue consumiendo más. El tiempo está mermando la contribución de valor esperada. Estoy bajo presión.
Por eso TOGAF Fase G estrés arquitecto empresarial compromiso. Por qué redactamos un contrato de arquitectura en términos que los implementadores puedan seguir. Realizamos gobernanza de la implementación Realizar revisiones tempranas con el objetivo de detectar problemas a tiempo.
Cada captura temprana es más barata que una captura tardía. La captura temprana es una constante en TOGAF. Fase A ¿Pruebas para determinar si una idea puede superar unos obstáculos mínimos? Fase E hoja de ruta dinámica Está repleto de VRP que proporcionan pasos de parada y pivote para reducir el riesgo. Fase G nos guía a revisar en las fases de inicio, diseño y principales. Como último recurso, en puesta en marcha.
Siempre que detectamos el déficit, nuestra acción es siempre la misma. Una recomendación sobre qué hacer: redoblar la apuesta y gastar más, aceptar un beneficio menor o desechar el trabajo. Desechar en Fase A está limpiando la pizarra blanca. Fase G Estamos desechando cosas que acabamos de comprar. Cosas que esperábamos que mejoraran las cosas. Cosas que todos secretamente esperamos que aún puedan mejorarlas.
Aquí está mi desafío de esta semana. Mira la guía en tu arquitectura. ¿Qué estás haciendo para ayudar? sus implementadores¿Están claras las reglas del juego: cómo ganar y qué está prohibido?
Ve más allá, ¿puedes rastrear el valor de tu? especificaciones de arquitectura ¿Están aplicando? Cuando definió un patrón, ¿incluyó el parte difícil en Plantilla de patrón de navegación ¿Para habilitar el cálculo del valor?
La semana que viene nos trasladaremos a la arquitectura empresarial dominio. Dado el arquitectura de sistemas de información debe habilitar el arquitectura empresarial, Necesitamos conocerla. Nuestra arquitectura empresarial tiene múltiples usos. Primero, explica los contornos del contexto empresarial. Segundo, muestra dónde y cómo mi organización genera valor. Por último, me indica los límites del cambio. Modelos de capacidad Tienen un papel especial en los límites y las necesidades del cambio. Creo que será una serie divertida.
¡Que tengas una excelente semana!
Como siempre, agradezco sus comentarios y preguntas.
Saludos,
Dave
Dave Hornford
Conexiam