Ir al contenido principal

¿Qué es la Arquitectura de Software?




La Arquitectura es una palabra cuyo origen etimológico sugiere que se usaba en la antigua Grecia para referirse a aquellos expertos que lideraban la construcción de importantes obras. El significado descrito se refiere principalmente a las edificaciones, obras de Ingeniería Civil que  no pareciera tener alguna relación con los sistemas informáticos.
Debido a la relativa novedad del concepto, es común que muchos Arquitectos no sepan cómo describir adecuadamente lo que hacen y el valor que tienen para una empresa. Existen, en realidad, bastas definiciones e incluso clasificaciones donde la Arquitectura de Software es sólo una parte de un conglomerado de conceptos que se relacionan entre sí.

Las siguientes son, a mi parecer, las principales definiciones otorgadas por organizaciones influyentes en el campo tecnológico:

1.    SEI: El Instituto de Ingeniería de Software, uno de los principales referentes de la Ingeniería, describe la Arquitectura desde un punto de vista práctico. Señalando que es la representación de un sistema de software, sus elementos y relaciones, que ayuda a comprender cómo éste se comportará y cómo se podrá diseñar e implementar. La Arquitectura además se encarga de garantizar los atributos de calidad o cualidades del sistema.
Adicional a lo anterior, varios miembros investigadores de renombre que hacen parte del SEI como Paul Clements, exponen constantemente la importancia de la Arquitectura como un producto de trabajo o entregable, desarrollado con una cuidadosa disciplina de documentación a través de puntos de vistas Arquitecturales.
Para profundizar acerca de estos conceptos, el siguiente es el link de acceso principal a todos los recursos de la Arquitectura de Software a través del SEI, si bien, la mayoría de estos artículos y documentos son de pago, es posible sacarle bastante provecho y espero más adelante discutirlos en otro artículo:
http://www.sei.cmu.edu/architecture/start/?wt.ac=swaGettingStarted

2.     IASA: La Asociación Internacional de Arquitectura de Software, la considera como parte de 4 especializaciones para afrontar la Arquitectura Empresarial, a saber: Arquitectura de Negocio, Arquitectura de Infraestructura y Arquitectura de Información. Si bien la IASA contempla la existencia de la Arquitectura de T.I y la define como el arte y la ciencia de diseñar y entregar estrategias de tecnología valiosas para una organización, esta definición puede extenderse  a cualquiera de las especializaciones considerando, además, el valor que cada una representa. Adicional a lo anterior, relaciona cada tipo de Arquitectura a través de 4 pilares fundamentes del conocimiento para abarcar completamente su definición, estas se pueden considerar como un conjunto de conceptos y habilidades que definen lo que cada Arquitectura hace y significa para una Compañía. Estas son: Estrategias tecnológicas del negocio, Entorno de la tecnología de la información, Atributos de Calidad, Diseño y Dinámica Humana.

3.     TOGAF: The Open Group Architecture FrameWork, es un marco de trabajo para lograr construir adecuadamente la Arquitectura Empresarial. Al Igual que la IASA, TOGAF modela la Arquitectura Empresarial a través de 4 distintos niveles; Arquitectura de Negocio, Arquitectura de Aplicaciones, Arquitectura de Datos y Arquitectura Tecnológica o de Solución, siendo esta última una dimensión que contiene la Arquitectura de Software como parte del diseño para la implantación de aplicaciones críticas para el negocio.
Dentro de la Arquitectura de solución se describen herramientas, métodos y estándares para el diseño e implementación de las aplicaciones, y se describe formalmente como la estructura y las relaciones en hardware y software que constituye la solución (una aplicación nueva o existente que hace parte de un inventario tecnológico valorable) desde una vista global y alineado a los objetivos del negocio y de cada una de las dimensiones de Arquitectura que lo definen.

Luego de repasar estas definiciones, personalmente he extraído de todas las siguientes características en común:

-       Construcción de importantes obras (tecnológicas)
-       Representa el total de las partes del sistema, sus relaciones y características
-       Objetivos del negocio
-       Alineación con la Arquitectura Empresarial
-       Arquitectura vs diseño
-       Atributos de calidad

De esta forma, cada vez que me piden una definición de la Arquitectura de Software la resumo así:

Representa la relación de cada una de las partes que conforma un sistema de software y su entorno tecnológico, haciendo clara sus responsabilidades y características. Se encarga de que dichas partes, reconocibles como elementos arquitecturales, estén acordes a ciertas metas alienadas con los objetivos del negocio. 

