¡Arquitectura, cada cosa en su lugar!!

El término de arquitectura abarca temas de Solución, Software, Hardware y Datos, por lo que solo me enfocare a describir a nivel general el área de arquitectura de Software. (Aquí solamente la llamaré Arquitectura para abreviar)

Dentro de las primeras etapas (según UP – “elaboration”) la labor del equipo de proyecto se enfoca a determinar la estructura base de desarrollo, dicha estructura deberá de alinearse a las características de calidad esperada por el usuario (stakeholders)

Durante la recopilación de requerimientos a través de crear un equipo multidisciplinario para que se vayan clasificando y revisando su viabilidad y tipos de los requerimientos, los arquitectos toman vital relevancia para identificar los QoS (Quality of Service) que conformarán al sistema, así como orientar al usuario sobre su pedido y sus prioridades.

Requerimientos Arquitectónicos

Es muy cierto que el usuario deberá de indicar las prioridades sobre sus requerimientos funcionales, sin embargo estos están supeditados a las prioridades arquitectónicas del sistema, por lo que hay que explicarle como será construido y por qué se necesitan las capas y niveles (tiers & leyers) que se están proponiendo (en caso de desarrollo nuevo).

Además que la arquitectura base nos proporcionará los lineamientos de diseño y programación a seguir tales como conectividad a DB, uso de colas o mensajería, Temporizadores, seguimiento/ Monitoreo, manejo de excepciones, seguridad entre otros…

Se sugiere que todo requerimiento no funcional (transversal - horizontal), se sugiere se documente de manera independientemente a la funcionalidad (Especificaciones suplementario, o complementario), ello permitirá que sea manejable y eliminará la redundancia en las especificaciones funcionales.

Por ejemplo las actividades de seguimiento (loggeo de datos de usuario), es muy común que los embeban en cada especificación funcional y que cuando son trabajadas por equipos separados, estamos propensos a duplicar implementación y esfuerzo para resolverlo

Que son las capas (tiers)

