Comprender la arquitectura empresarial y Agile
¿Cómo se combinan la arquitectura empresarial y Agile?
Arquitectura empresarial y Agile: definir el enfoque Agile
Arquitectura empresarial y Agile: Guía del Backlog en Sprint
Arquitectura empresarial y Agile: Restricción de sprints
Arquitectura empresarial y Agile: Resolver la dependencia
Conclusión sobre arquitectura empresarial y metodología ágil
¿Cómo se combinan la arquitectura empresarial y Agile?
La arquitectura empresarial y la metodología ágil se complementan de maneras inesperadas. El enfoque actual del método ágil son los pasos para crear un software de envío viable. Desde esta perspectiva, la pregunta es: ¿qué hace la arquitectura empresarial hoy? ¿Qué hace para agilizar el software de envío?
La arquitectura empresarial y la metodología ágil no encajan dentro del sprint. Se integran fuera del ciclo de desarrollo. Se integran cuando los arquitectos empresariales y los desarrolladores ágiles realizan su trabajo. Los equipos de arquitectura empresarial exitosos cumplen con sus objetivos. caso de uso. No cumplen con nada más. Incluso si pudieran.
Contamos con una arquitectura empresarial simple y un modelo de referencia ágil. Existen cuatro patrones fundamentales de interacción con la arquitectura empresarial:
- Definiendo el enfoque ágil
- Guiar el backlog en el sprint
- limitando los sprints ágiles
- Resolviendo la dependencia del producto cruzado
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 compromiso?
Primero, analiza tu caso de uso de EA. ¿Qué orientación se espera que brindes? ¿A quiénes prestas servicios? Luego, analiza los patrones de participación que abordan los desafíos de tu trabajo. Incorpóralos a tu participación.
Nuestra plantilla de patrón de arquitectura tiene dos elementos clave: el problema predecible y el acercarse para resolver el problema. También recopilamos la partes duras. Cuando consideramos un patrón, observamos qué tan bien resuelve el problema y cuánto trabajo adicional es necesario para aplicarlo con éxito.
Analicemos los patrones de interacción: el problema que resuelven, el enfoque y los aspectos difíciles.
- Definiendo el enfoque ágil
- Guiar el backlog en el sprint
- limitando los sprints ágiles
- Resolviendo la dependencia del producto cruzado
Ejemplo práctico: Desarrollo ágil en la hoja de ruta de la arquitectura empresarial
Tuve una conversación amena con la ingeniera de confiabilidad de sistemas recién contratada. La especialista en SRE estaba entusiasmada. Por fin habíamos empezado con 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 cuanto a sus desafíos inmediatos, nada. Estaba inmersa en la implementación. Estaba observando la implementación.
Ella no entendía cómo se estaba desarrollando la organización. No estaba al tanto de la hoja de ruta de la cartera. La hoja de ruta tenía un punto de transición que acabábamos de alcanzar. Habíamos incorporado contenedores, gestión de datos de prueba y un conjunto de pruebas automatizadas deficiente. No se dio cuenta de que la planificación vertical anticuada había creado las condiciones para su nuevo trabajo.
Ella pensaba en el desarrollo inmediato. Yo pensaba en todo el... transformación digital. Su función era ayudar a la organización en la siguiente transición. Estaba desarrollando... capacidades críticas. Las pruebas automatizadas proporcionarían evidencia de que se estaban siguiendo las restricciones de la arquitectura. Estaba pasando de... Definiendo el enfoque ágil. Necesitaba ayuda Para guiar el atraso.
Diez puentes y caminos que los conectan valen más que 500 medios puentes que no llevan a ninguna parte
490 constructores de puentes estarán descontentos
490 constructores de puentes que creían que estaban aportando valor
Arquitectura empresarial y Agile: definir el enfoque Agile
Agile es una opción. Tiene ventajas y desventajas. Adoptar Agile requiere decisiones sobre el producto, la plataforma, la estrategia de prestación de servicios y los puntos de transición descendentes.
Un equipo de EA necesita la capacidad de brindar soporte Estrategia y Cartera a definir el enfoque ágil.
Problema predecible¿Cuándo utilizar Agile?
Patrón de producto
Los productos externos son más fáciles de implementar que los internos. En resumen, existe un mercado. Internamente, el uso de metodologías ágiles impulsa el sistema interno hacia productos digitales. Es necesario determinar la existencia, el alcance y el enfoque de desarrollo de los sistemas internos.
Problema predecible¿De dónde viene el producto?
AcercarseAjustar la definición de ‘soluciones’ utilizada para subsanar deficiencias y los resultados del paquete de trabajo para que se ajusten a los productos independientes. Desarrollar una cartera interna de productos y un conjunto de indicadores de valor para los productos internos. Los productos deben aparecer en la hoja de ruta de arquitectura.
Patrón de plataforma
Las plataformas pueden mejorar la velocidad y la sostenibilidad del desarrollo. Sin embargo, una plataforma mal seleccionada tendrá el resultado contrario. Un equipo ágil no decide si usar una plataforma, ni mucho menos cuál. Hemos utilizado el término plataforma para referirnos a 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: Enfoques múltiples
-
- Utilice alternativas 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 cómo llenar todos los vacíos
Trozos duros:Cuestión de soporte y sostenibilidad del producto y la plataforma.
Patrón de estrategia de prestación de servicios
Una estrategia de prestación de servicios se refiere al enfoque que las organizaciones utilizan para proporcionar productos o servicios. No es inevitable que elija su enfoque actual (interno, por contrato o de aumento de personal).
Problema predecible¿Cómo implementará su organización el desarrollo ágil?
Acercarse: Siga los enfoques de la arquitectura para respaldar la estrategia. Plantee la pregunta de cómo se facilitará el desarrollo ágil. Utilice un Modelo operativo para definir 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 mayor
El desarrollo ágil tiene la misma probabilidad 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 destacar que la parte interesada tiene una vía de escape y puede dejar de invertir. Las partes interesadas utilizarán estas vías de escape por varias razones:
-
- Cuando el esfuerzo para alcanzar el siguiente punto de descanso excede el valor incremental.
Esta es una conversación sobre el retorno de la inversión (ROI). Las conversaciones sobre el ROI suelen conducir a un cambio de prioridad. - Cuando el mismo esfuerzo se puede utilizar para alcanzar un resultado más valioso
- Cuando las prioridades organizacionales han cambiado (gobernancia)
- Cuando existe una amenaza o una oportunidad inesperada (agilidad empresarial)
- Cuando el esfuerzo para alcanzar el siguiente punto de descanso excede el valor incremental.
Problema predecible:Conocer el Valor Punto de Reposo para detenerse o cambiar el enfoque
AcercarseUtilice hojas de ruta de arquitectura para explorar alternativas de entrega de valor. Genere informes sobre la actividad hacia las etapas de transición.
Trozos durosLas consideraciones incluyen el valor comparativo en reposo y el valor potencial como punto de partida para otras actividades. Los implementadores rara vez comprenden estas conversaciones. Se involucran emocionalmente en una ruta o punto de reposo, especialmente cuando se considera la existencia del producto o el próximo lanzamiento. Los líderes sénior siempre buscan el mejor camino a seguir, no el mayor retorno potencial. Quieren el mejor camino.
Explorar los puntos de equilibrio del valor es el primer paso. Quienes toman las decisiones deben comprender las opciones (selección basada en diferentes criterios y postergación de decisiones inciertas). Luego, identificar qué se necesita para alcanzar los diferentes puntos de equilibrio del valor seleccionados.
-
- ¿Qué cambio se debe buscar teniendo en cuenta los diferentes criterios?Hoja de ruta de arquitectura tipo 4: Escenarios
- ¿Qué trabajo aportará valor y cuál es el costo y la incertidumbre?Hoja de ruta de arquitectura tipo 1: Mapa de calor
- ¿Qué decisiones se aplazan?Hoja de ruta de arquitectura tipo 4: Escenarios
- ¿Cuándo se entregará el valor?Estados de transición
Arquitectura empresarial y Agile: Guía del Backlog en Sprint
Los equipos ágiles sólidos encuentran el camino más eficaz hacia adelante. La planificación y la presupuestación a largo plazo existen debido a la complejidad del ecosistema. El reto es conectar la planificación a largo plazo con la creatividad ágil. Conectar la planificación descendente con la ejecución ascendente.
Es necesario informarles sobre las prioridades organizacionales en términos que puedan incorporarse a la gestión de la cartera de pedidos.
La agilidad existe porque quienes están más cerca de la solución pueden encontrar el camino más efectivo. Las organizaciones exitosas priorizan y buscan soluciones. Sin alcanzar el futuro deseado con las limitaciones de tiempo y recursos, no se debería iniciar ningún trabajo.
Un equipo de EA necesita la capacidad de brindar soporte Cartera y Proyecto a Guía del backlog en el 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.
Parte difícilDemasiados promotores de la metodología ágil se sorprenden de que las organizaciones que la adoptan sigan estando profundamente comprometidas con la planificación y la presupuestación a largo plazo. A menudo debemos superar la mitología de que existe una preferencia cultural por el método en cascada.
Hoja de ruta para guiar el patrón del producto
Problema predecible:Tener una hoja de ruta de producto integral, en lugar de un ciclo de lanzamiento de funciones.
Acercarse:Usando un técnica de hoja de ruta de arquitectura Donde el producto o la familia de productos se ubican en el portafolio. Asegúrese de que los informes de productos incluyan la actividad hacia estados de transición.
Trozos durosUna excelente gestión de producto proporcionará una hoja de ruta completa. Muchos propietarios de producto de abajo a arriba carecen de experiencia en la gestión del ciclo de vida o la integración de una suite de productos integrada. El equipo de EA deberá sustituir o sustituir a los demás, según las habilidades de la organización del producto.
Demasiados equipos de arquitectura caen en la trampa de la precisión artificial o la omnisciencia imaginaria. Ambas son formas sofisticadas de referirse al pensamiento en cascada. Una hoja de ruta de arquitectura clásica hablará de transiciones, brechas y paquetes de trabajo. Esto resultará incomprensible para un equipo de producto. Cambie el lenguaje a terminología de producto y ágil. El propietario del producto debe comprender las limitaciones con las que opera.
Desarrollar la hoja de ruta requiere una arquitectura adecuada. El único enfoque escalable es...‘Sólo lo suficiente."Justo lo suficiente" significa imponer la prioridad organizacional y evitar problemas predecibles. "Justo lo suficiente" significa mantenerse al margen del diseño del producto. Usar patrones de arquitectura que funcionen en todo el portafolio. "Justo lo suficiente" significa ignorar las sinergias potenciales. "Justo lo suficiente" significa centrarse en problemas predecibles. El valor de evitar problemas predecibles es alto. "Justo lo suficiente" significa no tener miedo de usar la destrucción creativa. Usar el concepto de ciclo de vida esperado para impulsar una refactorización agresiva (enfoques desde cero y revolucionarios).
El uso de técnicas con el propietario del producto ayuda a incorporar las prioridades y limitaciones organizacionales a la hoja de ruta del producto.
-
- ¿Qué producto o características clave buscar según diferentes criterios? Hoja de ruta de arquitectura tipo 4: Escenarios
- ¿Qué productos o características aportarán valor (beneficio, trabajo y incertidumbre – Hoja de ruta de arquitectura tipo 1: Mapa de calor
- ¿Cuándo son necesarios cambios en el producto y la plataforma? Hoja de ruta de arquitectura 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:Usando estados de transición bien construidos en un técnica de hoja de ruta de arquitectura Donde el producto o la familia de productos se ubican en el portafolio. Asegúrese de que los informes de productos incluyan la actividad hacia estados de transición.
Trozos durosRequiere productos estrechamente integrados o con restricciones estrictas. El enfoque debe centrarse en la integración o en los puntos de restricción. Un ejemplo sencillo es la coexistencia de múltiples productos dentro de un ecosistema y el intercambio de datos de referencia.
Es común caer en la trampa del diseño inicial. El enfoque debe centrarse en las áreas donde los desarrolladores de software deben limitar su creatividad debido al ecosistema o a requisitos externos. Idealmente, esto debería hacerse desde el principio, en lugar de como una reacción a la deuda técnica.
Cuando logramos este objetivo, adoptamos activamente el lenguaje de métodos como SaFE y enmarcamos la hoja de ruta en términos de temas estratégicos y pautas de arquitectura.
Patrón de valor empresarial
Problema predecible:Asegurarse de que los factores críticos de éxito incluidos en los estados de transición y objetivo guíen la preparación del backlog ágil y la planificación épica.
Acercarse: Traducir las medidas y objetivos descendentes en criterios consumibles para la gestión ágil del backlog. Asegurar que los informes periódicos del producto incluyan la selección y finalización de actividades para alcanzar el valor establecido.
Trozos durosLas medidas descendentes deben ser definitivas y fáciles de evaluar. Por ejemplo, no se puede pedir al equipo ágil 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 descendentes generará confusión, especialmente si se ha alcanzado una etapa de transición.
Para los productos internos, siempre nos aseguramos de contar con un modelo de costos sólido para los productos digitales antes de implementar medidas de costos. Sin un modelo de costos, se perderán los costos operativos y de plataforma, y todos los costos se justificarán en función del costo de implementación. Planifique ayudar al gerente de producto interno con... Entendiendo ITFM. Por el contrario, los gerentes de productos de productos digitales externos normalmente tienen una comprensión muy sólida del costo.
Restringir el patrón de propietario del producto "de abajo hacia arriba"
Problema predecible:Propietarios de productos que ven toda la empresa a través de la lente de su producto y sus usuarios directos.
AcercarseDocumentar el producto y su rol dentro del ecosistema. Documentar las restricciones aplicables al producto. Documentar los criterios de evaluación. Asegurar que los informes habituales del producto incluyan el progreso hacia las etapas de transición y la actividad alineada con el valor empresarial.
Trozos durosLos propietarios de productos digitales internos suelen ser un punto 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 las medidas de prioridad y valor empresarial
Es muy probable que los equipos de EA que dan soporte a portafolios y proyectos deban restringir a los propietarios de producto de abajo a arriba. Esto requiere un esfuerzo deliberado y la asignación de personal.

Arquitectura empresarial y Agile: Restricción de sprints
Estamos pasando de ayudar a un equipo ágil a gestionar su parte posterior a profundizar en el sprint. Aquí debemos integrar las especificaciones de la arquitectura en el software. Debemos hacerlo sin interferir en la creatividad ni la innovación del equipo ágil.
Toda especificación de arquitectura elimina cierto grado de libertad. Al limitar su libertad, dificultamos que el equipo ágil encuentre la ruta más eficiente. Cuando las limitaciones impulsan las prioridades empresariales, facilitamos la búsqueda del mejor camino.
Hay una regla básica:Nunca elimines un grado de libertad si no es necesario
La libertad para innovar y crear es el elemento vital del desarrollo de software ágil.
Hay una regla avanzadaNunca tengas miedo de plantearle 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 que son críticas para el éxito ágil sean conscientes de las prioridades, preferencias y limitaciones de la organización y estén dirigidas por ellas.
Trozos durosEncontrar un equilibrio entre los requisitos empresariales y la interferencia con la libertad de diseño y enfoque requerida. Esto es especialmente cierto para arquitectos con experiencia en desarrollo. La experiencia en la materia crea un terreno resbaladizo que va más allá de las especificaciones empresariales y se adentra en el diseño. Esto conduce a una arquitectura deficiente y de gran envergadura.
Los arquitectos empresariales que apoyan la entrega de proyectos y soluciones deben prever la limitación de los sprints. Los arquitectos que se centran en un ecosistema o plataforma de producto también deben prever la colaboración con los equipos ágiles.
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: Proporcionar criterios de aceptación obligatorios aplicables al final de las epopeyas y antes del lanzamiento. Hemos utilizado con frecuencia Patrones de arquitectura de aplicaciones y Patrones de arquitectura de datos Crear criterios de aceptación. Incluir criterios de aceptación obligatorios en todos los informes de pruebas.
Trozos durosSaber cuándo aplicar criterios de aceptación obligatorios. Si se aplican demasiado pronto, se distorsiona el desarrollo. Si se aplican demasiado tarde, se presiona para que se implementen excepciones. Esto es especialmente cierto en el caso de productos digitales internos que no tienen ciclos de lanzamiento 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 salir del camino y cosechar la creatividad.
Patrón de valores (medidas y puntos de reposo)
Problema predecible:Entender qué se valora y cómo se mide el valor.
AcercarseLa arquitectura empresarial debe definir claramente cómo se describe y mide el valor. Las declaraciones de valor requieren factores críticos de éxito (FCE) y medidas de efectividad (MdE). Asegúrese de que las medidas de valor se incluyan en los informes de producto, épica y lanzamiento.
Trozos durosMuchos profesionales de TI tienen una comprensión limitada del valor. Usan una abreviatura rápida que expresa el valor en términos de algo entregado. El valor es evidente en la entrega.
En un mundo complejo, cualquier cosa que se entregue puede reducir el valor. Un ejemplo claro son las funciones dirigidas a usuarios que no son clientes objetivo. O cuando una unidad de trabajo solicita funciones que simplifican su actividad a expensas del sistema.
Recomendamos encarecidamente las prácticas básicas de Lean y Six-Sigma. Analice la definición y cuantificación del valor. Busque la optimización local. Los conceptos de Cliente Objetivo y Propuesta de Valor del Lienzo de Modelo de Negocio son muy útiles.
Greenfield, evolución o revolución
En Fase E de TOGAF, Hay un paso interesante. Revisa el paquete de trabajo y selecciona una estrategia adecuada: Greenfield, Evolutiva o Revolucionaria. ¿Prevés conservar lo máximo posible, refactorizar radicalmente o empezar desde cero?
Esto se hace en la planificación del portafolio de productos y del ecosistema. Es una guía crucial y una fuerte limitación para un equipo ágil. ¿Les indica que empiecen desde cero (Greenfield)? ¿Mejoran los sistemas existentes gradualmente (evolución)? ¿O implementan un cambio radical que se espera elimine las fricciones y los problemas que hemos estado experimentando (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.
Un bocado duroAlinear los cambios de arquitectura descendentes con la hoja de ruta del producto. Esto se vuelve más difícil cuando las decisiones para apoyar la Estrategia o la Cartera requieren un cambio en el enfoque del producto. Hemos tenido que dedicar mucho tiempo a asegurar a los propietarios de productos digitales, y a través de ellos, a sus equipos, que el esfuerzo previo no fue en vano.
Restringir patrón de interfaz
Cuando un producto debe integrarse en un entorno empresarial existente o dar soporte a un entorno empresarial en evolución, las interfaces son clave. Estas se basarán en datos y métodos. En un mundo complejo, ni siquiera los productos emergentes tendrán la libertad de desarrollar estructuras de datos e interfaces. 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á centrando en nuevos sistemas. Es el nuevo sistema el que debe integrarse. Incluso el F-22 Raptor tuvo que conectarse con sistemas antiguos mediante interfaces desarrolladas en la década de 1970. Ni siquiera un avión tan caro pudo modernizar sus sistemas antiguos.
Problema predecible:Identificar las interfaces necesarias y garantizar su uso.
Acercarse: Centrar el trabajo descendente en las interfaces y las estructuras de datos compartidas. Incorporar los requisitos mediante ciclos de épica y lanzamiento. Utilizar criterios de aceptación. Hemos utilizado con frecuencia Patrones de arquitectura de aplicaciones y Patrones de arquitectura de datos Para interfaces ligeramente específicas. Incluir la conformidad de la interfaz en todos los informes de pruebas.
Un bocado duroLas interfaces son uno de los puntos donde suele ser necesaria una planificación descendente con visión de futuro. Esfuerzo para garantizar una infraestructura de API sólida, API publicadas y estructuras de datos para datos maestros, datos de referencia y registros transaccionales.
Los equipos de producto con un ritmo acelerado suelen pasar por alto la legislación multijurisdiccional o un plan de negocio para un mercado en expansión. En estos casos, el equipo de EA tiene la obligación de anticiparse. Por lo general, nos sentimos más cómodos con una refactorización radical que con la planificación anticipada. Especialmente si hemos reforzado la modularidad y las interfaces.

Arquitectura empresarial y Agile: Resolver la dependencia
Los equipos ágiles y el desarrollo centrado en productos digitales no son adecuados para resolver problemas en un ecosistema o portafolio de productos. El diseño fundamental de la metodología ágil consiste en que un solo equipo desglose los problemas y los resuelva directamente. Existen conceptos de equipo de equipos, pero estos presentan dificultades para adaptarse al contexto 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 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.
Trozos durosEl desafío más crítico es la sincronización. Los equipos de desarrollo ágil creativos, con las mejores prácticas, trabajarán para resolver el problema. Cuando el problema surge, suele ser un obstáculo crítico, con niveles 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 de las partes interesadas reales
Problema predecible:Identificar a la parte interesada real que pueda proporcionar dirección y aprobación en una cartera de productos internos compleja.
AcercarseUtilizar técnicas de arquitectura empresarial para identificar a las partes interesadas y a sus agentes, sus inquietudes y preferencias. Utilizar técnicas de arquitectura empresarial de alternativas y compensación Guiar a las partes interesadas hacia una decisión que dirija la cartera de productos. Garantizar una gobernanza eficaz de la cartera digital.
Trozos durosPodemos esperar que los equipos de productos digitales cuenten con fuentes locales de autoridad y un modelo simplificado de toma y autoridad de decisiones. Además, su comunicación y evaluación estarán orientadas a las TI y serán tácticas.
El equipo de EA deberá trabajar para garantizar una gobernanza eficaz que abarque toda la cartera digital e interactúe con las estructuras de autoridad de los productos digitales. Además, los equipos de EA no tienen una capacidad especial para involucrar a las partes interesadas. Sin embargo, sí tienen la capacidad de representar sus inquietudes mediante una arquitectura superior.
Cruzar el patrón de cartera
Problema predecibleLas decisiones tácticas optimizadas localmente no pueden surgir como un ecosistema digital efectivo y sostenible.
Acercarse:Mantener lo justo Arquitectura de la aplicación y Arquitectura de datos. Priorizar la organización en esa arquitectura. La arquitectura de aplicaciones debe centrarse en servicios e interfaces compartidos. La arquitectura de datos debe centrarse en datos maestros, datos de referencia y datos con alta clasificación de seguridad. Se requieren descripciones de metadatos. Utilizar patrones de arquitectura que especifiquen el enfoque de ecosistemas.
Trozos durosCruzar la cartera requiere conciliar dos realidades contradictorias. En primer lugar, el enfoque ágil surgió debido a la falla observada en el diseño empresarial detallado descendente. 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 justo" significa asegurar la prioridad organizacional y evitar problemas predecibles. Por ejemplo, si la prioridad organizacional es la sostenibilidad, la arquitectura de su aplicación debe garantizar la modularidad y el uso de infraestructura de aislamiento, como una puerta de enlace API.
Lo justo significa no intervenir en el diseño del producto. En su lugar, es necesario utilizar patrones de arquitectura que se apliquen a todo el portafolio.
Lo justo significa ignorar las sinergias potenciales. 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 en hojas de ruta de arquitectura demuestra que siempre se paga la factura, y se puede obtener el beneficio. El valor de la sinergia es bajo cuando se aplica la incertidumbre.
Lo justo significa centrarse en problemas predecibles. Nadie ha creado jamás un maestro de clientes distribuido sin datos de referencia. Jamás. Ese es un problema de datos predecibles. Resuélvalo pronto. Es muy valioso evitar problemas predecibles.
Lo justo significa no tener miedo de usar las fuerzas del mercado y la destrucción creativa. Utilizamos el concepto de ciclo de vida esperado para destacar en qué partes del ecosistema esperamos implementar regularmente una refactorización agresiva (enfoques nuevos y revolucionarios).
Patrón de impacto de liberación
Problema predecible:Una arquitectura suficiente implica que cada contingencia, cada restricción, cada conflicto, no se haya descubierto antes del lanzamiento.
Acercarse: Mete las manos en los bolsillos y espera a que te llamen durante la resolución. A menos que te llamen, espera a participar durante la revisión del incidente para descubrir dónde no identificaste un problema predecible, subestimaste el riesgo o incumpliste con un requisito de prueba.
Trozos durosExiste un caso en el que un equipo de arquitectura podría tener una emergencia. Son esos casos excepcionales en los que las implicaciones se extienden más allá del producto. Si los usuarios finales están solucionando el defecto, no hay una emergencia. Cuando crean vulnerabilidad y responsabilidad, sí hay una emergencia.
Utilice una buena técnica de brecha, paquete de trabajo y punto de reposo de valor. Busque el cambio más pequeño que genere valor aprovechable. En este caso, el valor consiste en 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 aplicación incorrecta crónica. Con demasiada frecuencia, simultáneamente. Ajuste su enfoque para que su metodología ágil y... arquitectura empresarial Los esfuerzos reducen la incertidumbre del éxito.
Como arquitecto empresarial, busque herramientas que le permitan aplicar un enfoque incremental para reducir la probabilidad y el coste de los errores. Al reducir el coste de los esfuerzos de cambio fallidos, elimina el desperdicio. El 100% de sus esfuerzos de cambio desperdiciados reduce el valor del cambio.
La matemática es simple: el beneficio se mantuvo, el trabajo aumentó. El resultado neto es menor.
La respuesta simple es aprovechar tus fortalezas. Y esperar que el equipo ágil aproveche las suyas.
La arquitectura empresarial y ágil tienen cuatro patrones de participación de alto nivel:
- Definiendo el enfoque ágil
- Guiar el backlog en el sprint
- limitando los sprints ágiles
- Resolviendo la dependencia del producto cruzado
La selección del patrón está determinada por su caso de uso de arquitectura empresarial el Diseño de tu equipo EA.
Avanzando con la arquitectura empresarial y la agilidad
Yendo más allá Agilidad Se distingue del desarrollo de software ágil. La arquitectura empresarial y la metodología ágil se complementan en tres áreas:
- Arquitecto de una empresa ágil
- Prácticas de trabajo ágiles para desarrollar una arquitectura empresarial de mejores prácticas
- desarrollo de software ágil y arquitectura empresarial