De lo anterior es importante resaltar que los elementos arquitecturales son todas aquellas partes del sistema que se rescatan para ser representados por un Arquitecto a través algún punto de vista, que son visibles para cualquiera que quiera entender y estudiar la Arquitectura. Dichos elementos se relacionan con otros, tienen responsabilidades, características y se representan a través de una nomenclatura estándar. Las metas se definen principalmente como objetivos medibles y alcanzables, estas deben ser los atributos de calidad.
Por otro lado, los objetivos del negocio son cruciales para definir las metas en la Arquitectura, estos objetivos son valorables

Espero que esta breve introducción a la Arquitectura de Software, ayude a todos los que empiezan a entender cuál es mundo al que se van a enfrentar y comprendan el valor que representan como estrategas tecnológicos de la compañía para la que trabajan.

Comentarios

  1. Interesante definicion Osca, la comparto, tambienme gusta la definicion de Simon Brown en su Libro Software architecture for developer

    ResponderEliminar

Publicar un comentario

Comenta, pregunta u orienta constructivamente.

Entradas populares de este blog

Proceso para la creación de la Arquitectura

Hoy quiero contarles acerca de un modelo que he adoptado para la construcción y entrega de la Arquitectura de Software, el cual lo he relacionado con éxito al interior de la compañía para la cual trabajo y que considero, bien puede adaptarse a cualquier tipo de especialidad de la Arquitectura Empresarial. Cuando era desarrollador escuchaba hablar constantemente acerca de varias metodologías de desarrollo. Durante mucho tiempo apliqué RUP, XP y metodologías AGILES, usé PSP y TSP como procesos de desarrollo. Pero durante todo ese tiempo nunca oí hablar de metodologías orientadas a la generación de la Arquitectura de Software, aún luego de comenzar a estudiar y al día de hoy he tenido muy pocas referencias. Quiero aclarar que existen varios modelos y  frameworks bastante conocidos para la Arquitectura Empresarial que son confrontados a profundidad en unas entregas muy completas de Microsoft, estas pueden estudiarse en este link . Pues bien, el método al que me refiero es ACDM, ...

Expandir espacio en disco duro en Virtual Box y con Partition Logic

Cuando nos quedamos sin espacio en nuestra máquina virtual, tenemos problemas para seguir usándola adecuadamente. Los siguientes son  los pasos que seguí para aumentar el espacio en disco duro, para la unidad principal de una máquina virtual de Windows XP instalada en mi Mac Book.  Probé una herramienta llamada Partition Logic   y, debido a que no la conocía, decidí documentarlo. Tenía asignadas 5GB a la unidad donde está instalado el sistema operativo, y se veía así: Mi máquina, con 5GB de tamaño en disco duro. 1. Redimensionar la unidad vdi. el siguiente es el comando que realiza toda la magia en VirtualBox: VBoxManage modifyhd "ruta/unidad.vdi" --resize [tamaño] En mi caso aumenté el tamaño a 20GB. VBoxManage modifyhd "/Users/oscar/VirtualBox VMs/WindowsXP/WindowsXPClone.vdi" --resize 20000 Como anotación,  debí clonar la unidad, pues había creado el disco de tamaño fijo en Virtual Box y no me permitía aumentarlo (generaba error...

Atributos de Calidad

¿Qué son los Atributos de Calidad? Los Arquitectos debemos participar en el entendimiento de las necesidades de los usuarios. Sí, esa es nuestra principal responsabilidad.  En mi experiencia he debido iniciar con leer términos de referencia para aplicar a licitaciones públicas y privadas y luego acompañar al equipo de análisis en el levantamiento de requerimientos. Los usuarios finales, a excepción de algunos muy técnicos, hablarán en el lenguaje del negocio, de otros sistemas que conocen, de lo que hace la competencia, de lo que otro proveedor les contó, de lo que alguno de sus más influyentes operarios conoce o del patrón de trabajo que ejecutan a diario. Muy pocas veces nos dirán exactamente lo que quieren y por eso debemos estar presentes; debemos ayudar a traducir esos relatos prosaicos de necesidades a requerimientos técnicos.  Los requerimientos técnicos se dividen principalmente en 2: los funcionales (functional requirements) y los no funcionales (Non-functi...