h1

Guia a la arquitectura empresarial y el caso contra Extreme Programming

02/11/2009

Wizbook [Icon By Buuf]

 Libros: Software Engineering.

Incluso la perfecta verificación de un programa sólo puede establecer que cumple con su especificación. […] Mucha de la esencia de construir un programa es de hecho, la depuración de la especificación.

¿Qué es una arquitectura empresarial y qué elementos la componen? Esa es la pregunta que responde el libro A Practical Guide to Enterprise Architecture (Una Guía Práctica a la Arquitectura Empresarial), de James McGovern, et al. Llevándonos de la mano por todos los conceptos de las arquitecturas empresariales – desde la definición de arquitectura y qué se supone que debe hacer un arquitecto, hasta conceptos más avanzados como el Extreme Programming, un SOA o cómo podemos medir la usabilidad de un sistema – este libro posee información que arquitectos, líderes de proyecto, CIOs y CTOs conocen íntimamente o al menos con la que deberían estar familiarizados.

Tal vez este libro no tenga nada de novedoso para los que ya tenemos un buen rato peleándonos con proyectos de software y sistemas, pero para todo aquél que quiera pasar del desarrollo a la definición de arquitecturas, este documento es una fuente indispensable de conocimiento que difícilmente encontraremos consolidada en un sólo libro.

A grandes rasgos, el texto funciona como un repositorio de información de referencia para aquellos conceptos de TI que están enfocados en proyectos de software, incluyendo los siguientes temas:

• 

Qué es una arquitectura empresarial.

• 

Qué elementos componen dicha entidad (procesos, modelos, metodologías).

• 

Qué tipos de arquitecturas existen (monolítica, cliente-servidor, orientada a servicios).

• 

Qué es una metodología; qué metodologías existen (CMM, RUP, XP). Dejando algunos capítulos completos para definir cada una de éstas, su razón de ser y sus principales artefactos.

• 

Cómo modelar una arquitectura (básicamente UML y sus diagramas).

• 

Cómo se define la usabilidad de un sistema.

• 

Cómo se define una arquitectura de datos.

• 

Aspectos organizacionales de una arquitectura empresarial (básicamente, tips para ser un mejor arquitecto).

Dichos conceptos pueden diagramarse en el siguiente esquema, propuesto por los autores:

El pentágono McGovern/Stevens de agilidad arquitectónica.
(fuente: McGovern, et al. A Practical Guide to Enterprise Architecture, 2003)

Así entonces, recomiendo este libro para aquellos que quieran dar un repaso a todos los conceptos que incluye, así como todo aquél curioso que desee echarse un clavado en el mundo de las arquitecturas de software.

Reflexionando

Sin embargo, leyendo el libro me saltaron un par de ideas: aunque el libro pone mucho énfasis en metodologías ágiles de desarrollo de software y aplicaciones web como la neta del planeta, es bueno tomar en cuenta que ni todos los proyectos son web ni las metodologías ágiles son siempre lo mejor. Por experiencia – y esto no sólo lo he comprobado yo, sino algunos de mis compañeros y colegas también – las metodologías ágiles son excepcionalmente buenas para proyectos con pocas personas en el equipo de trabajo, y las metodologías que requieren muchos artefactos (por ejemplo, RUP) tienen mayor cabida en proyectos con muchas personas involucradas.

¿Cómo es eso? El desarrollo de software es un proceso que depende enormemente de la creatividad (de hecho, es el tema central de trabajos como Peopleware: Productive Projects and Teams); las metodologías ágiles explotan esta creatividad en beneficio del proyecto proporcionando a los desarrolladores el empowerment necesario para participar en todo el ciclo de desarrollo: la misma persona levanta el requerimiento con el cliente, arma el demo y va desarrollando la funcionalidad y casos de prueba de acuerdo a lo que ha platicado con el cliente. Sin embargo, esto depende de tres cosas: 1) que las actividades de un desarrollador no impacten las de otro, 2) que el índice de rotación de un proyecto tienda a cero y 3) que el cliente no quiera chamaquearse al desarrollador. Estos supuestos se logran en proyectos pequeños o donde el staff asignado ya tiene relativa experiencia.

Por el contrario, en proyectos grandes con muchas personas involucradas, el tema principal es la coordinación de un ejército de desarrolladores – de los cuales muchos seguramente son de nivel junior – y la extensa y a veces ineludible dependencia entre el trabajo de unos y otros. Si un desarrollador se va, todo puede verse comprometido como un juego de domino. Por ello, al seguir al pie de la letra una metodología intensiva en documentos como RUP, estamos desaprovechando la creatividad de nuestros desarrolladores, pero estamos asegurando que lo que se está negociando con el cliente es lo que se entregará.

Conclusiones y un par de tips

Siendo así las cosas, una buena estrategia al levantar los requerimientos de un proyecto es definir una serie de artefactos de alto nivel: como mínimo, una arquitectura física, una lógica y las narrativas de los casos de uso; y dependiendo del alcance y complejidad del proyecto, podemos seleccionar una metodología específica. Otra estrategia – la que mejor me ha funcionado – es utilizar una metodología mixta, usando artefactos tales como matrices de requerimientos vs. productos y llevando un estricto control de entregables, pero usando constantemente conceptos ágiles como desarrollo iterativo, pruebas de concepto y prototipos que deben ser verificados por el cliente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: