Arquitecto de aplicaciones

Hace un par de meses me incorporé a un programa que se estaba llevando a cabo en una dependencia del gobierno federal. Este programa era mediando, teniendo un promedio de 80 personas (entre analistas, desarrolladores, líderes y el gerente) en el mismo para llevar a cabo alrededor de 12 proyecto. Se me asignó como Arquitecto de aplicaciones.

Uno de mis primeros retos fue definir: ¿cuales son las responsabilidades del arquitecto de aplicaciones? Parecería sencillo, es quien debe definir “la arquitectura” de las aplicaciones de acuerdo al conocimiento general pero el arquitecto va un poco más allá. Dejarlo en solo está definición sería como pretender que su símil de construcción, el Arquitecto, solo se dedica a hacer planos. Entrega los documentos y se da por finalizado su trabajo. En algunos casos puede ser así, pero no se debe acotar el rol a solo estas funciones. El arquitecto en la construcción gestiona el proceso de construcción en base a los planos, verifica el seguimiento de los lineamientos que estableció y establece medidas en caso de desviaciones. Lo mismo para el arquitecto de aplicaciones, debe definir las políticas, lineamientos, estándares de cómo se “construirá” el software, pero también debe definir los procesos de operación, revisión, control y calidad para asegurar el cumplimiento de estos elementos y enfocado en favorecer la creación de un producto de calidad. Un Arquitecto, es por lo tanto, un Líder Técnico. Hay que establecer que el Líder de proyecto, project manager o PM, debe seguir las buenas prácticas del PM Book, el cual es agnóstico al área de aplicación. Aunque el PM puede tener conocimientos técnicos, muchas veces requiere apoyarse en un rol más experimentado en el área antes mencionada, esto es, el Líder Técnico. El PM ejecuta los procesos de administración de proyectos, independientes del proceso de desarrollo y los procesos de soporte al mismo (control de cambios, accesos, seguridad, control de versiones, etc). y el Líder Técnico quien si ve estos procesos propios del desarrollo.

En base a esto, me di a la labor de identificar la situación actual de los proyecto del programa y mis hallazgos fueron:

• Lineamientos y políticas vagas, poco detalladas, estructura no homologada y no difundidas.
• Falta de control de los ambientes y las herramientas.
• Procesos no definidos para revisión y promoción de las aplicaciones.
• Modelos de datos heterogéneos.

Lo que procedí a hacer fue:

1. Definir los puntos de control más importantes a realizar sobre el proceso de desarrollo (el cual estaba basado en MAAGTIC). Por ejemplo, uno de los entregables del proceso de desarrollo es el documento de detalle de casos de uso, el cual era generado de acuerdo a la experiencia y conocimiento de cada analista teniendo a la larga multitud de estilos y formas.
2. A partir de los puntos de control, definir que se esperaba (guías) y como se iba a revisar (listas de verificación). Siguiendo con el ejemplo: Procedí a crear una guía de documentación de casos y un checklist de revisión a fin de homologar su desarrollo y minimizar la curva de entendimiento de parte de los desarrolladores (aumentando la  calidad de su construcción) al aplicar buenas prácticas y recomendaciones. Esto incluyó:
1. Descripción de la arquitectura de la aplicación en capas.
2. Marcos de trabajo (Spring, JSF, PrimeFaces, entre otros).
3. Dependencias.
4. Estándares de nomenclatura.
5. Guías de diseño de IU.
6. Herramientas.
3. Definir las herramientas y procesos de revisión de calidad de la aplicación:
1. Revisión de código: FindBugs.
2. Pruebas de stress: JMeter, LoadTest.
4. Definir los procesos de promoción de una aplicación, desde desarrollo hasta producción. Estos estaban soportados por las guías y listas de revisión.
5. Definir los procesos de administración de las herramientas y los ambientes para controlar las configuraciones y cambios en los mismos, lo cual impactaba en las entregas finales al cliente.
6. Definir las políticas de bases de datos. Desde la administración de usuarios, creación de esquemas, guías de nomenclatura y manejo de tablespaces (se empleaba Oracle 11g).
7. Definir y estandarizar los formatos de manuales técnicos, permitiendo contar con un documento, para cada proyecto, mejor estructurado, completo y útil.
8. Definir un procedimiento integral de despliegue de las aplicaciones resultantes de los 12 proyectos en lo que denomine “paquete de aplicación” consistente de un WAR, Script de BD y  Manual técnico.

Este no fue un proceso de un día para otro, tomo alrededor de un mes la definición, puesta en marcha, adopción y uso de estos elementos.

De aqui que como Arquitecto de Aplicaciones puedo compartir que:

• Debe definir el como se deben construir las aplicaciones.
• Definir el como se controlará y validará la calidad de los construido.
• Definir las herramientas a emplear, tanto para construir, probar y publicar.
• Definir los procesos de operación y soporte al proceso de desarrollo asociados con las herramientas, ambientes, promoción.