Comprensión del desarrollo ágil y EA

La arquitectura ágil y empresarial encajan maravillosamente. Ambos resuelven diferentes partes del problema.

El desarrollo de software ágil sobresale en la construcción de algo que nunca antes habíamos tenido y no sabemos cómo. La arquitectura empresarial sobresale ante las decisiones cuando no sabe qué hacer.

La agilidad, la arquitectura empresarial y el desarrollo de software encajan en tres áreas

  1. diseñar una empresa ágil
  2. prácticas de trabajo ágiles para desarrollar una arquitectura empresarial de mejores prácticas
  3. desarrollo de software ágil y arquitectura empresarial

La mayoría de los arquitectos saltan al último. Intentan unir dos mundos tremendamente divergentes, generalmente sin detenerse a comprender ninguno de los dos.

Tuve una conversación divertida con el ingeniero de confiabilidad de sistemas recién contratado. El especialista en SRE estaba emocionado. Finalmente iniciamos prácticas modernas prácticas de CI / CD. Me preguntó qué estaba haciendo el equipo de EA para ayudar.

Tuve que sonreír cuando ella preguntó '¿Qué está haciendo EA Team para ayudar?? ' Lo que realmente quiso decir fue 'que haces para apoyarme hoy? ' Hoy, frente a sus desafíos inmediatos, podría ser: nada. Ella saltó a cómo el equipo de EA apoyaba su trabajo diario.

Nunca vio la hoja de ruta de la cartera que incluía contenedores, gestión de datos de prueba y, francamente, un conjunto de pruebas automatizadas ridículamente insuficiente. No se dio cuenta de que la misma vieja hoja de ruta identificaba un punto de transición que financió su trabajo.

Los equipos de EA exitosos cumplen su propósito. No cumplen con nada más. Incluso si pudieran.

Seis casos de uso cubren todos los aspectos de la arquitectura ágil y empresarial

Un marco simple para pensar en la arquitectura empresarial es preguntar ¿qué admiten?

  1. estrategia de apoyo
  2. cartera de soporte
  3. proyecto de apoyo
  4. Soporte de entrega de soluciones

https://conexiam.com/togaf-9-2-body-of-knowledge/

Desarrollo ágil y arquitectura empresarial

Cuando se vincula al desarrollo de software ágil, se hace la misma pregunta, ¿qué debería ayudar a responder el equipo? Parte de la alineación está impulsada por lo que el equipo de arquitectura empresarial está diseñado para respaldar.

  1. definiendo el enfoque ágil
  2. guiar la acumulación en sprint
  3. restringir los sprints
  4. resolver la dependencia entre productos
Producto de trabajo de arquitectura ágil y empresarial

Arquitectura ágil y empresarial: defina el enfoque ágil

Por lo general, un equipo de EA que está al servicio de la estrategia y la cartera definir el enfoque ágil.

Producto

Los productos aparecen en una hoja de ruta como brechas o paquetes de trabajo. El equipo de EA puede hablar sobre capacidad o servicio comercial. Cuando lo hagan, espere ver los productos nuevos o reelaborados.

Plataformas

Producto de trabajo de desarrollo ágil compatible con EA¿Qué apoyará u operará el producto? Saber si el producto es independiente, basado en una nueva plataforma, utilizando una plataforma existente o apalancamiento en plataformas de terceros, definirá los elementos clave de su enfoque ágil, generalmente mucho antes del sprint-zero.

Los profesionales más débiles se fijarán en la definición de términos como "Plataforma". Una definición nítida y demasiado precisa es una trampa. Considere unos segundos, es perfectamente razonable que alguien hable de SAP, 0365, Facebook, Pega o incluso Angular y Containers como plataformas. El término necesita un contexto para una definición estrecha. Todo lo que necesita es que el consumidor y el operador estén de acuerdo. He sucumbido a la tentación de especificar un producto que era una plataforma consumida por otros. Los pedantes intentaron determinar si era producto o plataforma.

Estrategia de prestación de servicios

Es mejor que las hojas de ruta de nivel superior sean claras sobre cómo implementar la transformación. Ejemplos incluyen.

  • ¿Desarrollar una capacidad interna sólida o utilizar a terceros?
  • ¿Garantizar sistemas sostenibles de larga duración o tratar algunos o todos los productos como pañuelos desechables?

