¿Por que la importancia de la Arquitectura?
La complejidad en el desarrollo de sistemas empresariales donde hay requerimientos de alta disponibilidad, de integración, componentes distribuidos y seguridad ha ocasionado que sea necesario contar con un desarrollador de software experimentado en la combinación de las tecnologías adecuadas para lograr que un sistema con estas características sea exitoso y cumpla así los objetivos del sistema.
¿Qué es Arquitectura?
Es la especificación de la estructura de un sistema para soportar correctamente su operación.
Metas de la arquitectura
- Reducir los riesgos tecnológicos del proyecto asociados a sistemas de gran escala
- Diseñar los componentes de software que soporten la operación del sistema y cumplan con los requerimientos no funcionales
- Facilitar el diseño, implementación y despliegue de la aplicación.
¿Qué es un Arquitecto de Software?
Una persona como cualquiera de nosotros que cuenta con suficiente experiencia para poder proponer soluciones. Contrario a lo que podríamos pensar, un Arquitecto no es un gurú del desarrollo, no se centra en detalles de codificación y no tiene porque conocer los detalles codificación de todos los frameworks conocidos. El Arquitecto debe conocer cómo funcionan las diferentes opciones tecnológicas, sus ventajas y desventajas para poder proponer una o varias alternativas de solución que normalmente deben sujetarse a restricciones de presupuesto, tiempo y recursos. La elección debe ser cuidadosa ya que uno de sus objetivos es tratar de eliminar los riesgos del desarrollo sistema y garantizar la operación del sistema una vez liberado. Los proyectos siempre tienen variantes o requieren de ciertos frameworks que nunca habíamos utilizado, por ello también el Arquitecto debe saber investigar y entender rápidamente cómo funciona la tecnología.
Actividades del Arquitecto
El insumo de un Analista Funcional de Sistemas son los requerimientos de Negocio y Funcionales para encontrar ¿Qué funcionalidad debe proporcionar el sistema?. El insumo de un Arquitecto son los Requerimientos No Funcionales y las Restricciones Iniciales para determinar ¿Cómo debe ser construido el sistema para soportar tal funcionalidad?.
El Arquitecto al igual que el Analista de Sistemas debe realizar actividades de Análisis, Diseño y Construcción con la diferencia que su objetivo son los Requerimientos No Funcionales del Sistema, todo aquello que determina como debe funcionar el sistema.
¿Cómo proponer una solución?
El Arquitecto obtiene los requerimientos iniciales, las restricciones, los supuestos, identifica riesgos, analiza la información y formula una o varias propuestas de solución tomando en cuenta todo lo anterior. Dentro de la solución no elige un framework porque es el favorito del Arquitecto, no elige el lenguaje de desarrollo porque quiere aprenderlo o porque es el de moda, los elementos que conforman la solución deben elegidos de forma adecuada para que en conjunto cumplan con los requerimientos no funcionales y las restricciones de tiempo, costo y recursos.
¿Cuál es el resultado de las actividades de análisis de un Arquitecto?
El resultado es un entregable al que llamo en este artículo: Documento de Arquitectura, este documento puede tener diferentes nombres dependiendo de la metodología y de la empresa: Documento de Arquitectura (Vision Consulting), Service Level Agreement (SLA), TCH100 (GNP) etc.
Las siguientes son algunas de las actividades que debe realizar el Arquitecto para poder proponer una solución de Arquitectura.
Obtención y Análisis de Requerimientos
Requerimientos de Negocio
Al igual que el Analista Funcional, el arquitecto debe identificar y conocer cuáles son los objetivos de negocio que motivan el desarrollo del sistema. Esto permitirá proponer la solución más adecuada en función de estos objetivos y evitar cualquier desviación.
Requerimientos No Funcionales
Los Requerimientos No Funcionales (NFRs) son los niveles de servicio y restricciones que el sistema debe cumplir, cuando un cliente es experimentado puede definirlas por el mismo, en otras ocasiones es el arquitecto quien debe ayudar a identificarlas.
En el Documento de Arquitectura el listado de Requerimientos No funcionales puede ir en una tabla como la siguiente escritas con palabras propias del cliente.
| Clave | Descripción |
| NFR01 | Descripción del Requerimiento No Funcional |
| NFR 02 |
Cualidades Sistémicas
Las cualidades sistémicas están definidas por Sun Microsystems de la siguiente manera:
Manifiestas u obvias para el usuario
- Desempeño (Performance) – Que tan rápido el sistema debe cumplir la petición.
- Confiabilidad (Reliability) – El sistema debe ser exacto.
- Disponibilidad (Availability) – Cantidad de tiempo en línea en el que el sistema puede procesar solicitudes. (De hecho el tema es más complejo)
- Usabilidad (Usability) – Que tan fácil es usar el sistema.
Cualidades operacionales que están ligadas al sistema en ejecución
- Rendimiento de trabajo (Throughput) – Cantidad de trabajo hecho por el sistema medido en operaciones por unidad de tiempo.
- Posibilidad de ser Administrado (Manageability).
- Seguridad (Security) – Prevención de uso no autorizado del sistema y su información.
- Serviceabilidad (Serviceability) – Esfuerso necesario para actualizar o reparar el sistema.
- Facilidad de hacer pruebas (Testeability) – Esfuerzo requerido para identificar y aislar una falla en el sistema.
- Escalabilidad (Scalability) – Capacidad de crecer y mantener buenos niveles de operación ante un incremento en el número de usuarios o peticiones.
- Mantenibilidad (Maintainability) – Que tan susceptible es de ser corregido o reparado.
- Extensibilidad (Extensibility) – Posibilidad de agregar funcionalidad nueva.
- Flexibilidad (Flexibility) – Costo de implementar una corrección o una funcionalidad nueva.
- Reusabilidad (Reusability) – Esfuerzo ahorrado apoyándose en componentes existentes
- Portabilidad (Portability) – Esfuerzo ahorrado cuando se migra a una infraestructura diferente.
Cualidades de Desarrollo que afectan como se está construyendo
- Realizabilidad (Realizabilidad) – Probabilidad o confianza en que el sistema puede desarrollarse, se ve reflejado en la facilidad de estimación, planeación y construcción.
- Planeabilidad (Serviceability) – Confianza en que el sistema puede ser planeado en costo y esfuerzo.
Las cualidades sistémicas identificadas se listan y priorizan en un listado como el siguiente:
| QoS | Prioridad | Descripción del Requerimiento | Propuesta para cubrir el requerimiento |
| Disponibilidad | Alta | El sistema no debe quedar fuera de línea en las horas pico o dentro de la ventana de servicio. | Opción 1: Se propone escalar el sistema con XX Memoria RAM y mover las aplicaciones existentes a otro servidor con menos recursos Opción 2: Se propone el uso de 2 servidores YYY y 1 balanceador de carga. |
| Seguridad | Alta | ||
| Tiempos de Respuesta | Alto | Ver tabla anexa |
Tiempos de respuesta esperados (Ejemplo)
| Tipo operación | Respuesta en Hora Promedio | Respuesta en Hora Pico | Volumen promedio de datos | Accesos concurrentes, (prom. futuro.) | Latencia detectada hacia Server | Latencia detectada hacia BD |
| Escritura | ¿? | ¿? | 50k | 825 | Por probar | Por probar |
| Lectura | ¿? | ¿? | 50k | 300 | Por probar | Por probar |
| Reportes | ¿? | ¿? | 50k | 300 | Por probar | Por probar |
| General | 1seg | 5seg | 50k | 300 | Por probar | Por probar |
Características operacionales
| Característica | Operaciones del Sistema Detectadas | Descripción |
| Transaccional | *Asignación del folio *Calculo de número de referencia | Se desarrollarán los componentes de negocio con EJBs Los demás componentes de negocio se desarrollarán con POJOs para poder llegar a los tiempos de respuesta solicitados. |
| Concurrencia | * Registro de un solicitante * Consulta de reportes * Configuración de procesos de registro | |
Restricciones
Todo proyecto tiene restricciones, las más comunes son tiempo, recursos, presupuesto y tecnología a utilizar. El arquitecto debe proponer alternativas de solución que se muevan dentro de estas restricciones. En algunos casos será necesario sacrificar una buena opción porque no cumple alguna de estas.
Es muy importante documentar las restricciones iniciales del proyecto y a lo largo del desarrollo documentar los cambios sobre estas restricciones. Al final del proyecto es común que alguien sin contexto cuestione: ¿Por qué se hizo de esta manera? La respuesta puede estar en las restricciones iniciales y los cambios a lo largo del proyecto.
Suposiciones
Al inicio del proyecto no siempre tenemos toda la información necesaria para poder plantar una propuesta, incluso el cliente puede no tenerla. Esta incertidumbre puede hacer que dudemos en proponer una solución porque no sabemos qué implicaciones puede tener ese faltante de información, pero por otro lado no podemos quedarnos inmóviles a esperar a que se defina ese faltante, esto puede resultar en la pérdida de un posible cliente. Ante estos casos se deben hacer supuestos y actuar en base a estos. Cuando por ejemplo se hace una propuesta estos supuestos se deben notificar a todos los involucrados y denotar que cierta solución es válida bajo ciertas consideraciones.
Ejemplo. El cliente no tiene idea de cuantos reportes se tienen que generar en el sistema.
Supuesto: Se realiza una propuesta suponiendo que solamente se requerirán 100 horas de construcción de reportes.
Riesgos
El manejo de riesgos es un tema importante en la administración de proyectos y de igual forma para la Actividad de Arquitectura. Unos de los objetivos de la arquitectura es precisamente disminuir los riesgos tecnológicos.
La idea es identificar todos aquellas situaciones que pueden poner en riesgo el éxito del proyecto dentro de las restricciones de tiempo y presupuesto, crear un plan de mitigación y de contingencia en caso de que se de el problema.
| Riesgo | Descripción | Probabilidad | Impacto | Plan de mitigación |
| Ejemplo: Diferente comportamiento entre el ambiente de desarrollo y de producción | El ambiente de desarrollo es Windows y el de Producción es UNIX puede haber problemas de ambientación | ALTA / MEDIA / BAJA | ALTO / MEDIO / BAJO | * Desarrollar en maquinas virtuales * Realizar deploys y revisiones periódicas del sistema en el ambiente AIX |
| Ejemplo: El cliente propone el uso de un framework web open source que no ha sido probado en el servidor final | La especificación dice que el servidor de aplicaciones que adquirirá el cliente cumple con le especificación XXX y el framework necesita de esa especificación para poder funcionar. Hay una probabilidad de que el framework no funcione correctamente | BAJA | ALTO | RESUELTO Se realizaron pruebas de operaciones complejas con el framework usando la misma versión y sistema operativo del servidor de aplicaciones. |
| Ejemplo: Tiempos de respuesta arriba del valor requerido | Se está solicitando el tener tiempos de respuesta de máximo 5 segundos para operaciones de consulta en horario pico Dada la configuración de topología red donde se tiene … … | MEDIO | ALTO Es un criterio de aceptación para la liberación | Se deben hacer pruebas de desempeño en el servidor de pruebas usando los mismos elementos de hardware e identificar posibles cuellos de botella fuera de la aplicación |
Esta tabla es un ejemplo y nos ayuda a identificar y prepararnos para saber que debe hacerse en caso de que se presente un problema previamente identificado.
Esta lista de riesgos debe actualizarse y mantenerse durante todo el desarrollo del proyecto
Sizing y Planeación de la Capacidad
Dentro de este rubro se puede mencionar la medición del crecimiento de espacio en disco por elementos propios de la aplicación, información tales como archivos o datos de la base de datos o número de peticiones de clientes considerando cifras iniciales y a futuro.
Esta recolección de cifras ayudará a determinar qué tipo y cantidad de hardware es necesaria para soportar la operación del sistema en un horizonte de tiempo dado.
Numero de Accesos
| Operaciones más demandantes | Accesos concurrentes Iníciales, Horario Pico (Operaciones / min) | Accesos concurrentes Iníciales, Horario No Pico (Operaciones / min) | Accesos concurrentes Futuros, Horario Pico (Operaciones / min) | Accesos concurrentes Futuros, Horario No Pico (Operaciones / min) |
| Registro de X | 750 | 200 | 825 | 220 |
| Consulta de reportes | 300 | 50 | 330 | 55 |
| Configuración de catalogos | - | - | 330 A 1 año | 55 A 1 año |
Crecimiento de espacio en Disco Duro
Descripción del archivo | Tipo de Archivo | Cantidad inicial (6 meses) MB | Tamaño al final del año (MB) | Porcentaje semestral | Periodicidad |
| EARs, Wars de la aplicación | Aplicación | ||||
| Archivos | Archivos | ||||
| Base de datos | Base de Datos | ||||
| Log | Archivo de texto | ||||
| Esquema de Base de Datos | Esquema | ||||
| Total |
Crecimiento de la base de datos
| Tabla | Tamaño inicial en registros (primeros 6 meses) | Incremento semestral (% o núm) | Operación | |||||
Consulta | Actualización | |||||||
| Nombre | Oper | Frec | % o núm. | Oper | Frec | % o núm. | ||
| CSI_AREA | 13 | 0% | S | DIA | 525 | ----- | ----- | 0 |
| CSI_COLONIA | 91500 | 0% | S | DIA | 525 | ----- | ----- | 0 |
| CSI_DEPENDENCIA | 30 | 0% | S | DIA | 525 | ----- | ----- | 0 |
| CSI_ESTADO | 32 | 0% | S | DIA | 525 | ----- | ----- | 0 |
Propuesta de Solución (Diseño)
Tipo de SistemaSe debe especificar qué tipo de sistema se desarrollará.
- Cliente / Servidor
- Multicapa
- Multicapa web
Diagrama de Capas y Filas
Este diagrama es un artefacto de la metodología Sun Tone Methodology, muestra la tecnología a utilizar en cada una de las capas del sistema y por cada capa define niveles de productos que participan en la solución. Cada una de las tecnologías elegidas da solución a los requerimientos detectados en la fase de Análisis.
Ejemplo: Este es un diagrama de ejemplo, Algunas de las celdas pueden haber sido dadas de inicio por las restricciones tecnológicas del cliente y las otras se llenan con la propuesta tecnológica del Arquitecto
| Capa Nivel | Capa Cliente | Capa de Presentación | Capa de Negocio | Capa Integración o Acceso a Datos | Capa de Recursos |
| API, Framework | *HTML ver. 4.01 *CSS 2.1 *DOM 2 *Javascript *Plugins: *Adobe Reader PDF *Ajax Prototipe | Presentación: *Web Components JSP1.2, Servlet 2.5, *Struts 1.3 *JSE 6.0 Reportes: *Jasper Reports *JFree Chart Utilerias: *apache-commons | *POJOs con JSE 6.0 | *Hibernate 3.0 *JSE 6.0 *Webservices con JAX-WS *Correo con apache-mail *Java IO para lectura de archivos *WebServices con AXIS2.0 | BD: *Tablas*No Habra triggers, ni stored procedures |
| Producto | Explorer >=6.0, Mozilla>=2.0 | *JBoss 4.3.2GA con soporte para JEE5.0 *Workflow: jBPM 3.3.2 | *SQL Server 2005 para la BD del sistema (En server 1) | ||
| Sistema Operativo | Cualquiera | *Linux Ubuntu Server 8.04 | *Windows 2003 Server en server 1. | ||
| Hardware | Cualquiera | *Servidor 2: Opteron AMD dual core serie 800 | *Servidor 1: intel xeon 3.2 MHZ | ||
Capa de Cliente: Es la capa donde se ejecuta una aplicación de consola, dispositivo móvil, pc desktop o con navegador web.
Capa de Presentación: Aquí residen los componentes dinámicos de vista y control que generan una salida HTML, XML y los Reportes que se envían al cliente, por ejemplo JSP, Servlets.
Capa de Negocio: Aquí residen los procesos de negocio, workflow, timers.
Capa de Integración: Aquí residen los componentes que permiten la comunicación al exterior tal como componentes de acceso a base de datos, web services, correo, colas de mensajes, clientes de web service, conectores.
Capa de Recursos: Aquí se encuentran todas las fuentes de información externas, tales como Bases de Datos, sistemas de Archivos, Content Managers, Mainframes.
Diagrama de Componentes
El diagrama de componentes inicial es una propuesta de que componentes de software intervendrán en la solución.
Diagrama de Despliegue
El Diagrama de Despliegue inicial nos ayuda a saber con qué otros sistemas interactuarán y convivirá el nuestro dentro.
Prototipo
Provee una demostración o implementación de principio a fin de los componentes tecnológicos primarios, demuestra la viabilidad de la solución y sirve como guía para el desarrollo del sistema.
Estos prototipos pueden ser implementaciones base o presentaciones ppt dependiendo del nivel de cliente para el cual se desea hacer una prueba
Usabilidad
La usabilidad toma en cuenta el tipo de personas que serán usuarios del sistema para proporcionarles una interfaz de usuario que permita hacer productivo su trabajo y por ninguna circunstancia dañe su información. En este sentido es necesario al inicio del proyecto hacer pruebas de usabilidad ya sea con un demo o una presentación que muestre la forma en la que se interactuará con el sistema.
Principios de Diseño a seguir:
- Visibilidad – Claridad en la información a presentar.
- Retroalimentación – Enviar información en respuesta a una acción del usuario.
- Facilidad - Uso de elementos obvios y sencillos para el usuario.
- Simplicidad – Mantener una interfaz simple.
- Estructura – L a interfaz de usuario está dispuesta en una forma lógica y con sentido.
- Consistencia – Uniformidad y la navegación hacen fácil el uso
- Tolerancia – La aplicación debe tolerar los errores de usuario, (uso de confirmaciones, mensajes de error)
Conclusión
Si bien el Arquitecto de Sistemas es una persona experimentada, su responsabilidad no jugar el rol de Analista, Diseñador, Líder de Proyecto y Tester al mismo tiempo, más bien tiene como responsabilidad el asegurar que el sistema sea desarrollado minimizando riesgos tecnológicos y que el sistema una vez liberado opere sin poner en riesgo los objetivos de negocio para los cuales fue creado. Para esto es necesario que aplique su experiencia y buenas prácticas de diseño de sistemas.Así mismo el entregable del Arquitecto no es un "Si" "No" a capricho en la elección de la tecnología a usar. Todo el proceso de análisis, las alternativas de solución y la decisión final deben estar sustentados y plasmados en un Documento de Arquitectura que documente las decisiones de diseño y guie el desarrollo.
Referencias
Software Architecture in Practice http://books.google.com.mx/books?id=mdiIu8Kk1WMC
The J2EE Architect's Handbook
http://www.theserverside.com/tt/books/DVTPress/J2EEArchitectsHandbook/index.tss
Developing Architectures for Enterprise Java Applications (SL-425) Course
http://www.sun.com/training/catalog/courses/SL-425.xml
Sun Tone Methodology
http://rieck.dyndns.org/architecture/suntoneam_wp_5.24.pdf?version=1
