Lectura 1

Tomado de: https://www.scio.com.mx/blog/por-que-es-importante-la-arquitectura-de-

software/

¿Por qué es importante la arquitectura de software?

by damorelos | Sep 3, 2019 | Blog | 1 comment

¿Alguna vez has contemplado un hermoso edificio y te has preguntado: “A

quién se le habría ocurrido diseñar eso”? “El arquitecto debe ser un
visionario”. Bueno, todos hemos sentido eso de una u otra manera. Podemos
relacionarnos más fácilmente con un objeto o un lugar con estructura que
con uno sin forma. Ahora aplica ese mismo pensamiento a la arquitectura de
tu desarrollo de software, y verás una gran similitud en el concepto.

En una era digital en constante evolución que involucra el desarrollo de

software, la programación y todo lo relacionado con la tecnología, ¿cómo se
relacionan la arquitectura y el software? ¿Qué es la arquitectura de software?
Partiendo de la base, el término “arquitectura” se define como la estructura
cuidadosamente diseñada de algo. Sin ella, cualquier persona involucrada en
la creación o desarrollo de un proyecto puede quedar totalmente
desorientado. Por otra parte, el software es la culminación de programas y
otra información operativa utilizada por un ordenador. Estas dos palabras -
arquitectura y software- se relacionan por su función de “estructura” o
“sistema”.
En general, la arquitectura de software es el principio rector general y la
comprensión del sistema, lo que evita que todos los involucrados en el
proyecto se desvíen.

Pero, ¿importa tener una arquitectura de

software bien diseñada?
 Sí, porque reduce los aspectos que los desarrolladores de software necesitan
considerar, dejando más espacio para que el cerebro se centre en la
habilidad de escribir códigos, resolver problemas y otros.

Pídele a cualquier programador que escoja entre crear software desde cero
o mantener uno, y la respuesta que obtendrás será la primera.
Es mucho más fácil crear y desarrollar software cuando se sabe cómo
funciona cada pieza de código escrito y dónde se coloca. Ahorra tiempo al
desarrollador, facilita y acelera su trabajo y aumenta la probabilidad de éxito
del proyecto. El ahorro de costes hace que el trabajo sea más eficiente.
Dicho esto, a continuación, se presentan algunos de los beneficios de
establecer y seguir una buena arquitectura de software:
• La arquitectura del software sirve de guía
• Facilita la depuración del código
• Asegura un entendimiento común del proyecto entre las partes interesadas
• Reduce el riesgo
• Define el límite de la aplicación de Software
• Aumenta la rentabilidad
La arquitectura del software sirve de guía
En términos generales, tener una adecuada y bien definida arquitectura de
software se puede comparar con tener una receta bien escrita. Cualquiera
puede cocinar la misma comida, pero se necesita una buena receta para
crear una obra de arte. Algunos pueden argumentar que todavía se puede
escribir código incluso sin una estructura guía, pero los resultados se pueden
comparar con un huevo revuelto.
Facilita la depuración del código
Imagínate arreglar un bug o buscar un código que necesita ser arreglado. Sin
una estructura definida y un libro de reglas que diga que lo estás haciendo
bien, te sentirás como si estuvieras buscando una aguja en un pajar. Por otra
parte, la arquitectura permite que todo el código sea escrito y compilado de
forma organizada, facilitando la búsqueda de errores o errores.

Asegura un entendimiento común del proyecto

entre las partes interesadas.
Contar con la arquitectura de software cierra la brecha entre los
desarrolladores, las partes interesadas y los demás involucrados en el
proyecto, ya que les permite tener un entendimiento común del proceso.
Esto también representa la implementación de una visión. Hace que todo el
mundo vea el panorama general y hacia dónde se dirige el proyecto de
software. En pocas palabras, asegura que todas las partes interesadas estén
en la misma página.

Reduce el riesgo
Tener una arquitectura de software sólida reduce el riesgo empresarial
asociado a la construcción de una solución técnica. El software debe ser lo
suficientemente flexible para poder manejar la naturaleza cambiante que
ocurrirá en la tecnología de hardware y software con el tiempo. Esto también
significa una mayor adaptabilidad y la capacidad de realizar cambios más
rápidamente.

Define el límite de la aplicación de software

Al establecer los límites de la arquitectura de software, el equipo del proyecto
puede decidir qué funciona en el sistema y qué no funciona. Esto hace que
la arquitectura de software sea más sofisticada, lo que lleva al desarrollo de
un producto único. También minimiza la duplicidad, lo que se traduce en
facilidad de uso y rendimiento. Además, resulta en la alta calidad del
producto y en la priorización de metas. Tener una arquitectura bien pensada
no sólo ayuda a garantizar un alto nivel de rendimiento del sistema, sino que
también proporciona una evaluación más fiable de otros atributos de calidad
del sistema como la seguridad, interoperabilidad, fiabilidad y disponibilidad.