Puntos de descanso de mayor valor

Usamos habitualmente Value Resting Points como sinónimo de transiciones arquitectónicas. Siempre proporcione a sus partes interesadas una rampa de salida. Usamos rampas de salida por dos razones:

  1. Cuando el esfuerzo por alcanzar el siguiente punto de reposo supera el valor incremental.
    Esta es una conversación sobre ROI. Las conversaciones sobre el retorno de la inversión suelen dar lugar a un cambio de prioridad.
  2. Cuando el esfuerzo por llegar a un punto de descanso podría llegar a un descanso más emocionante o gratificante.

Las conversaciones de compensación proporcionan uno de los resultados más valiosos de una estrategia o ejercicio de hoja de ruta de cartera. Los recursos son finitos. Los líderes senior siempre están buscando el mejor camino a seguir, no el retorno potencial más alto. El mejor camino. Las consideraciones incluyen el valor comparativo en reposo y el valor potencial como trampolín para otras actividades.

Los implementadores rara vez entienden estas conversaciones. Se vuelven emocionalmente investidos en un camino o punto de descanso. Especialmente cuando se está considerando la existencia del producto o el próximo lanzamiento.

Arquitectura Agile y Empresarial: Guía de Backlog en Sprint

Los profesionales de EA que apoyan la cartera y el proyecto a menudo se relacionarán con equipos ágiles al guiar la acumulación en Sprint.

He observado que sorprende a demasiados evangelistas ágiles que las organizaciones profundamente comprometidas con los beneficios del desarrollo ágil de software sigan profundamente comprometidas con la planificación y la elaboración de presupuestos a largo plazo. Por lo general, la conversación confunde una preferencia cultural mítica por una cascada.

En lugar de eso, piensa en el problema. La planificación y el presupuesto a más largo plazo existen debido a la complejidad del ecosistema. Cada organización tiene múltiples caminos a seguir y diferentes limitaciones. Las organizaciones exitosas realizan priorización y compensación. Sin llegar al futuro preferido en las limitaciones de tiempo y recursos, no debería comenzar ningún trabajo.

Producto de trabajo de arquitectura ágil y empresarial

La arquitectura empresarial se reduce a las limitaciones. Cada restricción limita la creatividad de un equipo de desarrollo de software ágil. Sin una necesidad imperiosa de restricción, no lo haga. Simplemente no lo hagas.

Hoja de ruta para guiar el producto

La hoja de ruta para guiar el producto es uno de los entregables más difíciles para un equipo de EA talentoso. La tensión fundamental de saber a dónde vas sin saber cómo llegar es un punto caliente.

Demasiados equipos de arquitectura caen en la trampa de la precisión artificial o la omnisciencia imaginada. Ambas son formas elegantes de decir pensamiento en cascada.

El desarrollo ágil ofrece resultados sorprendentes cuando el equipo tiene todos los grados de libertad. Solo piense en el punto óptimo de un producto independiente totalmente nuevo.

A menudo, una buena arquitectura se reduce a proporcionar las restricciones mínimas para garantizar que las decisiones no fallen en una prueba que no es evidente para quien toma las decisiones. Si la persona que toma las decisiones puede ver la prueba, no necesita una arquitectura para restringirlos. La arquitectura existe para guiar o restringir la elección cuando el factor está fuera del campo de visión de los arquitectos.

Una hoja de ruta clásica de EA hablará sobre transiciones, brechas y paquetes de trabajo. Será incomprensible para un equipo de producto. Haga la transición de la hoja de ruta a los términos correctos con el propietario del producto. El propietario del producto debe comprender las limitaciones dentro de las que opera.

Espere tensión

Hoja de ruta para guiar épica

La hoja de ruta para guiar a Epic es el resultado más difícil para un equipo de EA talentoso. Siempre pienso en quedar atrapado en un campo minado durante un bombardeo. No hay ningún lugar seguro al que ir.

Las expectativas de la línea de tiempo empeoran la trampa común del pensamiento en cascada. Saltar por delante del viaje de descubrimiento de un equipo ágil con precisión artificial y omnisciencia imaginada socava todo en el desarrollo ágil. ¡No lo hagas!

