Yo estaba poniendo al día algunos e-mail esta tarde y me di cuenta de un hilo iniciado por Steve Godbold acerca de las posibles soluciones de compromiso entre los métodos ágiles de desarrollo de software y arquitectura/ modelado de sistemas/empresa. Es una pregunta interesante y probablemente merece un poco de debate.
¿Qué es el desarrollo ágil de software?
La mayoría de los desarrolladores en estos días dicen que práctica de algún tipo de desarrollo de software ágil. Hay un buen número de métodos diferentes a cabo allí, pero el común entre ellos es la entrega incremental de valor dentro de un modelo de desarrollo iterativo (aunque algunos métodos tienen iteraciones tan pequeñas que podría ser considerado un flujo constante de valor).
En muchos sentidos, la definición de desarrollo ágil de software se conoce bastante bien, mientras que los detalles de implementación a menudo se discuten.
¿Qué es la arquitectura de la empresa?
Arquitectura empresarial podría definirse como la relación entre los diversos sistemas de información de apoyo dentro de una organización y una comprensión de cómo se integran con los procesos de negocio y la estrategia general del negocio de una organización. Cualquier persona que habla de un sistema específico, sin una visión global de cómo ese sistema se ajusta dentro de la organización es a lo mejor práctica de la arquitectura de sistemas, pero ciertamente no la arquitectura empresarial.
¿Qué es la arquitectura de los sistemas/aplicación?
Los sistemas, o arquitectura de aplicación es un enfoque más local para los esfuerzos de la arquitectura. Se define el diseño ideal de una pieza de software, dados los requisitos funcionales y no funcionales. Por ejemplo, una aplicación que requiere coherencia inmediata en todas las transacciones puede ser que necesite evitar algunas de las opciones de persistencia NoSQL por ahí – es todo sobre las ventajas y desventajas específicas de la aplicación que tienen que hacerse.
¡Todo es acerca del valor!
Los métodos ágiles, arquitectura empresarial, arquitectura de aplicación/sistemas todos existen para entregar valor al negocio. Los métodos ágiles entregan valor al reducir el riesgo de fracaso del proyecto mediante la entrega de valor en las pequeñas piezas adicionales.
Arquitectura de aplicación/sistemas define el panorama general de cómo la aplicación se unificara y es bueno «domesticar» el diseño emergente que consigues a menudo en proyectos de desarrollo ágil. Yo no iría en un proyecto sin una idea razonable de cómo las piezas del sistema se van a integrar entre sí y determinar qué aspectos técnicos del sistema son peligrosos y deben ser sobrecargadas.
La arquitectura empresarial es realmente un juego en una capa diferente de una organización. Un buen arquitecto empresarial va a estar profundamente integrado con las unidades de negocio y saber cuáles son sus retos actuales y tener un plan sobre cómo esas cuestiones van a ser resueltas a través del tiempo. Empuja algunas restricciones de diseño en los proyectos ágiles, definiendo qué tipo de interacciones el nuevo sistema debe apoyar – el valor que aporta es la visión a más largo plazo.
Fangosas aguas de la empresa y la arquitectura de sistemas.
En mi experiencia muchas organizaciones confunden la arquitectura de sistemas y empresa, y tienden a colapsar en un única rol. Si estás en este tipo de papel tienes que trabajar duro para no convertir cada sistema en un microcosmos de la arquitectura de la empresa en general y en el proceso completo complicar el problema en cuestión. Esto amenaza la capacidad de ambas disciplinas para ofrecer valor y completamente puede descarrilar un equipo ágil.
Arquitectos de empresa son pollos, arquitectos de sistemas son cerdos!
¿Todos están enfermos aun de la analogía de pollos y cerdos? Los arquitectos de sistemas realmente necesitan estar involucrados hasta el final de un proyecto de desarrollo de software. En el camino de la arquitectura serán desafiados y es posible que tenga que evolucionar rápidamente en su lugar. Los arquitectos de la empresa no necesariamente tienen que hacer esto porque su influencia es realmente ejercida sobre los requisitos funcionales del sistema a desarrollar.
Consideraciones finales
He visto grandes entregas de enfoques arquitectónicos que fallan con los equipos de desarrollo ágil en el que no pueden manejar efectivamente su deuda técnica gracias a una arquitectura inapropiada (sólo porque lo llaman una arquitectura no significa que sea correcta, y la mejor manera de probar una arquitectura es empezar a probarlo con la construcción en su contra). En cambio he visto los equipos de desarrollo ágil producir montones de basura, simplemente porque no tenían una visión de alto nivel de cómo el sistema se unificaría.
Los mejores equipos de desarrollo ágil tratan la arquitectura de sistemas como un elemento de evolución donde se sabe más o menos en qué dirección va, pero mantener la aplicación abierta para el cambio y esto es lo que aporta valor a la organización y permite a los arquitectos de la empresa poder evolucionar los sistemas globales de la empresa con más facilidad.
