El desarrollo \u00e1gil de software sobresale en la creaci\u00f3n de algo que nunca antes hab\u00edamos tenido y que no sab\u00edamos c\u00f3mo construir. Ya es bastante dif\u00edcil construir con \u00e9xito un sistema complejo por segunda vez. Probablemente la primera vez no se logre. Agile reduce el riesgo durante la implementaci\u00f3n. Funciona en incrementos cortos. Se falla, se vuelve a intentar. Y entonces se logra.<\/p>\n
El enfoque \u00e1gil reduce el riesgo al acortar el ciclo de pruebas.<\/p>\n
El papel de un arquitecto empresarial<\/a> Es guiar a las partes interesadas para que encuentren un camino a seguir cuando no se sabe qu\u00e9 hacer. La arquitectura empresarial reduce el riesgo durante el establecimiento de la direcci\u00f3n y la planificaci\u00f3n. Las arquitecturas empresariales miran m\u00e1s all\u00e1 de la agilidad para...\u00a0 comparar cambios potenciales<\/a> al otro lado de dominios de la arquitectura<\/a>.<\/p>\n La arquitectura empresarial est\u00e1 dise\u00f1ada para informar la toma de decisiones y reducir el costo de los esfuerzos de cambio condenados al fracaso.<\/p>\n La arquitectura empresarial y la metodolog\u00eda \u00e1gil reducen el riesgo. La arquitectura se utiliza para reducir el riesgo y los costos antes de comenzar la implementaci\u00f3n. La metodolog\u00eda \u00e1gil reduce el riesgo y los costos despu\u00e9s de comenzar la implementaci\u00f3n.<\/p>\n\t\t\t\n\t\t\t\t\t\t\tM\u00e1s informaci\u00f3n sobre la certificaci\u00f3n TOGAF\n\t\t\t<\/a>\n\t \u00bfC\u00f3mo se combinan la arquitectura empresarial y Agile?<\/a><\/p>\n Arquitectura empresarial y metodolog\u00edas \u00e1giles: defina el enfoque \u00e1gil.<\/a><\/p>\n Arquitectura empresarial y metodolog\u00eda \u00e1gil: Gu\u00eda para el backlog en el sprint<\/a><\/p>\n Arquitectura empresarial y metodolog\u00edas \u00e1giles: Limitar los sprints<\/a><\/p>\n Arquitectura empresarial y metodolog\u00edas \u00e1giles: soluci\u00f3n a las dependencias<\/a><\/p>\n Conclusi\u00f3n sobre arquitectura empresarial y metodolog\u00eda \u00e1gil<\/a><\/p>\n\t\t\t\t La arquitectura empresarial y la metodolog\u00eda \u00e1gil se complementan de maneras inesperadas. El enfoque actual del m\u00e9todo \u00e1gil son los pasos para crear un software de env\u00edo viable. Desde esta perspectiva, la pregunta es: \u00bfqu\u00e9 hace la arquitectura empresarial hoy? \u00bfQu\u00e9 hace para agilizar el software de env\u00edo?<\/p>\n La arquitectura empresarial y la metodolog\u00eda \u00e1gil no encajan dentro del sprint. Se integran fuera del ciclo de desarrollo. Se integran cuando los arquitectos empresariales y los desarrolladores \u00e1giles realizan su trabajo. Los equipos de arquitectura empresarial exitosos cumplen con sus objetivos. caso de uso<\/a>. No cumplen con nada m\u00e1s. Incluso si pudieran.<\/p>\n Contamos con una arquitectura empresarial simple y un modelo de referencia \u00e1gil. Existen cuatro patrones fundamentales de interacci\u00f3n con la arquitectura empresarial:<\/p>\n Durante los \u00faltimos a\u00f1os trabajando en Transformaci\u00f3n digital<\/a> iniciativas, desarrollamos un conjunto de patrones de participaci\u00f3n.<\/p>\n\t\t\t\t <\/p>\n Primero, analiza tu caso de uso de EA. \u00bfQu\u00e9 orientaci\u00f3n se espera que brindes? \u00bfA qui\u00e9nes prestas servicios? Luego, analiza los patrones de participaci\u00f3n que abordan los desaf\u00edos de tu trabajo. Incorp\u00f3ralos a tu participaci\u00f3n.<\/p>\n Nuestra plantilla de patr\u00f3n de arquitectura<\/a> tiene dos elementos clave: el problema predecible<\/em> y el acercarse<\/em> para resolver el problema. Tambi\u00e9n recopilamos la partes duras<\/em>. Cuando consideramos un patr\u00f3n, observamos qu\u00e9 tan bien resuelve el problema y cu\u00e1nto trabajo adicional es necesario para aplicarlo con \u00e9xito.<\/p>\n Analicemos los patrones de interacci\u00f3n. El problema que resuelven, el enfoque y las dificultades.<\/p>\n Tuve una conversaci\u00f3n amena con la ingeniera de confiabilidad de sistemas reci\u00e9n contratada. La especialista en SRE estaba entusiasmada. Por fin hab\u00edamos empezado con pr\u00e1cticas modernas: CI\/CD y pruebas automatizadas. Me pregunt\u00f3 qu\u00e9 estaba haciendo el equipo de EA para ayudar.<\/p>\n Tuve que sonre\u00edr cuando me pregunt\u00f3:\u2018\u00bfQu\u00e9 est\u00e1 haciendo el equipo de EA para ayudar?<\/em>\u2018'Lo que realmente quer\u00eda decir era:'\u2018\u00bfQu\u00e9 est\u00e1s haciendo para apoyarme hoy?<\/em>\u2018'Hoy, en cuanto a sus desaf\u00edos inmediatos, ninguno. Estaba inmersa en la implementaci\u00f3n. Estaba analizando la implementaci\u00f3n.<\/p>\n Ella no entend\u00eda c\u00f3mo se estaba desarrollando la organizaci\u00f3n. No estaba al tanto de la hoja de ruta de la cartera<\/a>. La hoja de ruta ten\u00eda un punto de transici\u00f3n al que acab\u00e1bamos de llegar. Hab\u00edamos incorporado contenedores, gesti\u00f3n de datos de prueba y un conjunto de pruebas automatizadas deficiente. Ella no se dio cuenta de que la planificaci\u00f3n tradicional de arriba hacia abajo hab\u00eda creado las circunstancias para su nuevo trabajo.<\/p>\n Ella pensaba en el desarrollo inmediato. Yo pensaba en todo el... transformaci\u00f3n digital<\/a>. Su funci\u00f3n era ayudar a la organizaci\u00f3n en la siguiente transici\u00f3n. Estaba desarrollando... capacidades cr\u00edticas<\/a>. Las pruebas automatizadas proporcionar\u00edan evidencia de que se estaban siguiendo las restricciones de la arquitectura. Estaba pasando de... Definiendo el enfoque \u00e1gil<\/a>. Necesitaba ayuda Para guiar el atraso<\/a>.<\/p>\n Diez puentes y caminos que los conectan valen m\u00e1s que 500 medios puentes que no llevan a ninguna parte<\/em><\/strong><\/p>\n490 constructores de puentes estar\u00e1n descontentos Agile es una opci\u00f3n. Tiene ventajas y desventajas. Adoptar Agile requiere decisiones sobre el producto, la plataforma, la estrategia de prestaci\u00f3n de servicios y los puntos de transici\u00f3n descendentes.<\/p>\n Un equipo de EA necesita la capacidad de brindar soporte Estrategia<\/a> y Cartera<\/a> a definir el enfoque \u00e1gil.<\/em><\/strong><\/p>\n Problema predecible<\/strong>\u00bfCu\u00e1ndo utilizar Agile?<\/p>\n Los productos externos son m\u00e1s f\u00e1ciles de implementar que los internos. En resumen, existe un mercado. Internamente, el uso de metodolog\u00edas \u00e1giles impulsa el sistema interno hacia productos digitales. Es necesario determinar la existencia, el alcance y el enfoque de desarrollo de los sistemas internos.<\/p>\n Problema predecible<\/strong>\u00bfDe d\u00f3nde viene el producto?<\/p>\n Acercarse<\/strong>: Ajustar la definici\u00f3n de 'soluciones' utilizadas para llenar brechas y resultados de paquetes de trabajo para alinearlos con productos aut\u00f3nomos. Desarrollar una cartera de productos internos y un conjunto de medidas de valor para productos internos. Los productos deben aparecer en la hoja de ruta de arquitectura<\/a>.<\/p>\n Las plataformas pueden mejorar la velocidad y la sostenibilidad del desarrollo. Sin embargo, una plataforma mal elegida tendr\u00e1 el efecto contrario. No es decisi\u00f3n de un equipo \u00e1gil usar una plataforma, y mucho menos elegir cu\u00e1l. Hemos usado el t\u00e9rmino plataforma para referirnos a SAP, M365, Facebook, Pega e incluso OpenShift Containers.<\/p>\n Arquitecturas de referencia<\/a>\u00a0tienen un papel fundamental en la definici\u00f3n, selecci\u00f3n y gobernante<\/a>\u00a0El uso de plataformas.<\/p>\n Problema predecible<\/strong>\u00bfCu\u00e1ndo se debe utilizar una plataforma y cu\u00e1ndo el producto no debe tener restricciones?<\/p>\n Acercarse<\/strong>: Enfoques m\u00faltiples<\/p>\n Trozos duros<\/strong>:Cuesti\u00f3n de soporte y sostenibilidad del producto y la plataforma.<\/p>\n Una estrategia de prestaci\u00f3n 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).<\/p>\n Problema predecible<\/strong>\u00bfC\u00f3mo implementar\u00e1 su organizaci\u00f3n el desarrollo \u00e1gil?<\/p>\n Acercarse<\/strong>: Siga los enfoques de la arquitectura para respaldar la estrategia. Plantee la pregunta de c\u00f3mo se facilitar\u00e1 el desarrollo \u00e1gil. Utilice un Modelo operativo<\/a> para definir valor y un Mapa organizacional<\/a> definir c\u00f3mo trabajar\u00e1n juntos los diferentes consumidores, desarrolladores y operadores de un producto.<\/p>\n El desarrollo \u00e1gil tiene la misma probabilidad que cualquier otro enfoque de saber cu\u00e1ndo detenerse. Los puntos de descanso de valor son sin\u00f3nimo de transiciones de arquitectura. Usamos este t\u00e9rmino para destacar que la parte interesada tiene una v\u00eda de escape y puede dejar de invertir. Las partes interesadas utilizar\u00e1n estas v\u00edas de escape por varias razones:<\/p>\n Problema predecible<\/strong>:Conocer el Valor Punto de Reposo para detenerse o cambiar el enfoque<\/p>\n Acercarse<\/strong>Utilice hojas de ruta de arquitectura para explorar alternativas de entrega de valor. Genere informes sobre la actividad hacia las etapas de transici\u00f3n.<\/p>\n Trozos duros<\/strong>Las 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\u00f3ximo lanzamiento. Los l\u00edderes s\u00e9nior siempre buscan el mejor camino a seguir, no el mayor retorno potencial. Quieren el mejor camino.<\/p>\n Explorar los puntos de equilibrio del valor es el primer paso. Quienes toman las decisiones deben comprender las opciones (selecci\u00f3n basada en diferentes criterios y postergaci\u00f3n de decisiones inciertas). Luego, identificar qu\u00e9 se necesita para alcanzar los diferentes puntos de equilibrio del valor seleccionados.<\/p>\n Buenas pr\u00e1cticas arquitectura empresarial<\/a> de Conexiam Navegar<\/a><\/p>\n\t\t\t\n\t\t\t\t\t\t\tPrograme una formaci\u00f3n personalizada sobre arquitectura empresarial para impulsar su equipo\n\t\t\t<\/a>\n\t Los equipos \u00e1giles s\u00f3lidos encuentran el camino m\u00e1s eficaz hacia adelante. La planificaci\u00f3n y la presupuestaci\u00f3n a largo plazo existen debido a la complejidad del ecosistema. El reto es conectar la planificaci\u00f3n a largo plazo con la creatividad \u00e1gil. Conectar la planificaci\u00f3n descendente con la ejecuci\u00f3n ascendente.<\/p>\n Es necesario informarles sobre las prioridades organizacionales en t\u00e9rminos que puedan incorporarse a la gesti\u00f3n de la cartera de pedidos.<\/p>\n La agilidad existe porque quienes est\u00e1n m\u00e1s cerca de la soluci\u00f3n pueden encontrar el camino m\u00e1s efectivo. Las organizaciones exitosas priorizan y buscan soluciones. Sin alcanzar el futuro deseado con las limitaciones de tiempo y recursos, no se deber\u00eda iniciar ning\u00fan trabajo.<\/p>\n Un equipo de EA necesita la capacidad de brindar soporte Cartera<\/a> y Proyecto a Gu\u00eda del backlog en el sprint<\/em><\/strong>.<\/p>\n Problema predecible<\/strong>:Garantizar que los resultados esperados, el valor, las expectativas de rendimiento en cascada y las limitaciones gu\u00eden el lanzamiento y el desarrollo del producto.<\/p>\n Parte dif\u00edcil<\/strong>Demasiados promotores de la metodolog\u00eda \u00e1gil se sorprenden de que las organizaciones que la adoptan sigan estando profundamente comprometidas con la planificaci\u00f3n y la presupuestaci\u00f3n a largo plazo. A menudo debemos superar la mitolog\u00eda de que existe una preferencia cultural por el m\u00e9todo en cascada.<\/p>\n Problema predecible<\/strong>:Tener una hoja de ruta de producto integral, en lugar de un ciclo de lanzamiento de funciones.<\/p>\n Acercarse<\/strong>:Usando un t\u00e9cnica de hoja de ruta de arquitectura<\/a> Donde el producto o la familia de productos se ubican en el portafolio. Aseg\u00farese de que los informes de productos incluyan la actividad hacia estados de transici\u00f3n.<\/p>\n Trozos duros<\/strong>Una excelente gesti\u00f3n de producto proporcionar\u00e1 una hoja de ruta completa. Muchos propietarios de producto de abajo a arriba carecen de experiencia en la gesti\u00f3n del ciclo de vida o la integraci\u00f3n de una suite de productos integrada. El equipo de EA deber\u00e1 sustituir o sustituir a los dem\u00e1s, seg\u00fan las habilidades de la organizaci\u00f3n del producto.<\/p>\n Demasiados equipos de arquitectura caen en la trampa de la precisi\u00f3n artificial o la omnisciencia imaginaria. Ambas son formas sofisticadas de referirse al pensamiento en cascada. Una hoja de ruta de arquitectura cl\u00e1sica hablar\u00e1 de transiciones, brechas y paquetes de trabajo. Esto resultar\u00e1 incomprensible para un equipo de producto. Cambie el lenguaje a terminolog\u00eda de producto y \u00e1gil. El propietario del producto debe comprender las limitaciones con las que opera.<\/p>\n La elaboraci\u00f3n de la hoja de ruta requiere una arquitectura suficiente. El \u00fanico enfoque escalable es '\u2018S\u00f3lo lo suficiente<\/em>.Lo justo significa imponer prioridades organizacionales y evitar problemas predecibles. Lo justo significa mantenerse al margen del dise\u00f1o del producto. Utilizar patrones de arquitectura que se apliquen en toda la cartera. Lo justo significa ignorar la sinergia potencial. Lo justo significa centrarse en problemas predecibles. El valor de evitar problemas predecibles es alto. Lo justo significa no tener miedo de usar la destrucci\u00f3n creativa. Utilizar un concepto de ciclo de vida esperado para impulsar una refactorizaci\u00f3n agresiva (enfoques de campo nuevo y revolucionarios).<\/p>\n El uso de t\u00e9cnicas con el propietario del producto ayuda a incorporar las prioridades y limitaciones organizacionales a la hoja de ruta del producto.<\/p>\n Problema predecible<\/strong>:Uso de epopeyas para implementar resultados y restricciones de arriba hacia abajo en el producto.<\/p>\n Acercarse<\/strong>:Usando estados de transici\u00f3n bien construidos en un t\u00e9cnica de hoja de ruta de arquitectura<\/a> Donde el producto o la familia de productos se ubican en el portafolio. Aseg\u00farese de que los informes de productos incluyan la actividad hacia estados de transici\u00f3n.<\/p>\n Trozos duros<\/strong>Requiere productos estrechamente integrados o con restricciones estrictas. El enfoque debe centrarse en la integraci\u00f3n o en los puntos de restricci\u00f3n. Un ejemplo sencillo es la coexistencia de m\u00faltiples productos dentro de un ecosistema y el intercambio de datos de referencia.<\/p>\n Es com\u00fan caer en la trampa del dise\u00f1o inicial. El enfoque debe centrarse en las \u00e1reas donde los desarrolladores de software deben limitar su creatividad debido al ecosistema o a requisitos externos. Idealmente, esto deber\u00eda hacerse desde el principio, en lugar de como una reacci\u00f3n a la deuda t\u00e9cnica.<\/p>\n Cuando logramos este objetivo, adoptamos activamente el lenguaje de m\u00e9todos como SaFE y enmarcamos la hoja de ruta en t\u00e9rminos de temas estrat\u00e9gicos y pautas de arquitectura.<\/p>\n Problema predecible<\/strong>:Asegurarse de que los factores cr\u00edticos de \u00e9xito incluidos en los estados de transici\u00f3n y objetivo gu\u00eden la preparaci\u00f3n del backlog \u00e1gil y la planificaci\u00f3n \u00e9pica.<\/p>\n Acercarse<\/strong>: Traducir las medidas y objetivos descendentes en criterios consumibles para la gesti\u00f3n \u00e1gil del backlog. Asegurar que los informes peri\u00f3dicos del producto incluyan la selecci\u00f3n y finalizaci\u00f3n de actividades para alcanzar el valor establecido.<\/p>\n Trozos duros<\/strong>Las medidas descendentes deben ser definitivas y f\u00e1ciles de evaluar. Por ejemplo, no se puede pedir al equipo \u00e1gil que desarrolle un equilibrio matizado entre el tiempo de comercializaci\u00f3n y la resiliencia. Se requiere una terminolog\u00eda inequ\u00edvoca.<\/p>\n Cualquier cambio en las medidas descendentes generar\u00e1 confusi\u00f3n, especialmente si se ha alcanzado una etapa de transici\u00f3n.<\/p>\n Para los productos internos, siempre nos aseguramos de contar con un modelo de costos s\u00f3lido para los productos digitales antes de implementar medidas de costos. Sin un modelo de costos, se perder\u00e1n los costos operativos y de plataforma, y todos los costos se justificar\u00e1n en funci\u00f3n del costo de implementaci\u00f3n. Planifique ayudar al gerente de producto interno con... Entendiendo ITFM<\/a>. Por el contrario, los gerentes de productos de productos digitales externos normalmente tienen una comprensi\u00f3n muy s\u00f3lida del costo.<\/p>\n Problema predecible<\/strong>:Propietarios de productos que ven toda la empresa a trav\u00e9s de la lente de su producto y sus usuarios directos.<\/p>\n Acercarse<\/strong>Documentar el producto y su rol dentro del ecosistema. Documentar las restricciones aplicables al producto. Documentar los criterios de evaluaci\u00f3n. Asegurar que los informes habituales del producto incluyan el progreso hacia las etapas de transici\u00f3n y la actividad alineada con el valor empresarial.<\/p>\n Trozos duros<\/strong>Los propietarios de productos digitales internos suelen ser un punto d\u00e9bil. Los desaf\u00edos comunes incluyen no comprender:<\/p>\n Los equipos de arquitectura empresarial que dan soporte a la cartera y a los proyectos son los que probablemente necesiten limitar a los propietarios de productos que trabajan desde la base. Esto requiere un esfuerzo deliberado y la asignaci\u00f3n de personal.<\/p>\n Estamos pasando de ayudar a un equipo \u00e1gil a gestionar su parte posterior a profundizar en el sprint. Aqu\u00ed debemos integrar las especificaciones de la arquitectura en el software. Debemos hacerlo sin interferir en la creatividad ni la innovaci\u00f3n del equipo \u00e1gil.<\/p>\n Toda especificaci\u00f3n de arquitectura elimina cierto grado de libertad. Al limitar su libertad, dificultamos que el equipo \u00e1gil encuentre la ruta m\u00e1s eficiente. Cuando las limitaciones impulsan las prioridades empresariales, facilitamos la b\u00fasqueda del mejor camino.<\/p>\n Problema predecible<\/strong>:Garantizar que las decisiones durante el sprint que son cr\u00edticas para el \u00e9xito \u00e1gil sean conscientes de las prioridades, preferencias y limitaciones de la organizaci\u00f3n y est\u00e9n dirigidas por ellas.<\/p>\n Trozos duros<\/strong>Encontrar un equilibrio entre los requisitos empresariales y la interferencia con la libertad de dise\u00f1o 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\u00e1s all\u00e1 de las especificaciones empresariales y se adentra en el dise\u00f1o. Esto conduce a una arquitectura deficiente y de gran envergadura.<\/p>\n Los arquitectos empresariales que apoyan la entrega de proyectos y soluciones deben prever la limitaci\u00f3n de los sprints. Los arquitectos que se centran en un ecosistema o plataforma de producto tambi\u00e9n deben prever la colaboraci\u00f3n con los equipos \u00e1giles.<\/p>\n Problema predecible<\/strong>:Garantizar que el software se ajuste a las especificaciones y est\u00e1ndares de la arquitectura empresarial.<\/p>\n Acercarse<\/strong>: Proporcionar criterios de aceptaci\u00f3n obligatorios aplicables al final de las epopeyas y antes del lanzamiento. Hemos utilizado con frecuencia Patrones de arquitectura de aplicaciones<\/a> y Patrones de arquitectura de datos<\/a> Crear criterios de aceptaci\u00f3n. Incluir criterios de aceptaci\u00f3n obligatorios en todos los informes de pruebas.<\/p>\n Trozos duros<\/strong>Saber cu\u00e1ndo aplicar criterios de aceptaci\u00f3n 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.<\/p>\n Clasificamos nuestras especificaciones de arquitectura como:<\/p>\n La mayor\u00eda de los criterios de aceptaci\u00f3n obligatorios deben ser patrones o est\u00e1ndares de arquitectura.<\/p>\n Nunca olvides salir del camino y cosechar la creatividad.<\/p>\n Problema predecible<\/strong>:Entender qu\u00e9 se valora y c\u00f3mo se mide el valor.<\/p>\n Acercarse<\/strong>La arquitectura empresarial debe definir claramente c\u00f3mo se describe y mide el valor. Las declaraciones de valor requieren factores cr\u00edticos de \u00e9xito (FCE) y medidas de efectividad (MdE). Aseg\u00farese de que las medidas de valor se incluyan en los informes de producto, \u00e9pica y lanzamiento.<\/p>\n Trozos duros<\/strong>Muchos profesionales de TI tienen una comprensi\u00f3n limitada del valor. Usan una abreviatura r\u00e1pida que expresa el valor en t\u00e9rminos de algo entregado. El valor es evidente en la entrega.<\/p>\n 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.<\/p>\n Recomendamos encarecidamente la aplicaci\u00f3n de las pr\u00e1cticas b\u00e1sicas de Lean y Six Sigma. Analice la definici\u00f3n y cuantificaci\u00f3n del valor. Busque la optimizaci\u00f3n local. Los conceptos de Cliente Objetivo y Propuesta de Valor del Business Model Canvas resultan muy \u00fatiles.<\/p>\n En Fase E de TOGAF<\/a>, Hay un paso importante. Analiza el paquete de trabajo y selecciona la estrategia adecuada: Greenfield, Evolutiva o Revolucionaria. \u00bfPretendes conservar la mayor cantidad de elementos posible, refactorizar radicalmente o empezar desde cero?<\/p>\n Esto se hace en la planificaci\u00f3n del portafolio de productos y del ecosistema. Es una gu\u00eda crucial y una fuerte limitaci\u00f3n para un equipo \u00e1gil. \u00bfLes indica que empiecen desde cero (Greenfield)? \u00bfMejoran los sistemas existentes gradualmente (evoluci\u00f3n)? \u00bfO implementan un cambio radical que se espera elimine las fricciones y los problemas que hemos estado experimentando (Revolucionario)?<\/p>\n Problema predecible<\/strong>:Garantizar que se siga la estrategia de implementaci\u00f3n.<\/p>\n Acercarse<\/strong>:Utilice la hoja de ruta del producto y los ciclos de lanzamiento para imponer cambios radicales en el enfoque.<\/p>\n Un bocado duro<\/strong>Alinear los cambios de arquitectura descendentes con la hoja de ruta del producto. Esto se vuelve m\u00e1s dif\u00edcil 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\u00e9s de ellos, a sus equipos, que el esfuerzo previo no fue en vano.<\/p>\n Cuando un producto debe integrarse en un entorno empresarial existente o dar soporte a un entorno empresarial en evoluci\u00f3n, las interfaces son clave. Estas se basar\u00e1n en datos y m\u00e9todos. En un mundo complejo, ni siquiera los productos emergentes tendr\u00e1n la libertad de desarrollar estructuras de datos e interfaces. Los datos maestros, los datos de referencia y los sistemas existentes limitar\u00e1n el desarrollo \u00e1gil.<\/p>\n Los sistemas existentes no van a cambiar. La inversi\u00f3n se est\u00e1 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\u00e9cada de 1970. Ni siquiera un avi\u00f3n tan caro pudo modernizar sus sistemas antiguos.<\/p>\n Problema predecible<\/strong>:Identificar las interfaces necesarias y garantizar su uso.<\/p>\n Acercarse<\/strong>: Centrar el trabajo descendente en las interfaces y las estructuras de datos compartidas. Incorporar los requisitos mediante ciclos de \u00e9pica y lanzamiento. Utilizar criterios de aceptaci\u00f3n. Hemos utilizado con frecuencia Patrones de arquitectura de aplicaciones<\/a> y Patrones de arquitectura de datos<\/a> Para interfaces ligeramente espec\u00edficas. Incluir la conformidad de la interfaz en todos los informes de pruebas.<\/p>\n Un bocado duro<\/strong>Las interfaces son uno de los puntos donde suele ser necesaria una planificaci\u00f3n descendente con visi\u00f3n de futuro. Esfuerzo para garantizar una infraestructura de API s\u00f3lida, API publicadas y estructuras de datos para datos maestros, datos de referencia y registros transaccionales.<\/p>\n Los equipos de producto con un ritmo acelerado suelen pasar por alto la legislaci\u00f3n multijurisdiccional o un plan de negocio para un mercado en expansi\u00f3n. En estos casos, el equipo de EA tiene la obligaci\u00f3n de anticiparse. Por lo general, nos sentimos m\u00e1s c\u00f3modos con una refactorizaci\u00f3n radical que con la planificaci\u00f3n anticipada. Especialmente si hemos reforzado la modularidad y las interfaces.<\/p>\n Los equipos \u00e1giles y el desarrollo centrado en productos digitales no son adecuados para resolver problemas en un ecosistema o portafolio de productos. El dise\u00f1o fundamental de la metodolog\u00eda \u00e1gil 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.<\/p>\n Cualquier equipo de arquitectura debe asumir la responsabilidad de resolver problemas entre productos. El desarrollo \u00e1gil y la integraci\u00f3n moderna hacen que este servicio sea m\u00e1s importante que nunca.<\/p>\n Problema predecible<\/strong>:El conflicto en la cartera de productos digitales bloquea el progreso de m\u00faltiples productos.<\/p>\n Acercarse<\/strong>:Utilice t\u00e9cnicas de arquitectura empresarial para encontrar los cambios m\u00ednimos que permitan el progreso.<\/p>\n Trozos duros<\/strong>El desaf\u00edo m\u00e1s cr\u00edtico es la sincronizaci\u00f3n. Los equipos de desarrollo \u00e1gil creativos, con las mejores pr\u00e1cticas, trabajar\u00e1n para resolver el problema. Cuando el problema surge, suele ser un obst\u00e1culo cr\u00edtico, con niveles de deuda t\u00e9cnica.<\/p>\n El equipo de EA deber\u00e1 centrarse en estados de transici\u00f3n incrementales para permitir el progreso en toda la cartera de productos.<\/p>\n Problema predecible<\/strong>:Identificar a la parte interesada real que pueda proporcionar direcci\u00f3n y aprobaci\u00f3n en una cartera de productos internos compleja.<\/p>\n Acercarse<\/strong>Utilizar t\u00e9cnicas de arquitectura empresarial para identificar a las partes interesadas y a sus agentes, sus inquietudes y preferencias. Utilizar t\u00e9cnicas de arquitectura empresarial de alternativas<\/a> y compensaci\u00f3n<\/a> Guiar a las partes interesadas hacia una decisi\u00f3n que dirija la cartera de productos. Garantizar una gobernanza eficaz de la cartera digital.<\/p>\n Trozos duros<\/strong>Podemos esperar que los equipos de productos digitales cuenten con fuentes locales de autoridad y un modelo simplificado de toma y autoridad de decisiones. Adem\u00e1s, su comunicaci\u00f3n y evaluaci\u00f3n estar\u00e1n orientadas a las TI y ser\u00e1n t\u00e1cticas.<\/p>\n El equipo de Arquitectura Empresarial (EA) deber\u00e1 trabajar para garantizar una gobernanza eficaz en todo el portafolio digital e interactuar con las estructuras de autoridad de productos digitales. Asimismo, los equipos de EA no tienen una capacidad especial para lograr la participaci\u00f3n de las partes interesadas. Sin embargo, s\u00ed tienen la capacidad de representar las inquietudes de las partes interesadas mediante una arquitectura superior.<\/p>\n Problema predecible<\/strong>Las decisiones t\u00e1cticas optimizadas localmente no pueden surgir como un ecosistema digital efectivo y sostenible.<\/p>\n Acercarse<\/strong>:Mantener lo justo Arquitectura de la aplicaci\u00f3n<\/a> y Arquitectura de datos<\/a>. Priorizar la organizaci\u00f3n 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\u00f3n de seguridad. Se requieren descripciones de metadatos. Utilizar patrones de arquitectura que especifiquen el enfoque de ecosistemas.<\/p>\n Trozos duros<\/strong>Cruzar la cartera requiere conciliar dos realidades contradictorias. En primer lugar, el enfoque \u00e1gil surgi\u00f3 debido a la falla observada en el dise\u00f1o empresarial detallado descendente. En segundo lugar, las soluciones emergentes optimizadas localmente no pueden construir sistemas complejos eficientes sin una fuerte presi\u00f3n evolutiva y tiempo para evolucionar.<\/p>\n El \u00fanico enfoque escalable es '\u2018S\u00f3lo lo suficiente<\/em>.\u2019Lo justo\u00bb significa priorizar las necesidades de la organizaci\u00f3n y evitar problemas previsibles. Por ejemplo, si la prioridad de su organizaci\u00f3n es la sostenibilidad, la arquitectura de su aplicaci\u00f3n debe priorizar la modularidad y el uso de infraestructura de aislamiento, como una puerta de enlace API.<\/p>\n Lo justo significa no intervenir en el dise\u00f1o del producto. En su lugar, es necesario utilizar patrones de arquitectura que se apliquen a todo el portafolio.<\/p>\n Lo justo significa ignorar las sinergias potenciales. Es com\u00fan que los esfuerzos por imaginar un futuro complejo se conviertan en una farsa. La sinergia es lo m\u00e1s dif\u00edcil 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.<\/p>\n Lo justo significa centrarse en problemas predecibles. Nadie ha creado jam\u00e1s un maestro de clientes distribuido sin datos de referencia. Jam\u00e1s. Ese es un problema de datos predecibles. Resu\u00e9lvalo pronto. Es muy valioso evitar problemas predecibles.<\/p>\n Lo justo significa no tener miedo de usar las fuerzas del mercado y la destrucci\u00f3n creativa. Utilizamos el concepto de ciclo de vida esperado para destacar en qu\u00e9 partes del ecosistema esperamos implementar regularmente una refactorizaci\u00f3n agresiva (enfoques nuevos y revolucionarios).<\/p>\n Problema predecible<\/strong>:Una arquitectura suficiente implica que cada contingencia, cada restricci\u00f3n, cada conflicto, no se haya descubierto antes del lanzamiento.<\/p>\n Acercarse<\/strong>: Mete las manos en los bolsillos y espera a que te llamen durante la resoluci\u00f3n. A menos que te llamen, espera a participar durante la revisi\u00f3n del incidente para descubrir d\u00f3nde no identificaste un problema predecible, subestimaste el riesgo o incumpliste con un requisito de prueba.<\/p>\n Trozos duros<\/strong>Existe un caso en el que un equipo de arquitectura podr\u00eda enfrentarse a una emergencia: esos casos excepcionales en los que las implicaciones van m\u00e1s all\u00e1 del producto. Si los usuarios finales encuentran una soluci\u00f3n alternativa al defecto, no hay emergencia. Cuando generan vulnerabilidad y responsabilidad, s\u00ed la hay.<\/p>\nComprender la arquitectura empresarial y Agile<\/h2>\n
\n
![\"arquitectura](\"https:\/\/conexiam.com\/wp-content\/uploads\/2023\/09\/AdobeStock_437654262.jpeg\" "\\"arquitectura")
\n\t\t\t\n\t\t\t\t\t\t\tCont\u00e1ctenos para que nuestra consultor\u00eda de arquitectura empresarial le ayude.\n\t\t\t<\/a>\n\t\u00bfC\u00f3mo se combinan la arquitectura empresarial y Agile?<\/h2>\n
\n
![\"Arquitectura](\"https:\/\/conexiam.com\/wp-content\/uploads\/2020\/05\/EA-supporting-Agile-Development-Work-Product-600x408.png\" "\\"Arquitectura")
\n\t\u00bfC\u00f3mo utilizar estos patrones de compromiso?<\/h2>\n
\n
Ejemplo pr\u00e1ctico: Desarrollo \u00e1gil en la hoja de ruta de la arquitectura empresarial<\/strong><\/h3>\n
\n
\n<\/em><\/strong>490 constructores de puentes que cre\u00edan que estaban aportando valor<\/em><\/strong>\n
\n\t\t\t\n\t\t\t\t\t\t\tFormaci\u00f3n en arquitectura empresarial personalizada para impulsar su equipo\n\t\t\t<\/a>\n\tDescargas de arquitectura empresarial y ejemplos de arquitectura empresarial<\/a><\/h2>\n\t
Arquitectura empresarial y metodolog\u00edas \u00e1giles: defina el enfoque \u00e1gil.<\/h2>\n
Patr\u00f3n de producto<\/h3>\n
Patr\u00f3n de plataforma<\/h3>\n
\n
\n
Patr\u00f3n de estrategia de prestaci\u00f3n de servicios<\/h3>\n
Patr\u00f3n de punto de reposo de valor mayor<\/h3>\n
\n
\n
\nEsta es una conversaci\u00f3n sobre el retorno de la inversi\u00f3n (ROI). Las conversaciones sobre el ROI suelen conducir a un cambio de prioridad.<\/li>\n\n
\n
Vaya m\u00e1s all\u00e1 con el Proceso y M\u00e9todo de Arquitectura Empresarial de Mejores Pr\u00e1cticas<\/h2>\n
Arquitectura empresarial y metodolog\u00eda \u00e1gil: Gu\u00eda para el backlog en el sprint<\/h2>\n
Hoja de ruta para guiar el patr\u00f3n del producto<\/h3>\n
\n
\n
Hoja de ruta para guiar el patr\u00f3n \u00e9pico<\/h3>\n
Patr\u00f3n de valor empresarial<\/h3>\n
Restringir el patr\u00f3n de propietario del producto "de abajo hacia arriba"<\/h3>\n
\n
\n
![\"Arquitectura](\"https:\/\/conexiam.com\/wp-content\/uploads\/2020\/05\/EA-supporting-Agile-Development-Work-Product.png\" "\\"Comprender")
<\/p>\n\t\t\t\n\t\t\t\t\t\t\tDescargue la Gu\u00eda pr\u00e1ctica para el desarrollo de una arquitectura empresarial\n\t\t\t<\/a>\n\tFormaci\u00f3n en arquitectura empresarial y TOGAF<\/h2>\n\t
Arquitectura empresarial y metodolog\u00edas \u00e1giles: Limitar los sprints<\/h2>\n
\nHay una regla b\u00e1sica<\/strong><\/em>: nunca elimines un grado de libertad si no es necesario.
\nLa libertad para innovar y crear es el elemento vital del desarrollo de software \u00e1gil.<\/em>\nHay una regla avanzada<\/strong>Nunca tengas miedo de plantearle a un equipo \u00e1gil un problema realmente dif\u00edcil.
\nLa innovaci\u00f3n y la creatividad crear\u00e1n soluciones que no puedes imaginar.<\/em>\n
\nPatr\u00f3n de criterios de aceptaci\u00f3n<\/h3>\n
\n
\n
Patr\u00f3n de valores (medidas y puntos de reposo)<\/h3>\n
Greenfield, evoluci\u00f3n o revoluci\u00f3n<\/a><\/h3>\n
Restringir patr\u00f3n de interfaz<\/h3>\n
<\/p>\n\t\t\t\n\t\t\t\t\t\t\tDescargue la Gu\u00eda de gobernanza de la arquitectura empresarial\n\t\t\t<\/a>\n\tArquitectura empresarial y metodolog\u00edas \u00e1giles: soluci\u00f3n a las dependencias<\/h2>\n
Desbloquear el patr\u00f3n de cartera<\/h3>\n
Identificar el patr\u00f3n de las partes interesadas reales<\/h3>\n
Cruzar el patr\u00f3n de cartera<\/h3>\n
Patr\u00f3n de impacto de liberaci\u00f3n<\/h3>\n