Aumenta la rentabilidad
Una buena arquitectura de software permite la identificación de recursos
redundantes e innecesarios (por ejemplo, el uso de múltiples sistemas de
bases de datos), así como aquellos que pueden ser reutilizados.

Conclusión
La arquitectura de software es el plan maestro del software que se está
desarrollando. Es el guion que dicta los estándares técnicos, que incluyen los
códigos del programa, herramientas y plataformas que se traducen en una
aplicación de software exitosa. Determina cada una de las tareas que deben
realizar los miembros del equipo de proyecto.

Al construir y tener una buena arquitectura para el proyecto de software, uno

puede identificar los riesgos y mitigarlos o abordarlos al principio de la etapa
de desarrollo. Los beneficios de tener una buena arquitectura de software
para su proyecto de desarrollo de software se pueden resumir en cuatro
palabras: mejor, más rápido, económico y más seguro.
 Lectura 2
Tomado de:
Pressman, Roger. "Ingeniería del software: Un enfoque práctico." 7ma
Edición. McGraw Hill, México (2010). Capítulo 9

9.1.2 ¿Por qué es importante la arquitectura?

En un libro dedicado a la arquitectura del software, Bass et al. [Bas03]
identifican tres razones clave por las que es importante la arquitectura
del software:
• Las representaciones de la arquitectura del software permiten la
comunicación entre todas las partes (participantes) interesadas en el
desarrollo de un sistema basado en computadora.
• La arquitectura resalta las primeras decisiones que tendrán un efecto
profundo en todo el trabajo de ingeniería de software siguiente y,
también importante, en el éxito último del sistema como entidad
operacional.
• La arquitectura “constituye un modelo relativamente pequeño y
asequible por la vía intelectual sobre cómo está estructurado el sistema
y la forma en la que sus componentes trabajan juntos” [Bas03].
El modelo del diseño de la arquitectura y los patrones arquitectónicos
contenidos dentro de este son transferibles. Es decir, los géneros, estilos
y patrones arquitectónicos pueden aplicarse al diseño de otros sistemas
y representan un conjunto de abstracciones que permite a los ingenieros
de software describir la arquitectura en formas predecibles.
 Lectura 3
Tomado de: https://blog.koalite.com/2014/03/cuanto-dano-han-hecho-los-arquitectos-de-
software/

Arquitectura de Software
Según la wikipedia, la arquitectura de software es el diseño de más alto
nivel de la estructura de un sistema. Esta definición es algo ambigua
puesto que precisar cuál es el «más alto nivel» de un sistema es un tanto
subjetivo, pero nos permite hacernos una idea intuitiva de lo que estamos
hablando.
En realidad, podríamos ver la arquitectura como algo fractal que podemos
observar con distintos niveles de detalle. Podemos tener una arquitectura
global de todo un proyecto que engloba varios sistemas, arquitecturas a
nivel de cada sistema, y arquitecturas específicas para cada componente
de un sistema. Pero, independientemente del nivel al que lo apliquemos,
la idea es la misma: diseñar la manera en que se estructuran y
comunican los distintos componentes que forman parte de algo.
Partiendo de esta idea, es fácil entender que la arquitectura de software
es un factor muy importante a la hora de desarrollar aplicaciones. Elegir
la arquitectura correcta para un sistema (o para una parte del mismo)
puede ser crítico a la hora de alcanzar los requisitos establecidos de
escalabilidad, flexibilidad, facilidad de mantenimiento, etc.
Existen muchos tipos de arquitecturas que han ido evolucionando con el
tiempo, desde las tradiciones cliente-servidor, las basadas en N-capas,
orientadas a servicios, basadas en microservicios, orquestadas alrededor
de buses, etc.

Hay también catálogos de patrones de arquitectura similares a los

catálogos de patrones de diseño (a veces la frontera entre diseño y
arquitectura es francamente difusa), que recogen distintos patrones de
«probada eficacia» (ejem) que podemos aplicar al establecer la
arquitectura de un sistema.
Desarrollar una aplicación sin tener en cuenta la arquitectura acaba
resultando en una masa monstruosa de código difícil de comprender, difícil
de evolucionar y difícil de escalar.

Si la arquitectura de software es algo tan importante a la hora de

