Seis casos de uso de arquitectura empresarial ágil

Ejemplos de casos de uso de Agile EA

Caso de uso 1: Arquitectura de una empresa ágil

En este caso de uso, el propósito de EA se limita a requerir arquitecturas de destino aceptables para priorizar la agilidad.

Francamente, no tiene nada que ver con ningún método ágil. Muchas organizaciones ágiles con las que hemos trabajado no utilizan métodos de cambio ágiles.

Nos basamos en gran medida en la Cadena de Suministro y la Respuesta ante Desastres como pilares de alta agilidad. Utilizamos cinco atributos para la agilidad (extraídos de investigaciones deportivas y militares):

• Vigilancia
• Accesibilidad
• Decisión
• Rapidez
• Flexibilidad

Este caso de uso ejercita Atlas empresarial ágil de Navigate de Conexiam. Optimiza el desarrollo de la arquitectura para la agilidad a través de una biblioteca de puntos de vista especializados, la participación de las partes interesadas y sus preocupaciones.

Dicho sin rodeos, este caso de uso es peligroso si no se alinea con las verdaderas preferencias de las partes interesadas poderosas de una organización.

En términos de TOGAF, Este caso de uso se centra principalmente en TOGAF ADM Actividad de realización de valor de las fases G y H, donde el cambio debe estar alineado con la creación y el sostenimiento de una empresa ágil.

Caso de uso 2: Utilizar EA para definir un enfoque ágil para el cambio

En este caso de uso, la arquitectura empresarial se utiliza para estructurar cómo la empresa implementa el cambio. Se analizan los productos, la estructura del equipo de sprint, la velocidad y la alineación con todos los enfoques de cambio.

Las preguntas que se abordan son qué cambio, qué desarrollo debe seguir y qué enfoque. En el caso de los métodos ágiles, se responden cuestiones como el producto, la estructura del equipo de sprint y la velocidad.

Este caso de uso consiste en gran medida en ejercitar la TOGAF ADM Fase F, G y H basadas en una arquitectura estratégica o de cartera.

Caso de uso 3: Utilizar EA para guiar la planificación del backlog y del sprint

Desde la perspectiva de la Arquitectura Empresarial y TOGAF, Toda la implementación, el prototipado, los pilotos, los proyectos y los sprints ágiles se llevan a cabo en la Fase G. La arquitectura empresarial basada en mejores prácticas generará una arquitectura empresarial completa con un cuaderno de entrega de soluciones, un plan de gestión de brechas, un control, una especificación de arquitectura y un paquete de trabajo. Este material debe describirse en términos adecuados para el backlog: Épica, Historia de Usuario y Pista de Arquitectura.

La arquitectura empresarial contendrá un conjunto de deficiencias, paquetes de trabajo para subsanarlas y limitaciones en la creatividad de los equipos de implementación para implementar el cambio. Incluirá trazabilidad a factores clave, objetivos y prioridades fuera del alcance del gerente de producto y del cliente.

En la metodología ágil clásica, las épicas y las historias de usuario impulsadas por el cliente conforman el backlog. El cliente proporciona criterios de priorización. El equipo ágil autoorganizado prioriza el trabajo.

Este caso de uso utiliza la arquitectura empresarial para proporcionar un backlog no basado en el cliente y guiar la priorización en la planificación de sprints.

En este caso, se utilizan épicas de brechas e historias de usuario derivadas de brechas y paquetes de trabajo. La dependencia externa limita la priorización, los criterios de aceptación y los criterios de salida. Se pueden establecer prioridades generales.

Este caso de uso ejercita principalmente la TOGAF ADM Fase G, Gobernanza de la Implementación: En términos sencillos, durante la Fase G, se informa al equipo de implementación sobre el trabajo que debe realizar y las limitaciones externas que limitan su libertad para realizarlo. La comunicación del equipo de EA depende de la organización del equipo de implementación.

