Comprender la arquitectura empresarial y la agilidad
¿Cómo encajan la arquitectura empresarial y la agilidad?
Arquitectura empresarial y ágil: definir el enfoque ágil
Arquitectura empresarial y ágil: trabajo pendiente de guía en Sprint
Arquitectura empresarial y ágil: limitar los sprints
¿Cómo encajan la arquitectura empresarial y la agilidad?
La arquitectura empresarial y la agilidad encajan de maneras inesperadas. El método ágil se centra en el ahora. Los pasos para crear un software de envío viable. Desde esta perspectiva, la pregunta es ¿qué hace hoy la arquitectura empresarial? ¿Qué hace para acelerar el envío del software?
La arquitectura empresarial y la agilidad no encajan dentro del sprint. Encajan fuera del ciclo de desarrollo. Se combinan gracias a los arquitectos empresariales y los desarrolladores ágiles que realizan su trabajo. Los equipos exitosos de EA cumplen con sus caso de uso. No cumplen con nada más. Incluso si pudieran.
Contamos con una arquitectura empresarial simple y un modelo de referencia ágil. Hay cuatro patrones básicos de participación en la arquitectura empresarial:
- definir el enfoque ágil
- guiando el backlog en sprint
- limitar los sprints ágiles
- resolviendo la dependencia de productos cruzados
Durante los últimos años trabajando en Transformación Digital iniciativas, desarrollamos un conjunto de patrones de participación.
¿Cómo utilizar estos patrones de participación?
Primero, observe su caso de uso de EA. ¿Qué orientación se espera que proporcione? ¿A quién sirves? Luego, observe los patrones de participación que abordan los desafíos de su trabajo. Tráelos a tu compromiso.
Nuestra plantilla de patrón de arquitectura tiene dos elementos clave: el problema predecible y el Acercarse a solucionar el problema. También reunimos el bits duros. Cuando consideramos un patrón, observamos qué tan bien resuelve el problema y cuánto trabajo adicional es necesario para aplicar el patrón con éxito.
Veamos los patrones de participación. El problema que resuelven, el enfoque y las partes difíciles.
- definir el enfoque ágil
- guiando el backlog en sprint
- limitar los sprints ágiles
- resolviendo la dependencia de productos cruzados
Ejemplo práctico: desarrollo ágil en la hoja de ruta de la arquitectura empresarial
Tuve una conversación divertida con el ingeniero de confiabilidad de sistemas recién contratado. El especialista de la SRE estaba emocionado. Finalmente iniciamos prácticas modernas: CI/CD y pruebas automatizadas. Me preguntó qué estaba haciendo el equipo de EA para ayudar.
Tuve que sonreír cuando ella preguntó: '¿Qué está haciendo el equipo de EA para ayudar?"Lo que realmente quiso decir fue: "¿Qué estás haciendo para apoyarme hoy?' Hoy, en términos de sus desafíos inmediatos, nada. Ella estaba dentro de la implementación. Ella estaba mirando en términos de implementación.
No entendía cómo se estaba desarrollando la organización. Ella no era consciente de la hoja de ruta de la cartera. La hoja de ruta tenía un punto de transición al que acabábamos de llegar. Habíamos incorporado contenedores, gestión de datos de prueba y un conjunto de pruebas automatizadas débil. No se dio cuenta de que la anticuada planificación vertical había creado las circunstancias para su nuevo trabajo.
Ella estaba pensando en el desarrollo inmediato. Yo estaba pensando en todo el proceso. transformación digitalSu función era ayudar a la organización en la siguiente transición. Estaba desarrollando el capacidades críticasLas pruebas automatizadas iban a proporcionar evidencia de que se estaban siguiendo las restricciones de la arquitectura. Estaba pasando de definir el enfoque ágil. necesitaba ayuda para guiar el trabajo atrasado.
Diez puentes y carreteras de conexión valen más que 500 medios puentes hacia ninguna parte
490 constructores de puentes estarán descontentos
490 constructores de puentes que pensaron que estaban aportando valor
Descargar Guía de inteligencia artificial para líderes empresariales
Descargar Guía para líderes empresariales sobre inteligencia artificial Las organizaciones que aplican con éxito tecnología innovadora han tenido una ventaja competitiva. La tecnología innovadora no viene acompañada de patrones de éxito establecidos y mejores prácticas. La tecnología innovadora es novedosa y […]
Descargue la Introducción al estándar TOGAF, 10.ª edición
Descargar Introducción al estándar TOGAF®, 10.ª edición El estándar TOGAF, 10.ª edición facilita la adopción de las mejores prácticas de arquitectura empresarial. Separa los conceptos universales de las mejores prácticas comprobadas. El subrayado estándar donde […]
Descargar la guía de planificación basada en la capacidad
Descargar la guía de planificación basada en capacidades Conduzca siempre para obtener valor. ¡La mitad de la mejora es un desperdicio de 100%! Nadie le enseña a un águila a gatear, caminar o correr. ¡Las águilas vuelan! Descargue Enseñe a volar a sus águilas: planificación basada en capacidades […]
Descargar la guía de evaluación de la capacidad de la arquitectura empresarial
Descargue la Guía de evaluación de la capacidad de la arquitectura empresarial Descargue una Guía de evaluación de la capacidad de la arquitectura empresarial. La planificación basada en la capacidad es una de las técnicas de mejora de la arquitectura empresarial más poderosas. La mejor práctica de la planificación basada en la capacidad utiliza la capacidad como una gestión […]
Descargar ejemplos de principios de arquitectura empresarial
Descargar principios de arquitectura de muestra Descargue principios de arquitectura empresarial de muestra. Los principios de la arquitectura empresarial identifican cómo abordar un problema o una decisión. El enfoque siempre lo lleva hacia sus prioridades duraderas. Descargue los principios de arquitectura empresarial de muestra […]
Descargue la Guía de gobierno de la arquitectura empresarial
Descargue la Guía de gobierno de la arquitectura empresarial Descargue la Guía de gobierno de la arquitectura empresarial para comprender las mejores prácticas para dirigir y controlar el desarrollo de la arquitectura y cambiar para obtener los resultados esperados. Descargue la Guía de Gobernanza de la Arquitectura Empresarial […]
Descargar Integración TOGAF y SABSA
Descargar Integración de TOGAF y SABSA Reúna SABSA, el mejor marco de arquitectura de seguridad del mundo, y TOGAF, el marco de arquitectura empresarial estándar de la industria. Descargar Integración TOGAF y SABSA Integración TOGAF y SABSA Incluye SABSA utiliza […]
Descargar la arquitectura de referencia de la capacidad de la arquitectura empresarial
Descargar Arquitectura empresarial Arquitectura de referencia de capacidades La arquitectura de referencia de capacidades de la arquitectura empresarial acelerará el establecimiento y la mejora de su equipo de EA. Diseñe su equipo de arquitectura empresarial para el éxito. Identifique y mejore la arquitectura de su empresa […]
Descargar informe de arquitectura empresarial ágil
Descargar el informe de arquitectura empresarial ágil El informe de arquitectura empresarial ágil cubre nuestra experiencia: la arquitectura empresarial ágil es real, práctica y valiosa. Lo hacemos todos los días. Los informes de campo unen los conceptos teóricos y […]
Descargar el estudio de caso de arquitectura empresarial ágil
Descargue el estudio de caso de arquitectura empresarial ágil Descargue el estudio de caso de arquitectura empresarial ágil para ver un ejemplo que desarrolla una capacidad de EA y una arquitectura útil al mismo tiempo. Cubrimos los seis casos de uso […]
Arquitectura empresarial y ágil: definir el enfoque ágil
Ágil es una elección. Tiene ventajas y desventajas. La adopción de Agile requiere opciones sobre producto, plataforma, estrategia de prestación de servicios y puntos de transición de arriba hacia abajo.
Un equipo de EA necesita la capacidad de brindar soporte Estrategia y portafolio a definir el enfoque ágil.
Problema predecible: ¿Cuándo usas Agile?
Patrón del producto
Los productos externos son más fáciles que los productos internos. En resumen, hay un mercado. Internamente, el uso ágil impulsa el sistema interno hacia productos digitales. Se debe determinar la existencia, el alcance y el enfoque de desarrollo de los sistemas internos.
Problema predecible: ¿De dónde viene el producto?
Acercarse: Ajustar la definición de "soluciones" utilizadas para llenar vacíos y los resultados del paquete de trabajo para alinearse con productos autónomos. Desarrollar una cartera de productos internos y un conjunto de medidas de valor para los productos internos. Los productos deben aparecer en el hoja de ruta de la arquitectura.
Patrón de plataforma
Las plataformas pueden mejorar la velocidad del desarrollo y la sostenibilidad. Sin embargo, una plataforma mal seleccionada tendrá el resultado contrario. No es decisión de un equipo ágil utilizar una plataforma, y mucho menos qué plataforma. Hemos utilizado el término plataforma para cubrir SAP, M365, Facebook, Pega o incluso Open Shift Containers.
Arquitecturas de referencia Tienen un papel fundamental en la definición, selección y gobernante el uso de plataformas.
Problema predecible: ¿Cuándo se debe utilizar una plataforma y cuándo el producto no debe tener restricciones?
Acercarse: Múltiples enfoques
-
- Utilice una alternativa de arquitectura para seleccionar. Las principales preocupaciones serán la confianza, la sostenibilidad, el tiempo de comercialización y la continuidad del negocio.
- Utilice la plataforma Arquitectura de referencia Para garantizar la integridad del diseño del producto y evaluar si se pueden cubrir todas las lagunas
bits duros: Cuestión de soporte y sostenibilidad del producto y plataforma.
Patrón de estrategia de prestación de servicios
Una estrategia de prestación de servicios se refiere al enfoque que utilizaron las organizaciones para proporcionar productos o servicios. No es un hecho que usted seleccione su enfoque actual: interno, contrato, aumento de personal.
Problema predecible: ¿Cómo logrará su organización un desarrollo ágil?
Acercarse: Seguir los planteamientos de la Arquitectura para soportar la Estrategia. Plantee la pregunta de cómo se permitirá el desarrollo ágil. Utilice un Modelo operativo para definir el valor y un Mapa Organizacional definir cómo trabajarán juntos los diferentes consumidores, desarrolladores y operadores de un producto.
Patrón de punto de reposo de valor principal
El desarrollo ágil no tiene menos probabilidades que cualquier otro enfoque de saber cuándo detenerse. Los puntos de descanso de valor son sinónimo de transiciones de arquitectura. Usamos este término para resaltar que el interesado tiene una vía de salida y puede dejar de invertir. Las partes interesadas utilizarán las rampas de salida por varias 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 se puede utilizar el mismo esfuerzo para alcanzar un resultado más valioso
- Cuando las prioridades organizacionales han cambiado (gobernancia)
- Cuando hay una amenaza u oportunidad inesperada (agilidad empresarial)
- Cuando el esfuerzo para llegar al siguiente punto de descanso supera el valor incremental.
Problema predecible: Conocer el punto de reposo del valor para detenerse o cambiar de enfoque
Acercarse: Utilice hojas de ruta de arquitectura para explorar puntos de entrega de valor alternativos. Crear informes sobre la actividad hacia los estados de transición.
Bits duros: 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 involucran emocionalmente en un camino o punto de descanso. Especialmente cuando se está considerando la existencia del producto o el próximo lanzamiento. Los altos directivos siempre están buscando el mejor camino a seguir, no el mayor rendimiento potencial. Quieren el mejor camino.
Explorar los puntos de reposo del valor es el primer paso. Los tomadores de decisiones necesitan entender las opciones (selección basada en diferentes criterios y aplazamiento de decisiones inciertas). Luego identifique lo que se necesita para llegar a diferentes puntos de descanso de valores seleccionados.
-
- ¿Qué cambio perseguir según diferentes criterios?Arquitectura Roadmap Tipo 4: Escenarios
- ¿Qué trabajo generará valor y el costo y la incertidumbre?Arquitectura Roadmap Tipo 1: Heatmap
- ¿Qué decisiones se aplazan?Arquitectura Roadmap Tipo 4: Escenarios
- ¿Cuándo se entregará el valor?Estados de transición
Vaya más allá con los procesos y métodos de arquitectura empresarial de mejores prácticas
Mejores prácticas arquitectura empresarial de Conexiam Navegar
Mejores prácticas para implementar herramientas de gestión de arquitectura empresarial
Mejores prácticas para implementar herramientas de gestión de arquitectura empresarial Las herramientas de gestión de arquitectura empresarial están diseñadas para respaldar la planificación, el diseño, el análisis y la ejecución de la arquitectura empresarial. Permiten a los arquitectos empresariales examinar la necesidad de cambio […]
Comparación del marco de arquitectura empresarial: ¿cuál es el adecuado para usted?
Comparación de marcos de arquitectura empresarial: ¿cuál es el adecuado para usted? No existe una solución única para todos en el mundo de los negocios, ni tampoco para los marcos de arquitectura empresarial. Compare los méritos de los marcos más populares para determinar qué marco optimizado es el adecuado para usted. Si bien […]
Gestión del trabajo de arquitectura empresarial
Gestión del trabajo de arquitectura empresarial La gestión del trabajo de arquitectura empresarial es fundamental para el éxito diario de un equipo de arquitectura empresarial. Los arquitectos deben ofrecer una orientación útil antes de que las partes interesadas tomen decisiones informadas. Los arquitectos empresariales deben traducir […]
Cómo definir los principios de la arquitectura empresarial
Cómo definir los principios de la arquitectura empresarial Para definir los principios de la arquitectura empresarial, hay que empezar por entender qué es un principio y cómo aplicarlo. De este modo, podemos desarrollar principios de arquitectura sólidos que ayuden a mejorar nuestra organización. […]
Comprender la arquitectura empresarial y la agilidad
Comprender la arquitectura empresarial y la arquitectura ágil Tanto la arquitectura ágil como la empresarial están diseñadas para reducir el riesgo. El desarrollo ágil de software sobresale en la construcción de algo que nunca antes habíamos tenido y no sabemos cómo construir. […]
Desarrollo de una estrategia de arquitectura empresarial
Desarrollo de una estrategia de arquitectura empresarial: plan estratégico para el cambio La estrategia de arquitectura empresarial es acción. Las acciones que llevará a cabo su organización y los cambios que realizará para alcanzar sus objetivos estratégicos. El desarrollo de una estrategia es una cuestión de elección. […]
Garantizar la alineación y la rendición de cuentas: el papel crucial de las listas de verificación de gobernanza de la arquitectura empresarial
Garantizar la alineación y la rendición de cuentas: el papel crucial de las listas de verificación de gobernanza de la arquitectura empresarial Las listas de verificación de gobernanza de la arquitectura empresarial simplifican los procesos de gobernanza de la arquitectura empresarial. El proceso de gobernanza debe aprobar la arquitectura de destino y proporcionar gobernanza de implementación. Una empresa sólida […]
Aprovechar el poder de la planificación basada en la capacidad: una guía rápida
Libere el poder de la planificación basada en la capacidad: una guía rápida ¿Está buscando una forma más eficaz de planificar y ejecutar su estrategia comercial? No busque más allá de la planificación basada en la capacidad. Identificar y utilizar los […]
Creación de un Comité de Revisión de Arquitectura Moderna
La creación de un comité de revisión de arquitectura moderna exige crear un proceso de gobernanza dinámico y establecer un órgano de toma de decisiones de alto nivel. El objetivo es establecer una gobernanza de la arquitectura eficaz sin burocracia. […]
Hoja de ruta de la arquitectura empresarial como diseño
Hoja de ruta de arquitectura empresarial como diseño Una hoja de ruta de arquitectura es una herramienta de planificación que ayuda a los responsables de la toma de decisiones de una organización. Una hoja de ruta de arquitectura dinámica está diseñada para ayudarlos a desarrollar y recorrer el mejor camino a seguir. También […]
Arquitectura empresarial y ágil: trabajo pendiente de guía en Sprint
Los equipos fuertes y ágiles encuentran el camino más eficaz a seguir. La planificación y la presupuestación a largo plazo existen debido a la complejidad del ecosistema. El desafío es unir la planificación a largo plazo y la creatividad ágil. Unir la planificación de arriba hacia abajo y la ejecución de abajo hacia arriba.
Es necesario informarles sobre las prioridades organizacionales en términos que puedan incorporarse a la gestión del trabajo atrasado.
La agilidad existe porque las personas más cercanas a la solución pueden encontrar el camino más eficaz. Las organizaciones exitosas realizan priorizaciones y compensaciones. Sin alcanzar el futuro preferido en las limitaciones de tiempo y recursos, no debería comenzar ningún trabajo.
Un equipo de EA necesita la capacidad de brindar soporte portafolio y Proyecto para trabajo pendiente de guía en sprint.
Problema predecible: Garantizar que los resultados esperados, el valor, las expectativas de rendimiento en cascada y las limitaciones guíen el lanzamiento y el desarrollo del producto.
poco difícil: Demasiados evangelistas ágiles se sorprenden de que las organizaciones que adoptan la metodología ágil sigan profundamente comprometidas con la planificación y la elaboración de presupuestos a largo plazo. A menudo tenemos que superar la mitología de que existe una preferencia cultural por la cascada.
Hoja de ruta para guiar el patrón de producto
Problema predecible: Tener una hoja de ruta integral del producto, en lugar de un ciclo de lanzamiento de funciones.
Acercarse: Usando un técnica de hoja de ruta de arquitectura donde el producto, o familia de productos, ocupa el lugar de la Cartera. Asegúrese de que los informes normales del producto incluyan la actividad hacia los estados de transición.
bits duros: Una excelente gestión de productos brindará una hoja de ruta integral del producto. Demasiados propietarios de productos ascendentes no tienen experiencia en la gestión del ciclo de vida o la integración en un conjunto de productos integrado. El equipo de EA deberá completar o sustituir según la habilidad de la organización del producto.
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. Una hoja de ruta de arquitectura clásica hablará de transiciones, brechas y paquetes de trabajo. Esto será incomprensible para un equipo de producto. Cambie el idioma a terminología ágil y de producto. El propietario del producto debe comprender las limitaciones con las que opera.
Construir la hoja de ruta requiere suficiente arquitectura. El único enfoque escalable es 'sólo lo suficiente.' Lo suficiente significa hacer cumplir las prioridades organizacionales y evitar problemas predecibles. Lo suficiente significa mantenerse al margen del diseño del producto. Utilice patrones de arquitectura que funcionen en todo el portafolio. Bastar significa ignorar la sinergia potencial. Lo suficiente significa centrarse en problemas predecibles. El valor de esquivar problemas predecibles es alto. Lo suficiente significa no tener miedo de utilizar la destrucción creativa. Utilice un concepto de ciclo de vida esperado para impulsar una refactorización agresiva (enfoques totalmente nuevos y revolucionarios).
El uso de las técnicas con el propietario del producto ayuda a incorporar las prioridades y limitaciones de la organización en la hoja de ruta del producto.
-
- Qué producto o características clave buscar según diferentes criterios: Arquitectura Roadmap Tipo 4: Escenarios
- ¿Qué productos o características ofrecerán valor (beneficio, trabajo y incertidumbre – Arquitectura Roadmap Tipo 1: Heatmap
- ¿Cuándo son necesarios cambios de producto y plataforma? Arquitectura Roadmap Tipo 2: Ciclo de vida
- ¿Cuál es la dependencia y el impacto del trabajo y el cambio? Hoja de ruta de arquitectura tipo 3: impacto y dependencia
Hoja de ruta para guiar el patrón épico
Problema predecible: Uso de epopeyas para implementar resultados y restricciones de arriba hacia abajo en el producto.
Acercarse: Usar estados de transición bien construidos en un técnica de hoja de ruta de arquitectura donde el producto, o familia de productos, ocupa el lugar de la Cartera. Asegúrese de que los informes normales del producto incluyan la actividad hacia los estados de transición.
Bits duros: Requiere productos estrechamente integrados o estrechamente restringidos. El área de atención debe centrarse en la integración o los puntos de restricción. Múltiples productos coexistiendo dentro de un ecosistema y compartiendo datos de referencia es un ejemplo simple.
Es común caer en la trampa del diseño inicial. La atención debe centrarse en las áreas donde los desarrolladores de software necesitan limitar su creatividad debido a requisitos externos o del ecosistema. Idealmente, esto debería hacerse por adelantado y no como reacción a la deuda técnica.
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.
Patrón de valor empresarial
Problema predecible: Garantizar que los factores críticos de éxito incluidos en los estados de transición y objetivo guíen la preparación ágil de los trabajos pendientes y una planificación épica.
Acercarse: Traducir medidas y objetivos de arriba hacia abajo en criterios consumibles para una gestión ágil de los trabajos pendientes. Asegúrese de que los informes normales del producto incluyan la selección y finalización de actividades para alcanzar el valor indicado.
Bits duros: Las medidas de arriba hacia abajo deben ser definitivas y fáciles de evaluar. Por ejemplo, al equipo ágil no se le puede pedir que desarrolle un equilibrio matizado entre el tiempo de comercialización y la resiliencia. Se requiere una terminología inequívoca.
Cualquier cambio en las medidas de arriba hacia abajo causará confusión. Esto es especialmente cierto si se ha alcanzado un estado de transición.
Para productos internos, siempre nos aseguramos de tener un modelo de costos sólido para productos digitales antes de introducir medidas de costos. Sin un modelo de costos, se perderán costos operativos y de plataforma y todos los costos se justificarán en función del costo de implementación. Planee ayudar al gerente de producto interno con comprensión de ITFM. Por el contrario, los gerentes de producto de productos digitales externos normalmente tienen un conocimiento muy sólido de los costos.
Restringir el patrón de propietario de producto "de abajo hacia arriba"
Problema predecible: Los propietarios de productos ven toda la empresa a través de la lente de su producto y sus usuarios directos.
Acercarse: Documentar el producto y el rol dentro del ecosistema. Documente las restricciones que se aplican al producto. Criterios de valoración de documentos. Asegúrese de que los informes normales del producto incluyan el progreso hacia los estados de transición y la actividad alineada con el valor empresarial.
Bits duros: Los propietarios de productos digitales internos suelen ser un eslabón débil. Los desafíos comunes incluyen no comprender:
-
- por qué existe su producto
- Papel del producto en el ecosistema.
- criticidad de las restricciones empresariales
- ¿Quiénes son los que toman las decisiones (financiadores)?
- cómo obtener orientación sobre prioridades empresariales y medidas de valor
Es muy probable que los equipos de EA que respaldan la cartera y el proyecto necesiten limitar a los propietarios de productos "de abajo hacia arriba". Requiere un esfuerzo deliberado y una asignación de personal.
Formación en Arquitectura Empresarial y Formación TOGAF
Educación en línea efectiva
Educación en línea eficaz La educación en línea eficaz funciona. Los estudiantes tienen acceso al mejor instructor disponible. Los estudiantes controlan el ritmo de su aprendizaje. Los instructores pueden compartir material complementario valioso sin distraerse del tema principal. La educación a distancia eficaz […]
Curso de formación en arquitectura empresarial de TOGAF
¿Quieres formación para la Certificación TOGAF? Demuestre su conocimiento de arquitectura empresarial con la certificación TOGAF Curso de capacitación en arquitectura empresarial TOGAF® Dé un gran paso para ser un mejor arquitecto empresarial con el estándar TOGAF, décimo […]
Curso de formación en arquitectura negocios
Formación en arquitectura empresarial La arquitectura empresarial eficaz se basa en la arquitectura empresarial. El curso brinda a los estudiantes las habilidades y el conocimiento para desarrollar la arquitectura empresarial en un entorno de arquitectura empresarial. La arquitectura empresarial implica describir la estructura del […]
Capacitación en arquitectura empresarial personalizada
Capacitación en arquitectura empresarial personalizada La capacitación en arquitectura empresarial personalizada aborda el desarrollo profesional que su equipo de EA necesita. Los buenos arquitectos empresariales utilizan un amplio conjunto de habilidades, métodos, además de conocimientos de dominio especializados para desarrollar […]
Kickstart del arquitecto empresarial
El Kickstart del arquitecto empresarial Necesitamos mantener nuestras habilidades actualizadas. Ahora más que nunca. Utilice el Kickstart de arquitectura empresarial para mejorar su capacidad de ofrecer una arquitectura empresarial transformadora. Este kickstart de 90 días es la forma en que Conexiam Consulting […]
Curso de formación Avolution ABACUS
Avolution ABACUS Training La arquitectura empresarial eficaz se basa en el modelado y el análisis formales. Brindamos capacitación en Avolution ABACUS por parte de arquitectos empresariales prácticos. Los estudiantes adquieren habilidades y conocimientos para crear arquitecturas empresariales y de dominio integradas en este […]
Arquitectura empresarial y ágil: limitar los sprints
Estamos pasando de ayudar a un equipo ágil a gestionar su espalda a dedicarnos al sprint. Aquí debemos introducir las especificaciones de arquitectura en el software. Debemos hacerlo sin interferir en la creatividad e innovación del equipo ágil.
Cada especificación de arquitectura elimina un grado de libertad. Cuando restringimos su libertad, le hacemos más difícil al equipo ágil encontrar el camino más eficiente. Cuando las limitaciones impulsan las prioridades empresariales, facilitamos la búsqueda del mejor camino.
Hay una regla básica: nunca elimine un grado de libertad si no es necesario
La libertad para innovar y crear es el alma del desarrollo de software ágil
Hay una regla avanzada: nunca tengas miedo de darle a un equipo ágil un problema realmente difícil
La innovación y la creatividad crearán soluciones que no puedes imaginar
Problema predecible: Garantizar que las decisiones durante el sprint, fundamentales para el éxito ágil, sean conscientes de las prioridades, preferencias y limitaciones de la organización y estén dirigidas por ellas.
bits duros: Encontrar un equilibrio entre las exigencias empresariales y la interferencia en la libertad de diseño y enfoque requerida. Esto es especialmente cierto en el caso de los arquitectos con experiencia en desarrollo. La experiencia en la materia crea una pendiente resbaladiza que va más allá de las especificaciones empresariales y llega al diseño. Esto conduce a una mala arquitectura inicial.
Los arquitectos empresariales que respaldan la entrega de proyectos y soluciones deberían limitar los sprints. Los arquitectos que se centran en un ecosistema o plataforma de producto también deberían esperar trabajar con los equipos ágiles aquí.
Patrón de criterios de aceptación
Problema predecible: Garantizar que el software se ajuste a las especificaciones y estándares de la arquitectura empresarial.
Acercarse: Proporciona criterios de aceptación obligatorios aplicables al final de las epopeyas y antes del lanzamiento. A menudo hemos utilizado Patrones de arquitectura de aplicaciones y Patrones de arquitectura de datos para crear criterios de aceptación. Incluir criterios de aceptación obligatorios en todos los informes de prueba.
Bits duros: Saber cuándo hacer cumplir los criterios de aceptación obligatorios. Demasiado pronto distorsiona el desarrollo. Demasiado tarde genera presión para que se expidan excepciones. Esto es especialmente cierto en el caso de productos digitales internos que no tienen ciclos de lanzamiento reales y predecibles.
Clasificamos nuestras especificaciones de arquitectura como:
-
- principio de arquitectura
- patrón de arquitectura
- estándar
- regla
La mayoría de los criterios de aceptación obligatorios deben ser patrones o estándares de arquitectura.
Nunca olvides apartarte del camino y cosechar la creatividad.
Valor (compases y puntos de reposo) Patrón
Problema predecible: Comprender qué se valora y cómo se mide el valor.
Acercarse: La arquitectura empresarial debe ser definitiva en cuanto a cómo se describe y mide el valor. Las declaraciones de valor requieren factores críticos de éxito (CSF) y medidas de eficacia (MoE). Asegúrese de que las medidas de valor se incluyan en los informes de productos, épicos y de lanzamiento.
Bits duros: Para muchos profesionales de TI tienen una comprensión limitada del valor. Utilizarán una taquigrafía rápida que exprese el valor en términos de algo entregado. El valor se nota en la entrega.
En un mundo complejo, cualquier cosa que se entregue puede degradar el valor. Un ejemplo sencillo son las funciones dirigidas a usuarios que no son clientes objetivo. O, cuando una unidad de trabajo solicita funcionalidades que simplifiquen su actividad a expensas del sistema.
Recomendamos encarecidamente prácticas básicas de Lean y Six-Sigma. Analice la definición y cuantificación del valor. Busque optimización local. Los conceptos de Cliente objetivo y Propuesta de valor del Business Model Canvas son muy útiles.
Greenfield, evolución o revolución
En Fase E de TOGAF, hay un paso genial. Mire el paquete de trabajo y seleccione una estrategia adecuada: Greenfield, Evolutiva o Revolucionaria. ¿Espera conservar tanto como sea posible, refactorizar radicalmente o empezar desde cero?
Esto se hace en la cartera de productos y la planificación del ecosistema. Es una guía fundamental y una fuerte limitación para un equipo ágil. ¿Les ordena que empiecen desde cero (Greenfield)? ¿Mejorar los sistemas existentes de forma incremental (evolución)? ¿O realizar un cambio radical que se espera elimine las fricciones y los problemas con los que hemos estado viviendo (revolucionario)?
Problema predecible: Garantizar que se siga la estrategia de implementación.
Acercarse: Utilice la hoja de ruta del producto y los ciclos de lanzamiento para imponer cambios radicales en el enfoque.
Poco duro: Alinear los cambios de arquitectura de arriba hacia abajo con una hoja de ruta del producto. Esto es más difícil cuando las decisiones para respaldar la estrategia o la cartera requieren un cambio en el enfoque del producto. Hemos tenido que dedicar mucho tiempo a tranquilizar a los propietarios de productos digitales y, a través de ellos, a sus equipos, que el esfuerzo previo no fue en vano.
Restringir el patrón de interfaz
Cuando un producto debe encajar en un entorno empresarial existente o ser compatible con un entorno empresarial en evolución, las interfaces son clave. Las interfaces estarán impulsadas por datos y métodos. En un mundo complejo, ni siquiera los productos emergentes tendrán libertad para que surja alguna estructura de datos e interfaz. Los datos maestros, los datos de referencia y los sistemas existentes limitarán el desarrollo ágil.
Los sistemas existentes no van a cambiar. La inversión se está realizando en nuevos sistemas. Es el nuevo sistema el que debe encajar. Incluso el F-22 Raptor tuvo que conectarse con sistemas heredados utilizando interfaces desarrolladas en la década de 1970. Ni siquiera un avión tan caro podría remodelar los sistemas heredados.
Problema predecible: Identificar las interfaces necesarias y garantizar su uso.
Acercarse: Centrar el trabajo de arriba hacia abajo en interfaces y estructuras de datos compartidos. Requisitos de alimentación a través de ciclos épicos y de lanzamiento. Utilice criterios de aceptación. A menudo hemos utilizado Patrones de arquitectura de aplicaciones y Patrones de arquitectura de datos a interfaces ligeramente específicas. Incluya la conformidad de la interfaz en todos los informes de prueba.
Poco duro: Las interfaces son uno de los puntos donde suele ser necesaria una planificación prospectiva de arriba hacia abajo. Esfuerzo para garantizar que exista una infraestructura API sólida, API publicadas y estructuras de datos para datos maestros, datos de referencia y registros transaccionales.
Los equipos de productos que cambian rápidamente a menudo pasan por alto la legislación multijurisdiccional o un plan de negocios de mercado en expansión. En estos casos, el equipo de EA tiene el deber de mirar hacia el futuro. Como regla general, nos sentimos más cómodos con una refactorización radical que con una planificación anticipada. Especialmente porque hemos reforzado la modularidad y las interfaces.
Arquitectura empresarial y ágil: resolver la dependencia
Los equipos ágiles y el desarrollo centrado en productos digitales no son adecuados para resolver problemas en un ecosistema o cartera de productos. El diseño fundamental de Agile es que un solo equipo analice los problemas y los resuelva directamente. Existen conceptos de equipo de equipos, pero les cuesta salir del momento actual.
Cualquier equipo de arquitectura debe asumir la responsabilidad de resolver problemas entre productos. El desarrollo ágil y la integración moderna hacen que este servicio de necesidades sea más importante que nunca.
Desbloquear el patrón de cartera
Problema predecible: El conflicto en la cartera de productos digitales bloquea el progreso de múltiples productos.
Acercarse: Utilice técnicas de arquitectura empresarial para encontrar los cambios mínimos que permitan el progreso.
Bits duros: El desafío más crítico es el tiempo. Los equipos de desarrollo ágil de mejores prácticas creativas trabajarán para resolver el problema. Cuando el problema surge, generalmente será un obstáculo crítico, con capas de deuda técnica.
El equipo de EA deberá centrarse en estados de transición incrementales para permitir el progreso en toda la cartera de productos.
Identificar el patrón real de las partes interesadas
Problema predecible: Identificar a la verdadera parte interesada que puede brindar dirección y aprobación en una cartera de productos interna compleja.
Acercarse: Utilice técnicas de arquitectura empresarial para identificar partes interesadas y agentes, inquietudes y preferencias de las partes interesadas. Utilizar técnicas de arquitectura empresarial de alternativas y compensación para guiar a las partes interesadas hacia una decisión que dirigirá la cartera de productos. Garantizar una gobernanza eficaz de la cartera digital.
Bits duros: Podemos esperar que los equipos de productos digitales tengan fuentes de autoridad locales y un modelo simplista de toma de decisiones y autoridad de decisión. Además, su comunicación y evaluación serán tácticas y orientadas a las TI.
El equipo de EA tendrá que trabajar para garantizar una gobernanza eficaz en toda la cartera digital y colaborar con las estructuras de autoridad de los productos digitales. Además, los equipos de EA no tienen una capacidad especial para lograr la participación de las partes interesadas. Tienen la capacidad de representar las preocupaciones de las partes interesadas a través de una arquitectura superior.
Cruzar el patrón de cartera
Problema predecible: Las decisiones tácticas optimizadas localmente no pueden surgir como un ecosistema digital eficaz y sostenible.
Acercarse: Mantener lo suficiente Arquitectura de la aplicación y Arquitectura de datos. Impulsar la prioridad organizacional en esa arquitectura. La arquitectura de aplicaciones debe centrarse en interfaces y servicios compartidos. La arquitectura de datos debe centrarse en datos maestros, datos de referencia y datos con clasificación de alta seguridad. Requerir descripciones de metadatos. Utilice patrones de arquitectura que especifiquen el enfoque de ecosistemas.
Bits duros: Cruzar la cartera requiere cuadrar dos realidades en conflicto. En primer lugar, el enfoque ágil apareció debido al fracaso observado en el diseño empresarial detallado de arriba hacia abajo. En segundo lugar, las soluciones emergentes optimizadas localmente no pueden construir sistemas complejos eficientes sin una fuerte presión evolutiva y tiempo para evolucionar.
El único enfoque escalable es 'sólo lo suficiente.' Lo suficiente significa hacer cumplir las prioridades organizacionales y evitar problemas predecibles. Por ejemplo, si la prioridad de su organización es la sostenibilidad, la arquitectura de su aplicación debe imponer la modularidad y el uso de una infraestructura de aislamiento como una puerta de enlace API.
Lo suficiente significa mantenerse al margen del diseño del producto. En su lugar, debe utilizar patrones de arquitectura que funcionen en todo el portafolio.
Bastar significa ignorar la sinergia potencial. Es común que los esfuerzos por imaginar un futuro complejo se conviertan en una farsa. La sinergia es lo más difícil de encontrar. Todo nuestro trabajo de hoja de ruta de arquitectura demuestra que siempre pagas la factura por algo, es posible que obtengas el beneficio. El valor de la sinergia es bajo cuando se aplica la incertidumbre.
Lo suficiente significa centrarse en problemas predecibles. Nadie ha creado nunca un maestro de clientes distribuido sin datos de referencia. Alguna vez. Ése es un problema de datos predecible. Resuélvelo temprano. El valor de esquivar problemas predecibles es alto.
Basta significa no tener miedo de utilizar las fuerzas del mercado y la destrucción creativa. Usamos un concepto de ciclo de vida esperado para resaltar en qué parte del ecosistema esperamos implementar regularmente una refactorización agresiva (enfoques totalmente nuevos y revolucionarios).
Patrón de impacto de liberación
Problema predecible: La arquitectura suficiente significa que cada contingencia, cada restricción, cada conflicto no se descubrió antes del lanzamiento.
Acercarse: Pon las manos en los bolsillos y espera a que te llamen durante la resolución. A menos que lo llamen, espere para participar durante la revisión del incidente y descubrir dónde no identificó un problema predecible, subestimó un riesgo o no cumplió con un requisito de prueba.
Bits duros: Hay un caso en el que un equipo de arquitectura podría tener una emergencia. Esos raros casos en los que las implicaciones se extienden más allá del producto. Si los usuarios finales están solucionando el defecto, no se trata de una emergencia. Cuando crean vulnerabilidad y responsabilidad, tenemos una emergencia.
Utilice una buena técnica de espacio, paquete de trabajo y punto de descanso de valor. Busque el cambio más pequeño que proporcione valor aprovechable. En este caso, el valor es eliminar la amenaza y la responsabilidad.
Conclusión de la arquitectura empresarial y ágil
Tanto la arquitectura empresarial como la metodología ágil sufren de una mala aplicación crónica. Con demasiada frecuencia al mismo tiempo. Ajusta tu enfoque para que tu ágil y arquitectura empresarial Los esfuerzos reducen la incertidumbre del éxito.
Como arquitecto empresarial, busque vehículos en los que pueda utilizar un enfoque incremental para reducir la probabilidad y el costo de los errores. Cuando se reduce el costo de los esfuerzos de cambio fallidos, se elimina el desperdicio. 100% de sus esfuerzos de cambio desperdiciados reducen el valor del cambio.
La matemática es simple, el beneficio siguió siendo el mismo, el trabajo aumentó. La red tiene menos valor.
La respuesta simple es jugar con tu fuerza. Y espere que el ágil equipo aproveche sus fuerzas.
La arquitectura empresarial y la metodología ágil tienen cuatro patrones de participación de alto nivel:
- definir el enfoque ágil
- guiando el backlog en sprint
- limitar los sprints ágiles
- resolviendo la dependencia de productos cruzados
La selección del patrón depende de su caso de uso de arquitectura empresarial el diseño de tu equipo EA.
Yendo más allá con arquitectura y agilidad empresarial
Ir más lejos Agilidad es distinto del desarrollo ágil de software. La arquitectura empresarial y la agilidad encajan en tres áreas:
- 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
