Comprender el desarrollo ágil y la arquitectura empresarial
Agile y Enterprise Architecture encajan maravillosamente. Ambos resuelven diferentes partes del problema.
El desarrollo ágil de software 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 sabes qué hacer.
- diseñar una empresa ágil
- prácticas de trabajo ágiles para desarrollar una arquitectura empresarial de mejores prácticas
- desarrollo de software ágil y arquitectura empresarial
La mayoría de los arquitectos saltan al último. Intentan encajar dos mundos tremendamente divergentes, por lo general 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 de la SRE estaba emocionado. Finalmente comenzamos prácticas modernas prácticas de CI/CD. Me preguntó qué estaba haciendo el equipo de EA para ayudar.
Tuve que sonreír cuando me preguntó: "¿Qué está haciendo el equipo de EA para ayudar?' Lo que realmente quiso decir fue, '¿Qué estás haciendo para apoyarme hoy??' Hoy, frente a sus desafíos inmediatos, podría ser: nada. Saltó a cómo el equipo de EA apoyaba su trabajo diario.
Nunca vio la hoja de ruta de la cartera que trajo contenedores, gestión de datos de prueba y, francamente, un conjunto de pruebas automatizado ridículamente insuficiente. No se dio cuenta de que la misma vieja hoja de ruta identificaba un punto de transición que financiaba su trabajo.
Equipos de EA exitosos entregar en 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.
- estrategia de apoyo
- cartera de apoyo
- proyecto de apoyo
- Entrega de soluciones de soporte
Desarrollo ágil y arquitectura empresarial
Cuando se vincula con el desarrollo de software ágil, se hace la misma pregunta, qué debe ayudar el equipo a responder. Parte de la alineación está impulsada por lo que el equipo de arquitectura empresarial está diseñado para soportar.
- definir el enfoque ágil
- guiando el backlog en sprint
- limitando los sprints
- resolviendo la dependencia de productos cruzados
Arquitectura ágil y empresarial: defina el enfoque ágil
Por lo general, un equipo de EA que se ocupa 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 modificados.
Plataformas
Los practicantes más débiles se fijarán en definir 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 trataron de determinar si era producto o plataforma.
estrategia de prestación de servicios
Es mejor que las hojas de ruta de alto nivel sean claras sobre cómo implementar la transformación. Ejemplos incluyen.
- ¿Construir una capacidad interna robusta o utilizar a terceros?
- ¿Garantizar sistemas sostenibles duraderos o tratar algunos o todos los productos como Kleenex desechables?
Puntos de descanso de mayor valor
Rutinariamente usamos Value Resting Points como sinónimo de transiciones de arquitectura. Proporcione siempre a sus partes interesadas una rampa de salida. Usamos rampas de salida por dos razones:
- Cuando el esfuerzo para llegar al siguiente punto de descanso supera el valor incremental.
Esta es una conversación de ROI. Las conversaciones sobre el ROI generalmente conducen a un cambio en la prioridad. - Cuando el esfuerzo por llegar a un punto de descanso puede llegar a un descanso más emocionante o gratificante.
Las conversaciones de compensación brindan uno de los resultados más valiosos de un ejercicio de hoja de ruta de estrategia o cartera. Los recursos son finitos. Los líderes sénior siempre buscan el mejor camino a seguir, no el rendimiento potencial más alto. El mejor camino. Las consideraciones incluyen el valor comparativo en reposo y el valor potencial como trampolín para otra actividad.
Los implementadores rara vez entienden estas conversaciones. Se invierten emocionalmente en un camino o punto de descanso. Especialmente cuando se está considerando la existencia del producto, o el próximo lanzamiento.
Arquitectura ágil y empresarial: guía de trabajo pendiente en Sprint
Los profesionales de EA que respaldan la cartera y el proyecto a menudo se involucrará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 estando profundamente comprometidas con la planificación y la elaboración de presupuestos a más 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 restricciones. Las organizaciones exitosas realizan priorización y compensación. Sin alcanzar el futuro deseado en las limitaciones de tiempo y recursos, ningún trabajo debería comenzar.
La arquitectura empresarial se reduce a restricciones. 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 completamente 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 el tomador de decisiones. Si el tomador de decisiones puede ver la prueba, no necesita 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á de 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 en las que opera.
esperar tensión
Hoja de ruta para guiar la épica
La hoja de ruta para guiar la épica es el resultado más difícil para un equipo de EA talentoso. Siempre pienso en estar atrapado en un campo minado durante un bombardeo. No hay ningún lugar seguro para ir.
Las expectativas de la línea de tiempo empeoran la trampa común del pensamiento en cascada. Adelantarse al viaje de descubrimiento de un equipo ágil con precisión artificial y omnisciencia imaginada socava todo en el desarrollo ágil. ¡Simplemente no lo hagas!
Sin productos estrechamente integrados o estrictamente restringidos, las hojas de ruta para la épica están condenadas al fracaso. Los ejemplos, cuando esto sea necesario, incluyen múltiples productos que coexisten dentro de un ecosistema y comparten datos de referencia. Consumir el agotamiento de los datos de los demás a menudo necesitará epopeyas asociadas o una regulación punitiva compleja.
Sin presión externa, no realice esta actividad. La especificación excesiva y el diseño excesivo por parte de practicantes omniscientes autodesignados son algo que inventamos ágil para prescindir. Si se ve obligado a hacer planes épicos, asegúrese de comprender exactamente por qué es necesario limitar la creatividad de los desarrolladores de software. Es mejor que cada restricción que restringe su libertad y creatividad sirva para anular la entrega de valor que proviene de la creatividad desenfrenada.
Espere el fracaso.
Cuando logramos que esto tuviera éxito, adoptamos activamente el lenguaje de métodos como SaFE y enmarcamos la hoja de ruta en términos de temas estratégicos y arquitectura de pasarelas.
Valor de la empresa
La arquitectura superior siempre abordará las preocupaciones comunes de las partes interesadas. Debe proporcionar un conjunto de principios internamente coherentes que restrinjan la definición del valor. Aquí la arquitectura se asegura de 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 una buena arquitectura. Regla de las consideraciones transitorias. Una dicotomía clásica es la distinción entre el tiempo táctico de comercialización y la seguridad, la resiliencia o la estabilidad. Cuando su organización tiene imperativos, los gerentes de producto y los equipos de scrum deben saberlo. De lo contrario, no pueden evaluar adecuadamente el trabajo pendiente contra las métricas que realmente importan.
Restringir propietarios de productos 'ascendentes'
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 el rol del ecosistema. Restringir 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: limitar los sprints
Los profesionales de EA que desarrollan una arquitectura para respaldar la entrega de proyectos y soluciones deben esperar limitar 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í.
Los sprints restrictivos pueden ser emocionalmente difíciles para los nuevos arquitectos que solían participar activamente en el desarrollo. Es difícil dejar atrás tu antiguo trabajo. A menudo, la experiencia en la materia conduce a una especificación excesiva y un diseño excesivos. 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 que son nuevos en la arquitectura empresarial como novato. El recién graduado y la persona con 30 años de experiencia haciendo algo diferente a la 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 funcionamiento.
Nathan y Sam hablando sobre desarrollo de 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, enmarcarlo 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 aplicaciones de arquitectura de datos o la arquitectura de infraestructura. La especificación de la arquitectura será un principio, un patrón o un estándar. Proporcione la restricción como criterio de aceptación. O se alinea con un Sprint o se libera. Entonces sal del camino y observa la creatividad.
¿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, es compatible.
Valor (medidas y puntos de descanso)
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 practicantes tienen una comprensión limitada del valor. La abreviatura 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, la cosa entregada fácilmente podría tener un valor degradante. Un ejemplo sencillo son las características que no están dirigidas a los clientes objetivo o el movimiento de trabajo entre unidades de trabajo. Esto es común cuando el producto sirve a un grupo. Recomendamos enfáticamente aprender 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 comercial 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 Fase E de TOGAF, hay un paso genial. Mire el paquete de trabajo y seleccione una estrategia apropiada.
¿Será la obra Greenfield, Evolutiva o Revolucionaria? ¿Queremos conservar todo lo posible, refactorizar radicalmente o empezar de cero? Esta es una guía crítica y una fuerte restricción para un equipo ágil. ¿Quieren 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)?
La elección de enfoque puede no ser suya. Cuando no tienen la opción, siempre será impulsado por opciones por encima de su nivel de pago.
Restricción de interfaces
Cuando un producto debe adaptarse a un entorno empresarial existente o admitir un entorno empresarial en evolución, las interfaces son clave. Las interfaces serán impulsadas por datos y métodos. Incluso cuando el producto está emergiendo, en un mundo complejo, no habrá libertad para permitir que emerja la estructura de datos o la interfaz. Los datos maestros, los datos de referencia y los sistemas existentes limitarán el desarrollo ágil.
Los sistemas existentes no van a ser cambiados. 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 pasan por alto los equipos que se mueven rápidamente es cómo la legislación multijurisdiccional, o un plan de negocios, afectará 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 restricciones a la creatividad, los buenos practicantes de EA entienden la importancia de lo suficiente.
Arquitectura empresarial y Agile: resuelva la dependencia
Podemos esperar que los profesionales de eA que trabajan en una empresa necesiten intervenir y resolver las dependencias y los conflictos que surgen entre los productos, las soluciones y los sistemas. Simplemente mire TOGAF Fase G, destaca la necesidad de orientación y cambio de arquitectura. El desarrollo ágil y la integración moderna hacen que este servicio de necesidad de larga duración sea más importante que nunca.
Desbloquear la cartera
Incluso si no está limitado por el legado, habrá múltiples 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 conflicto. 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 la cartera de empresas.
Identificar verdaderos interesados
Las partes interesadas reales a menudo son difíciles de encontrar. Muchas decisiones tácticas se delegan. 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 expertos locales en la materia y los usuarios impulsen una agenda no alineada.
El equipo de arquitectura empresarial no tiene una habilidad especial para ganar compromiso. 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 para entregar un producto de forma incremental. El producto viable mínimo y la entrega incremental se encuentran en el centro de la propuesta de valor ágil.
Todo el enfoque ágil proviene del fracaso observado al tratar de 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. Esa ruta de falla es la razón por la cual 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, tenemos que hacer lo suficiente. A medida que surjan múltiples productos, surgirán nuevos conflictos y sinergias. Un buen equipo de EA, con una gran comprensión de los cambios en las prioridades de su empresa, ayudará a abordar la sinergia y el conflicto.
Cuando el equipo de EA descubre intersecciones, necesita usar su conocimiento y compromiso 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 se puede aplazar es el primer paso. Aprovechar la sinergia y evitar el conflicto 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
La arquitectura suficiente significa que cada contingencia, cada restricción, cada conflicto, no se descubrió antes del lanzamiento.
Hay un caso en el que un equipo de arquitectura tiene una emergencia. Es la crisis post-lanzamiento. Esos casos raros 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. Están lidiando con un defecto, o peor aún, creando riesgos y responsabilidades imprevistos para nuestra organización.
Conclusión de la arquitectura ágil y empresarial
Tanto el desarrollo ágil como arquitectura empresarial sufren de mala aplicación crónica. Con demasiada frecuencia 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 con el desarrollo de software ágil, los arquitectos empresariales deben:
- definir el enfoque ágil
- guiando el backlog en sprint
- limitando los sprints
- resolviendo la dependencia de productos cruzados
La arquitectura empresarial se reduce a límites: haz esto, no hagas aquello. Cada límite restringe la creatividad de un equipo ágil de desarrollo de software. Sin una necesidad imperiosa de restricción, no lo haga. Simplemente no lo hagas.
El TOGAF Cuerpo de conocimiento apoya el desarrollo de un enfoque de gobernanza eficaz.
Únase al Kickstart de la arquitectura empresarial
Programa gratuito de 12 semanas para ser un mejor arquitecto empresarial