Sin productos estrechamente integrados o restringidos, las hojas de ruta de la épica están condenadas al fracaso. Los ejemplos, cuando sea necesario, incluyen múltiples productos que coexisten dentro de un ecosistema y comparten datos de referencia. Consumir el agotamiento de datos de los demás a menudo requerirá epopeyas asociadas o una regulación punitiva compleja.

Sin presión externa, no realice esta actividad. La sobreespecificación y el sobre diseño por parte de practicantes omniscientes autodenominados es algo que inventamos ágilmente para prescindir. Si se ve obligado a seguir una hoja de ruta hacia épicas, asegúrese de comprender exactamente por qué es necesario limitar la creatividad de los desarrolladores de software. Cada restricción que restringe su libertad y creatividad debe servir mejor para anular la entrega de valor que proviene de la creatividad desenfrenada.

Espere el fracaso.

Cuando logramos que esto tenga éxito, adoptamos activamente el lenguaje de métodos como SaFE y enmarcamos la hoja de ruta en términos de temas estratégicos y pistas de arquitectura.

Valor de la empresa

La arquitectura superior siempre abordará las preocupaciones comunes de las partes interesadas. Debe proporcionar un conjunto de principios internamente coherente que proporcionen restricciones a la definición de valor. En este caso, la arquitectura garantiza que el descuido en la evaluación del valor no genere costos posteriores.

La evaluación descuidada del valor es el problema más común que aborda la buena arquitectura. Rigen las consideraciones transitorias. Una dicotomía clásica es la distinción entre tiempo táctico de comercialización y seguridad, resistencia o estabilidad. Cuando su organización tiene imperativos, los gerentes de producto y los equipos de scrum deben ser informados. De lo contrario, no pueden evaluar adecuadamente el retraso en comparación con las métricas que realmente importan.

Restringir a los propietarios de productos 'de abajo hacia arriba'

Demasiados propietarios de productos no tienen visibilidad de por qué existe su producto o Demasiados propietarios de productos no tienen visibilidad de por qué existe su producto o cuál es la función del ecosistema. Restrinja la libertad de un propietario de producto de abajo hacia arriba, ya sea prohibiendo la elección o imponiendo la puntuación y la evaluación.

Arquitectura ágil y empresarial: restringir los sprints

Los profesionales de EA que desarrollan arquitectura para respaldar la entrega de proyectos y soluciones deben esperar restringir los sprints. Los profesionales orientados a la cartera que están desarrollando un ecosistema o plataforma también deberían esperar trabajar con los equipos ágiles aquí.

Limitar los sprints puede ser emocionalmente difícil para los nuevos arquitectos que solían participar activamente en el desarrollo. Es difícil dejar atrás su antiguo trabajo. A menudo, la experiencia en la materia lleva a sobreespecificaciones y sobre diseños. Cada restricción que restringe su libertad y creatividad debe demostrar que anula la entrega de valor que proviene de la creatividad desenfrenada.

La dificultad de dejar su antiguo trabajo es la razón por la que tratamos a todos los nuevos en la arquitectura empresarial como nuevob. El recién graduado y la persona con 30 años de experiencia haciendo algo más que arquitectura empresarial son nuevos arquitectos.

Veo nuevos arquitectos con años de otro experiencia más cercana. Tienen muchos malos hábitos que les impiden ser arquitectos de alto rendimiento.

Producto de trabajo de arquitectura ágil y empresarial

Nathan y Sam hablando de desarrollando nuevos arquitectos empresariales. Es muy importante que todos arquitectos empresariales comprender los derechos de decisión y servir a las partes interesadas.

Criterios de aceptación

Un vínculo muy simple en un sprint son los criterios de aceptación definidos externamente. Si la arquitectura requiere algo, enmarquelo como criterio de aceptación. A menos que el nivel de detalle esté muy cerca de interferir en la creatividad ágil, la restricción será algo consistente. Habrá una demanda de la arquitectura empresarial, la arquitectura de la aplicación de la arquitectura de datos o la arquitectura de la infraestructura. La especificación de la arquitectura será un principio, patrón o estándar. Proporcione la restricción como criterio de aceptación. Alinéese con un Sprint o suéltelo. Entonces sal del camino y observa la creatividad.