El elemento crítico es alinear la actividad de gobernanza de EA con el modelo de cambio ágil. No se debe afectar el impulso del equipo de sprint.

Caso de uso 4: Utilizar EA para limitar los sprints ágiles

Este caso de uso ejercita en gran medida la Fase G del TOGAF ADM, Gobernanza de Implementación.

Siguiente Mejores prácticas de gobernanza de la arquitectura empresarial La pregunta esencial es:

¿El equipo ágil interpretó razonablemente las directrices y restricciones documentadas de la arquitectura de destino?

• • En caso afirmativo, su interpretación debe aceptarse como cumplimiento y cualquier problema debe abordarse mediante un cambio en la arquitectura.
  • En caso negativo, desarrolle una recomendación para corregir la situación.

Este es un punto clave. Una buena arquitectura puede ofrecer múltiples opciones de implementación, y el equipo ágil no está obligado a adherirse a una sola opinión. Si la opción de implementación es una interpretación razonable, debe considerarse conforme. Si se omitió algo en la especificación de la arquitectura, no es problema del equipo ágil. Es problema del equipo de arquitectura ágil, que necesita un cambio en la arquitectura aprobada.

El elemento crítico es la alineación gobernanza de la arquitectura empresarial Actividad con modelo de cambio ágil. No se debe afectar el impulso del equipo de sprint.

Las Brechas, la Estrategia del Paquete de Trabajo, los Controles y la Especificación de la Arquitectura guían y limitan los sprints. Deben redactarse y presentarse de forma que el equipo ágil pueda comprenderlas. Los Controles y las Especificaciones de la Arquitectura suelen presentarse como criterios de aceptación y de salida.

Caso de uso 5: Utilizar EA para resolver la dependencia

En este caso de uso, la arquitectura empresarial se utiliza para abordar la dependencia y el impacto en los equipos ágiles.

Este caso de uso se diferencia del Caso de Uso 4 porque cambia la forma en que el equipo de EA interactúa. A menudo, cuando existe dependencia, se da entre diferentes métodos de cambio (ágil y cascada) y las decisiones tomadas durante un sprint pueden tener efectos en cascada.

Un papel clave del desarrollo Arquitectura para respaldar la entrega de soluciones Se trata de identificar y abordar estas dependencias antes de que un equipo ágil tropiece con ellas.

En el caso de uso 4, una medida de éxito consiste en garantizar que el impulso no se vea afectado. En este caso, el impulso de un equipo debe equilibrarse con el de otros equipos ágiles, unidades operativas y equipos que utilizan otros métodos de cambio.

Este caso de uso ejercita en gran medida la actividad de gobernanza y orden de cambio de la Fase G de TOGAF ADM. Francamente, Mejores prácticas de gobernanza de la arquitectura empresarial Evita la concesión de exenciones a la dependencia arquitectónica entre equipos. Los desafíos no identificados constituyen el área más común de exenciones arquitectónicas.

Los problemas de dependencia son responsabilidad del equipo de EA. Deberán trabajar para que la organización supere estos obstáculos de la forma más eficaz. Abordarlos requiere una atención minuciosa a la arquitectura superior, los controles y las especificaciones de arquitectura expresadas en los Principios.

Caso de uso 6: Utilizar métodos ágiles para desarrollar la arquitectura empresarial

En este caso de uso, la capacidad EA está configurada para utilizar métodos ágiles para desarrollar una arquitectura empresarial.

Conexiam Predictable EA Es un ejemplo de este caso de uso. Para comprender que una arquitectura se utiliza para respaldar la toma de decisiones, solemos denominar al producto de trabajo útil "Carpeta de Asesoramiento". Esta carpeta está optimizada para el propósito y el problema. Se utilizará de diversas maneras.

Este caso de uso tendrá un gran impacto en la ejecución de todas las fases de ADM para el desarrollo de la arquitectura. Depende del resultado de la fase preliminar y de la estructura y ejecución de la capacidad de EA.