Son las divisiones lógicas o físicas que se establecen en un sistema y que se encuentran delimitadas por su responsabilidad, en estas podemos encontrar las siguientes capas:

  • Cliente
  • Presentación
  • Negocio
  • Integración
  • Recursos
  • Los Niveles (Layers)

    Son las divisiones que son establecidos en base a la plataforma utilizada y servicios de soporte que se proveen para el sistema funcione correctamente, estas capas son:

  • Aplicación
  • Plataforma Virtual
  • Infraestructura de la Aplicación
  • Servicios Empresariales
  • Cómputo y almacenamiento
  • Infraestructura de red
  • Las capas (tiers) son las que más están relacionadas con los programadores 
    ya que estás demarcarán la mecánica y lineamientos tanto de diseño como de programación; 
    los “layers” se darán como estándares a seguir por los programadores una 
    vez que estén estipulados.
    

    Ahora bien establecer la arquitectura no es tan simple como decir, ha! quiero una aplicación web y listo nos vamos directo algún FrameWork de desarrollo como “Struts” o “Spring” o posible “Seam”, combinados con Hibarnate, Ibatis, JPA entre otros tantos que hay en el mercado. Pero antes de elegir uno de ellos hay que verificar muchos aspectos tales como:

  • Tipo de proyecto
  • Experiencia de los recursos (costo)
  • Curva de aprendizaje
  • Herramientas de soporte (IDE´s)
  • Versiones actuales
  • Tipo de uso (intranet, extranet o internet o bien combinados)
  • Pero principalmente conocer las características de servicio, de aquí vamos a poder asegurar que en efecto deberá de ser una aplicación web y que se desarrollara con tal FgrameWork; anticiparte a las decisiones tecnológicas antes de revisar dichas características puede costar mucho $$$ y tiempo.

    En caso que no exista nada definido por el cliente (no tiene infraestructura de hardware/comunicaciones), pues hay que hacer un Análisis de costo beneficio y presentar mínimo 2 a 3 opciones (esto conlleva un proyecto totalmente por separado a nivel de arquitectura de solución, hardware, software y datos)

    Lo más simple es que el cliente ya cuente con cierto stack de aplicaciones y solo hay que alinearse, estableciendo entonces los “tiers” trabajando con los frameworks que se cuenta o promoviendo alguno compatible.

    Posterior a que se definió la arquitectura base, el Arquitecto o Líder técnico tiene la responsabilidad de verificar el cumplimiento tanto por el diseño como la construcción (supervisar el apego de los lineamientos, recomendado realizarlo cuando se lleve avances del 60-70 % de la implementación, en cada iteración), para ello existen diversas mecánicas de revisiones (en pares, peer review, informales, automatizadas como el Jtest entre otros..) lo importante es que se supervise que se esté implementando de manera correcta, además el arquitecto deberá de estar disponible para consultas, dudas y capacitando al equipo de programadores (el Arquitecto se vuelve el mentor del equipo).

    Es bastante gratificante cuando trabajas con arquitecturas bases y te proporcionan los lineamientos a seguir (diseño e codificación), ayuda a trabajar con mayor orden y eficiencia en el proyecto.

    Les dejo una presentación de la metodología de SUNTONE donde muestra un poco más de detalle sobre la parte de Arquitectura.

    Y para quienes quieran hondar aún más en eso de la Arquitectura, les pongo un libro del año del 2004, un poco desactualizado, pero los primeros capítulos me parecieron muy interesantes

    Comentarios

    Opciones de visualización de comentarios

    Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
    Imagen de jiturbide

    De acuerdo en todo excepto en este punto

    Es muy cierto que el usuario deberá de indicar las prioridades sobre sus requerimientos funcionales, sin embargo estos están supeditados a las prioridades arquitectónicas del sistema.

    Los Requerimientos Funcionales no dependen de los No Funcionales. Los funcionales son ¿Que debe hacer el sistema? los No Funcionales ¿El Como o Que tan bien?
    Si el cumplir con un RF se complica se debe explorar las opciones que hay, analizar las ventajas o desventajas y elegir la mas adecuada.

    Si se deja fuera una necesidad del sistema, entonces se crea un sistema incompleto.

    Saludos

    Imagen de Israel-69

    No es eliminar funcionalidad sino darle prioridad

    Gracias por tu comentario

    En el caso de las funcionalidades dependerán de la estructura arquitectónica que se provea, sino de otra manera funcionarán ineficientemente y terminarán por ser abandonado por el usuario o simplemente indicará que no funciona el sistema.

    La dependencia no es hacía que no ses puedan realizar la funcionalidades, sino en que lugar quedarán y bajo que contexto (sus niveles de servicio).

    Es cierto que hay que evaluar las opciones que cumplan con los QoS requeridos por el sistema, pero hay ocasiones que no se pueden proveer todos al mismo tiempo, hay que equilibrar los niveles de servicio así como la priorización de las funcionalidades, el objetivo es coordinan los equipos de trabajo para proveer entregables de valor para el cliente en el menor tiempo posible

    Supongamos que el cliente le urge un reporte de costos y pretende posteriormente ir automatizando el proceso para agilizarlo, pero actualmente no existe las funcionalidades en un sistema para la captura de entradas ni salidas, las conciliaciones o la información de cuentas por pagar, gastos entre otros datos. entonces hay que priorizar y ver como van a proveerse dichos datos tal que permitan lograr el reporte deseado.

    Tampoco se trata de construir todas las funcionalidades que preceden al reporte, sino estipular el mecanismo de entrada que permita lograr el objetivo y que posteriormente ir automatizando el proceso o crear dichas funciones que le den mayor calidad al servicio.

    El arquitecto prioriza las funcionalidades mínimas para alcanzar el objetivo además de estipular la estructura base, equilibrando los niveles de servicio requeridos y buscar que la arquitectura sea lo suficiente flexible para después incorporar funcionalidades necesarias así como mejorar la calidad de los servicios.

    saludos

    Imagen de jiturbide

    Re: No es eliminar funcionalidad sino darle prioridad

    En el caso de que ya tengas una estructura existente, pues no hay de otra, el requerimiento funcional se debe realizar con lo que hay, sin que afecte los niveles de servicio ni principios de arquitectura definidos.

    Pero si hablamos de Arquitectura estamos hablando de organizacion, estructura, soluciones pensadas, no de bomberazos, entonces si el requerimiento realmente es importante habra que ampliar las capacidades de la arquitectura existente para que soporte ese requerimiento.

    Al inicio del post mencionaste algo que es cierto, la arquitectura no solo es sofware abarca Negocio, Datos, Aplicaciones y Tecnologia. Sun Tone es una buena herramienta para la Arquitectura Tecnologia pero es pobre para las otras 3.

    ¿Que es lo que usas para especificar la Arquitectura de Negocio, Datos y Aplicaciones?

    En mi caso estoy iniciando con TOGAF que es un marco de referencia, me gustaria saber que experiencias tienen otros colegas con esta u otras metodologias.

    Saludos

    Imagen de Israel-69

    En mi caso me ha ayudado

    En mi caso me ha ayudado mucho Zachman, tiene un framework, muy simple y directo para determinar las cosas, los niveles de abstracción muy importante para lograr una buena arquitectura (tanto de Negocio como de Aplicaciones)

    Mi percepción de la Arquitectura (Negocio y Aplicaciones) se fundamenta en ubicación de Responsabilidades y la colaboración a sus diferentes niveles aplicando el concepto de encapsulación se logran muy buenas cosas; En caso especial de la Arquitectura de aplicaciones establecer capas (tiers) en base el tipo de proyecto y utilizando patrones como los que menciona Martin Fowler ayuda bastante alinear y mejorar la calidad de los entregables.

    En el caso de Arquitectura de Soluciones y Datos ahí si me declaro neófito, normalmente me apoyo de compañeros que conocen mas del tema para lograr una propuesta integral al cliente.