Guía del gobernador

¿Interpretaron razonablemente la guía y la restricción de la arquitectura de destino?

  • En caso afirmativo, su interpretación debe aceptarse como cumplimiento. Este es un punto clave. Una buena arquitectura puede tener múltiples opciones de implementación. El implementador no está obligado a adherirse a la opinión. Si la opción de implementación es una interpretación razonable, se cumple.

Valor (medidas y puntos de reposo)

Un punto recurrente de conflicto es la comprensión del valor.

El desarrollo de software ágil de mejores prácticas se centra en el valor. Desafortunadamente, la mayoría de los profesionales tienen una comprensión limitada del valor. La taquigrafía rápida es que el valor se expresa en términos de algo que se entregó. El valor es evidente en la entrega.

En un mundo complejo, lo que se entrega fácilmente podría tener un valor degradante. Un ejemplo sencillo son las funciones dirigidas lejos de los clientes objetivo o el movimiento de trabajo entre unidades de trabajo. Esto es común cuando el producto sirve a un grupo. Recomendamos encarecidamente aprender las prácticas básicas de Lean y Six-Sigma sobre optimización y valor local. Además, los conceptos de Business Model Canvas de Target Customer y Value Proposition son útiles.

Para abordar estos desafíos, esperamos que la arquitectura empresarial sea definitiva sobre cómo se evalúa el valor. La arquitectura debe proporcionar criterios de evaluación de valor a los equipos de desarrollo.

Greenfield, evolución o revolución

En la Fase E de TOGAF hay un paso genial. Mire el paquete de trabajo y seleccione una estrategia adecuada.

¿El trabajo será nuevo, evolutivo o revolucionario? ¿Queremos conservar todo lo posible, refactorizar radicalmente o empezar de cero? Esta es una guía crítica y una fuerte limitación para un equipo ágil. ¿Deben empezar de cero (Greenfield)? ¿Mejorar los sistemas existentes de forma incremental (evolución)? ¿O realizar un cambio radical en lo esperado para eliminar la fricción y las molestias con las que hemos estado viviendo (revolucionario)?

Es posible que la elección de enfoque no sea la de ellos. Cuando no tienen la opción, siempre será impulsado por opciones por encima de su nivel de pago.

Restringir interfaces

Cuando un producto debe encajar en un entorno empresarial existente o admitir un entorno empresarial en evolución, las interfaces son clave. Las interfaces se regirán por los datos y el método. Incluso cuando el producto está emergiendo, en un mundo complejo, no habrá libertad para permitir que también surjan la estructura o la interfaz de datos. Los datos maestros, los datos de referencia y los sistemas existentes limitarán el desarrollo ágil.

Los sistemas existentes no se van a cambiar. Incluso el F-22 Raptor tuvo que conectarse con sistemas heredados utilizando interfaces desarrolladas en la década de 1970. Incluso un avión tan caro no podría remodelar los sistemas heredados. El Raptor encaja dentro de la interfaz y la estructura de datos existentes.

Una restricción común que los equipos en rápido movimiento pasan por alto es cómo la legislación multijurisdiccional o un plan de negocios impactarán en el producto. En estos casos, el equipo de EA tiene el deber de profundizar y desarrollar las restricciones mínimas necesarias para evitar que el producto requiera una refactorización radical en un momento inconveniente. Como todas las limitaciones a la creatividad, los buenos profesionales de EA comprenden la importancia de lo suficiente.

Arquitectura empresarial y ágil: resuelva la dependencia

Se puede esperar que los profesionales de EA que trabajan en una empresa deban intervenir y resolver la dependencia y el conflicto que surgen entre las soluciones de productos y los sistemas. Simplemente mire la fase G de TOGAF, destaca la necesidad de orientación y cambio de arquitectura. El desarrollo ágil y el alcance de la integración moderna hacen que este servicio de necesidad de larga duración sea más importante que nunca.

Producto de trabajo de arquitectura ágil y empresarial

Desbloquea la cartera