desarrollar aplicaciones, parece lógico que exista gente especialmente
preparada para decidir qué arquitectura usar y cómo implantarla, y esos
son, claro está, los arquitectos de software.
Arquitectos de Software
Un arquitecto de software debe ser capaz de analizar un problema y
diseñar la mejor arquitectura para resolverlo. Un arquitecto de software
conoce una amplia gama de tipos de arquitectura y patrones
arquitectónicos, sabe cuándo aplicarlos y, a partir de ellos, establece unas
pautas, normalmente usando diagramas UML, frameworks o
implementaciones de referencia, y delega la implementación del sistema
a un equipo de desarrollo.

Esa visión de la arquitectura de software tan similar a la del arquitecto de

un edificio, que genera unos planos para que otros construyan el edificio,
es una visión errónea y peligrosa.

El desarrollo de sofware no se puede compartimentalizar tanto como para

que unos diagramas UML o un mega framework corporativo sirva de guía
única e infalible al construir una aplicación.

Es posible (no lo sé, no tengo ni idea de eso) que al construir un edificio

se puedan dar instrucciones tan precisas sobre cómo debe ser una pared
como para que cualquiera que sepa construir paredes lo haga bien.

En el desarrollo de software, el número de grados de libertidad que existen

a la hora de implementar algo hacen que definir específicamente lo que se
debe hacer y cómo se debe hacer, no sea práctico. La única forma de
conseguirlo es con el código fuente, y eso implica hacerlo (no diseñarlo).
La arquitectura es algo que hay que ir ajustando en mayor o menor medida
a lo largo del desarrollo. Puede que las pautas más generales, como si la
aplicación será web o de escritorio, o si se usará una SQL Server o
MongoDB puedan mantenerse estables durante bastante tiempo, pero en
cuanto bajas a niveles de componentes, suele ser contraproducente tener
que atarse a una arquitectura prefijada, del estilo de «todos las clases
deben tener su interfaz correspondiente», «todo sistema tendrá su
contenedor de inversión de control», «siempre se usará un ORM», etc.

Tratar de separar la arquitectura del desarrollo es un error y tratar de

separar el rol del arquitecto del rol del programador/desarrollador es otro
error. Es cierto que no todos los programadores son arquitectos, pero todos
los arquitectos deben ser programadores. Aun así, todo programador
debería comprender la arquitectura del sistema que está desarrollando,
con sus pros, sus contras y los motivos por los que se ha elegido.
Ser arquitecto de software tiene un componente aspiracional para muchas
personas. Puede que sea porque es la única forma que tienen de mejorar
en sus empresas, puede que sea por el aparente glamour asociado al rol,
pero hay personas que parece que necesitan ser arquitectos de software,
incluso a veces despreciando todo el trabajo relacionado con la
programación (eso es para los que «pican código»).
Eso suele acabar con una obsesión por la arquitectura en términos
abstractos, mucha palabraría sobre SOA, DDD, ESBs o lo que esté de
moda en el momento, pero con una falta de conexión muy grande con el
mundo real. Son arquitectos que viven sus torres de marfil y desde ellas
«diseñan» (por llamarlo de alguna manera) arquitecturas que luego son de
muy poca ayuda, o incluso directamente contraproducentes, a la hora de
desarrollar realmente el software.

He conocido empresas en las que un «arquitecto» diseñaba una

arquitectura, se la pasaba al equipo de desarrollo para que la siguiese a
rajatabla y sólo volvía a aparecer por el proyecto de vez en cuando para
asegurarse que la arquitectura se estaba siguiendo. Incluso he visto casos
de empresas con un departamento específico de arquitectura que
marcaba las pautas a nivel global de cómo debían ser todos los proyectos.
En ambos casos los resultados, al menos desde el punto de vista del
software desarrollado, era bastante cuestionables.

Conclusiones
La arquitectura de software es una tarea necesaria para el desarrollo de
software y se le debe prestar la atención adecuada.

El problema es que la arquitectura de software es algo demasiado

importante para dejarlo en manos de los arquitectos. O al menos, es
algo demasiado importante como para dejarlo en manos de arquitectos
como los que he descrito antes y que, por desgracia, abundan en
determinados sectores.
Existen muy buenos arquitectos de software, capaces de diseñar y
desarrollar soluciones sencillas para problemas complejos, pero todos los
que he conocido con esa capacidad son también buenos programadores,
viven el día a día con el equipo de desarrollo y conciben la arquitectura
como parte del proceso de desarrollo, no como algo que quede prefijado
al principio del desarrollo y haya que seguir de forma ciega e innegociable.

En definitiva, por mucho que en algunos ámbitos se empeñen en crear

roles específicos para cada aspecto del desarrollo de software, es bueno
recordar que la especialización es para los insectos, y que cuando creas
roles muy especializados, consigues justamente eso: arquitectos que
diseñan sin saber las implicaciones que tienen sus diseños a nivel de
código, y programadores que no pueden mejorar el sistema porque ni
pueden ni saben salirse de la arquitectura marcada.