La necesidad del manejo de la arquitectura de un sistema de software nace con
los sistemas de mediana o gran envergadura, que se proponen como solución para un
problema determinado.  En la medida que los sistemas de software crecen en
complejidad, bien sea por número de requerimientos o por el impacto de los mismos,
se hace necesario establecer medios para el manejo de esta complejidad (Hofmeister et
al., 1996).  En general, la técnica es descomponer el sistema en piezas que agrupan
aspectos específicos del mismo, producto de un proceso de abstracción (Bass et al.,
1998) y que al organizarse de cierta manera constituyen la base de la solución de un
problema en particular.  
De aquí que la mayoría de los autores (Bass et al., 1998; Kazman et al., 1998;
Hofmeister et al., 1995; Lane, 1990; Buschman et al., 1996; Booch et al., 1999;
Abowd, 1995) coinciden en que una arquitectura de software define la estructura del
sistema.  Esta estructura se constituye de componentes -módulos o piezas de código-
que nacen de la noción de abstracción, cumpliendo funciones específicas, e
interactuando entre sí con un comportamiento definido (Bass et al., 1998; Hayes-Roth,
1995; Hofmeister et al., 2000; Buschman et al., 1996; Booch et al., 1999; Abowd, 95).
Los componentes se organizan de acuerdo a ciertos criterios, que representan
decisiones de diseño.  En este sentido, hay autores que plantean que la arquitectura
de software incluye  justificaciones  referentes a la organización y el tipo de
componentes, garantizando que la configuración resultante satisface los
requerimientos del sistema (Boehm et al., 1995). 7
De esta manera, la arquitectura de software puede ser vista como la estructura
del sistema en función de la definición de los componentes y sus interacciones (Bass et
al., 1998).  La práctica ha demostrado que resulta importante extender el concepto
considerando los requerimientos y restricciones del sistema (Boehm et al., 1995; Lane,
1990), junto a un  argumento  que justifique que la estructura definida satisface los
requerimientos, dándole un sentido más amplio a la definición del término.
La arquitectura de software puede considerarse entonces como el “puente” entre
los  requerimientos  del sistema y la implementación (Hofmeister et al., 2000).  Las
actividades que culminan en la definición de la arquitectura pueden ubicarse en las
fases tempranas del ciclo de desarrollo del sistema: luego del análisis de los
requerimientos y el análisis de riesgos, y justo antes del diseño detallado.  Desde esta
perspectiva, la arquitectura constituye un  artefacto  de la actividad de diseño
(Hofmeister et al., 2000), que servirá de medio de comunicación entre los miembros del
equipo de desarrollo, los clientes y usuarios finales, dado que contempla los aspectos
que interesan a cada uno (Kazman et al., 2001).  Además, pasa a ser la base del diseño
del sistema a desarrollar, razón por la cual en la literatura la arquitectura es
considerada como plan de diseño del sistema (Hofmeister et al., 2000), debido a que es
usada como guía para el resto de las tareas del desarrollo.
De igual manera, serán de particular importancia las propiedades no funcionales
del sistema de software, pues influyen notoriamente en la calidad del mismo. Estas
propiedades tienen un gran impacto en el desarrollo y mantenimiento del sistema, su
operabilidad y el uso que éste haga de los recursos (Buschman et al., 1996).  Entre las
propiedades no funcionales más importantes se encuentran: modificabilidad,
eficiencia, mantenibilidad, interoperabilidad, confiabilidad, reusabilidad y facilidad de
ejecución de pruebas (Kazman et al., 2001).  Bass et al. (1998) proponen que el
término “requerimiento no funcional” es disfuncional, debido a que implica que tal
requerimiento no existe, o que es una especie de requerimiento que puede ser
especificado independientemente del comportamiento del sistema. En este sentido,
Bass indica que debe hacerse referencia a atributos de calidad, en lugar de
propiedades no funcionales.
Puede observarse que al hablar de arquitectura de software, se hace alusión a la
especificación de la estructura del sistema, entendida como la organización de
componentes y relaciones entre ellos; los requerimientos que debe satisfacer el sistema
y las restricciones a las que está sujeto, así como las propiedades no funcionales del
sistema y su impacto sobre la calidad del mismo; las reglas y decisiones de diseño que
gobiernan esta estructura y los argumentos que justifican las decisiones tomadas.
Habiendo aclarado el alcance que puede tomar el término arquitectura de
software, resulta de gran interés introducir formalmente otros términos que resultan
pilares fundamentales dentro del contexto de arquitectura, dado que en torno a ellos
gira gran parte del estudio que hasta el momento se ha realizado sobre el tema.  Tal es
el caso de los componentes, los conectores y las relaciones.

referencia --------> http://www.slideshare.net/jpbthames/diseo-arquitectnico-9443843