Incluso si no está limitado por el legado, habrá varios productos en el futuro. Los equipos de desarrollo ágil de mejores prácticas creativas encontrarán diferentes formas de abordar los problemas. Es una tontería esperar que la creatividad no cree conflictos. Se puede esperar que un buen equipo de EA que trabaje en la Fase G, donde ocurre todo el desarrollo de software ágil, desbloquee el conflicto en toda la cartera de empresas.

Identificar a las partes interesadas reales

Las partes interesadas reales a menudo son difíciles de encontrar. Se delegan muchas decisiones tácticas. Cuando la delegación es formal, el equipo ágil puede esperar tener un acceso razonable. Cuando la delegación es informal, se puede esperar que los usuarios y los expertos en la materia locales impulsen una agenda no alineada.

El equipo de arquitectura empresarial no tiene una capacidad especial para ganar participación. Tienen la capacidad de representar las preocupaciones de las partes interesadas a través de una arquitectura superior.

Cruzar la cartera

Los propietarios de productos y otros miembros de un equipo de desarrollo están motivados a entregar un producto de forma incremental. El producto mínimo viable y la entrega incremental son el núcleo de la propuesta de valor ágil.

Todo el enfoque ágil proviene del fracaso observado de intentar imaginar cada interacción en una cartera compleja, este es el camino del fracaso. El diseño empresarial detallado de arriba hacia abajo puede funcionar para sistemas aislados. Dentro de un ecosistema que está cambiando, el diseño de arriba hacia abajo siempre falla. Ese camino de falla es la razón por la que existe ágil y por qué se prefiere ágil.

Es casi imposible imaginar un futuro complejo, los esfuerzos para hacerlo a menudo se convierten en una farsa. Sin embargo, debemos hacer lo suficiente. A medida que surgen múltiples productos, surgirán nuevos conflictos y sinergias. Un buen equipo de EA, con un amplio conocimiento de los cambios en las prioridades de su empresa, ayudará a abordar las sinergias y los conflictos.

Cuando el equipo de EA descubre intersecciones, debe utilizar su conocimiento y participación para obtener la mejor respuesta. A menudo, este será un enfoque de gestión de riesgos. Evaluar rápidamente el conflicto para determinar si la resolución puede aplazarse es el primer paso. Aprovechar la sinergia y evitar los conflictos es costoso. Costoso y lento. Interfieren directamente con el tiempo de comercialización.

Hablamos en términos de fuerzas del mercado y destrucción creativa cuando debemos cruzar la cartera.

Impacto de liberación

Una arquitectura suficiente significa que cada contingencia, cada restricción, cada conflicto, no fue descubierto antes del lanzamiento.

Hay un caso en el que un equipo de arquitectura tiene una emergencia. Es una crisis posterior al lanzamiento. Esos raros casos en los que las implicaciones se extienden más allá del producto. El producto está en estado salvaje. Los usuarios finales dentro y fuera de nuestra organización lo están utilizando. O están lidiando con un defecto o, lo que es peor, creando riesgos y responsabilidades imprevistos para nuestra organización.

Conclusión de la arquitectura ágil y empresarial

Tanto el desarrollo ágil como la arquitectura empresarial sufren una mala aplicación crónica. Demasiado a menudo al mismo tiempo.

Seis casos de uso cubren todos los aspectos de la arquitectura ágil y empresarial. La arquitectura empresarial guía y limita el desarrollo ágil de software.

Al vincularse al desarrollo de software ágil, los arquitectos empresariales deben:

  1. definiendo el enfoque ágil
  2. guiar la acumulación en sprint
  3. restringir los sprints
  4. resolver la dependencia entre productos

La arquitectura empresarial se reduce a los límites: haga esto, no haga aquello. Cada límite restringe la creatividad de un equipo de desarrollo de software ágil. Sin una necesidad imperiosa de restricción, no lo haga. Simplemente no lo hagas.

https://conexiam.com/togaf-9-2-body-of-knowledge/

La Cuerpo de conocimientos de TOGAF apoya el desarrollo de un enfoque de gobernanza eficaz.

Únase al Kickstart de arquitectura empresarial personal

Programa gratuito de 12 semanas para ser un mejor arquitecto empresarial

Ir arriba