La palabra arquitectura
evoca un halo de misterio que nos lleva a pensar sobre decisiones importantes y
habilidades técnicas a las que sólo unos pocos pueden llegar. Se puede llegar a
decir que la arquitectura técnica está en el pináculo del logro técnico. Pero,
¿alguien sabe que es un arquitecto software? ¿qué hace un arquitecto software?
Un arquitecto software
es un programador y continúa siendo un programador. Esto significa que los
arquitectos software siguen desarrollando y no se centran en otras tareas de
alto nivel. Un arquitecto software cuenta con suficientes habilidades de
programación como para guiar al resto del equipo hacia un diseño que maximiza
la productividad.
Los arquitectos software
puede que no escriban tantos códigos como otros programadores pero aún así
estos continúan envueltos en tareas de programación. Los arquitectos siguen
programando porque si no ellos no podrían hacer bien su trabajo dado que no
experimentan los problemas que experimentan el resto de programadores.
La arquitectura de un
sistema software es la forma dada a ese sistema por aquellos que lo construyen.
La forma de este sistema viene dada por como está dividido en componentes, la
ordenación de estos componentes y la forma en que estos componentes se
comunican entre ellos.
El propósito de esa
forma es facilitar el desarrollo, el despliegue, operación y mantenimiento del
sistema de software.
La estrategia detrás de
esta “facilitación” es dejar tantas opciones abiertas como sea posible lo más
tarde posible.
Esto sorprende cuanto
menos. Quizá el pensamiento generalizado es que la meta de un arquitecto de
software es hacer que el sistema trabaje propiamente. Ciertamente, el sistema
tiene que trabajar propiamente y la arquitectura del sistema debe soportar esta
meta. Sin embargo, la arquitectura de un sistema tiene poco que ver con si un
sistema trabaja propiamente.
Por ejemplo, se puede
dar el caso de que un sistema con una mala arquitectura funcionen
correctamente. Los problemas de estos sistemas no están en su operación si no
en su implementación, mantenimiento y desarrollo continuo.
Esto no quiere decir que
la arquitectura no juegue un papel en el comportamiento del sistema, de hecho,
este papel es crítico pero no tiene que ver con la operativa del sistema. Existen
pocas opciones de comportamiento, si es que las hay, que la arquitectura de un
sistema puede dejar abierta.
El propósito principal
de la arquitectura es soportar el ciclo de vida del sistema. Las buenas
arquitecturas hacen el sistema fácil de entender, fácil de desarrollar, fácil
de mantener y fácil de desplegar. El objetivo principal es minimizar el coste
del ciclo de vida y maximizar la productividad del programador.
Desarrollo
El propósito de la
arquitectura de un sistema hacer que el sistema sea fácil de desarrollar para
las distintas partes que estén implicadas en su desarrollo.
Si hay diferentes
equipos implicados en un desarrollo implicarán diferentes estructuras arquitectónicas.
Por ejemplo, si sólo hay un único equipo de cinco desarrolladores estos pueden
desarrollar un sistema monolito sin intefaces ni componentes bien definidos. De
hecho, tal equipo probablemente encontraría las restricciones de una
arquitectura como un impedimento durante los primeros días del desarrollo. Esta
es la razón por la cual muchos sistemas carecen de una buena arquitectura: se
empezaron sin ninguna arquitectura porque el equipo era pequeño y no querían el
impedimento de una arquitectura.
Por otro lado, si hay
cinco equipos de desarrollo con cinco desarrolladores por equipo el sistema no
progresará a menos que el sistema esté dividido en componentes bien definidos
con interfaces estables y fiables. Sin contar con otros factores ni la tipología
del proyecto el sistema tiene una alta probabilidad de que la arquitectura de
ese sistema esté compuesta por cinco componentes, uno por equipo.
Esta arquitectura de
cinco componentes puede que no sea la mejor elección para la implementación,
operación y mantenimiento del sistema. Sin embargo, es la arquitectura hacia la
cual evolucionará el sistema si sólo se tiene en cuenta los distintos equipos.
Despliegue
Un sistema no es muy
útil en un entorno local, cuando es útil es cuando está desplegado en producción.
Por esta razón, cuanto más alto sea el coste de despliegue menos usable será el
sistema. Un objetivo de la arquitectura de software debería ser que el sistema
se pueda desplegar con una simple acción.
La estrategia de
despliegue rara vez se contempla durante el desarrollo inicial lo que lleva a
arquitecturas que son fáciles de desarrollar pero difíciles de desplegar.
Por ejemplo, en una fase
temprana del desarrollo de un sistema, los desarrolladores pueden decidir usar
una arquitectura de micro servicios. Ellos pueden encontrar que esta estrategia
hace el sistema fácil de desarrollar desde que los límites de los componentes
están muy definidos y las interfaces son relativamente estables. Sin embargo, a
la hora de desplegar se podría encontrar con que el número de servicios se ha
vuelto desalentador. Configurar las conexiones entre ellos y el tiempo de sus
inicializaciones podría resultar en una gran fuente de errores.
Si los arquitectos
hubieran considerado los problemas de implementación desde el principio,
podrían haber optado por menos servicios, un híbrido de servicios y componentes
en proceso, y un medio más integrado para gestionar las interconexiones.
Operación
El impacto de la
arquitectura en la operación del sistema tiende a ser menos dramático que el
impacto de la arquitectura en el desarrollo, la implementación y el
mantenimiento. Casi cualquier dificultad operativa se puede resolver al incluir
más hardware al sistema sin impactar drásticamente la arquitectura del
software.
De hecho, es una
práctica común que, cuando un sistema tiene una arquitectura ineficiente y
llegan al límite donde empiezan a no operar correctamente por alcanzar límites
hardware pueden solucionar el problema simplemente agregando más almacenamiento
o servidores. El hecho de que el hardware sea barato y la gente costosa
significa que las arquitecturas que impiden el funcionamiento no son tan
costosas como las arquitecturas que impiden el desarrollo, la implementación y
el mantenimiento.
Esto no quiere decir que
una arquitectura que esté alineada con el funcionamiento no sea deseable, de
hecho, lo es. Es sólo que el coste de desarrollo, implementación y
mantenimiento es más elevada.
Otra función que
desempeña la arquitectura en el funcionamiento de un sistema es comunicar las
necesidades operativas del sistema.
Esto quiere decir que la
arquitectura de un sistema hace que el funcionamiento del sistema sea evidente
para los desarrolladores. La arquitectura debe revelar la operación del
sistema. La arquitectura del sistema debe revelar los casos de uso, las
características y los comportamientos requeridos del sistema. Esto simplifica
la comprensión del sistema y, por lo tanto, ayuda en el desarrollo y el
mantenimiento.
Mantenimiento
De todos los aspectos de
un sistema de software, el mantenimiento es el más costoso. El interminable
desfile de nuevas características y el inevitable rastro de defectos y
correcciones consumen grandes cantidades de recursos humanos.
El principal coste del
mantenimiento es la espeleología y el riesgo. La espeleología hace referencia a
“excarvar” a través del software existente, tratando de determinar el mejor
lugar y la mejor estrategia para agregar una nueva característica o reparar un
defecto. Al realizar dichos cambios siempre existe la posibilidad de crear
defectos involuntarios, lo que aunmenta el coste del riesgo.
Una arquitectura
cuidadosamente pensada mitiga de forma sustancial estos costos. Al separar el
sistema en componentes y aislar esos componentes a través de interfaces
estables, es posible establecer las vías para funciones futuras y reducir en
gran medida el riesgo de roturas involuntarias.
Manteniendo las opciones
abiertas
Como se ha visto, el
software tiene dos valores el valor de su comportamiento o funcionalidad y el
valor de su estructura siendo este último el que mayor peso tiene en el
sistema.
Los sistemas software se
pueden descomponer en dos parte: la política y los detalles. Los elementos de
la política hacen referencia a las funcionalidades del negocio mientras que los
detalles es todo lo necesario para que otros sistemas o componentes puedan
comunicarse con la política. Esto incluye dispositivos de entrada y salida,
bases de datos, sistemas web, servidores, frameworks, protocolos de
comunicación, etc.
La meta de un arquitecto
es crear una forma para el sistema que reconoce la política como el elemento
más esencial del sistema mientras hace irrelevantes los detalles. Esto permite
retrasar y diferir las decisiones sobre esos detalles.
Por ejemplo:
- No es
necesario elegir un sistema de base de datos en las primeras fases de
desarrollo ya que a la política de alto nivel no le importa la base de
datos que se utilizará. De hecho, para la política de alto nivel le
debería dar igual si la base de datos es relacional, distribuida,
jerárquica o incluso un archivo de texto plano.
- No es
necesario un servidor web en las primeras fases de desarrollo ya que la
política no debe saber en qué medio se está entregando. Si la política de
alto nivel no tiene conocmineto de HTML, Ajax, etc no es necesario decidir
qué sistema utilizar hasta más adelante. De hecho sería posible entregar
el sistema en un formato que no fuera web.
- No es
necesario adoptar REST al principio del desarrollo por lo que la política
de alto nivel debe ser independiente de la interfaz con el mundo exterior.
Tampoco es necesario adoptar una arquitectura de micro-servicios o SOA.
Las políticas de alto nivel no deberían preocuparse por estas cosas.
- Tampoco
es necesario adoptar un marco de inyección de dependencia al inicio del
desarrollo, ya que la política de alto nivel no debe importarle cómo se
resuelven las dependencias.
Si se puede desarrollar
la política de alto nivel sin comprometerse con los detalles que la rodean, se
pueden retrasar y diferir las decisiones sobre esos detalles durante mucho
tiempo. Además, cuanto más se espere a tomar esas decisiones, más información
se tendrá para tomarlas correctamente.
Esto brinda la
oportunidad de experimentar con distintas opciones con el propósito de recabar
más información. Si se tiene una parte de la política de alto nivel funcionando
y, para esta, no tiene el conocimiento sobre que base de datos se está
utilizando si no que es una abstracción se podrían probar distintas bases de
datos para verificar la aplicabilidad y el rendimiento.
Cuanto más tiempo se
dejen las opciones abiertas más experimentos se podrán realizar y más
información se tendrá cuando llegue el momento de tomar esas decisiones.
¿Qué ocurre si otra
persona ha tomado esas decisiones ya? ¿Qué sucede si la empresa ya tiene una
base de datos concreta o un determinado framework? Un buen arquitecto finge que
la decisión no se ha tomado aún de manera que configura el sistema de modo que esas
decisiones aún puedan aplazarse o modificarse durante el mayor tiempo posible.
Conclusión
Los buenos arquitectos
separan cuidadosamente los detalles de la política y entonces desacoplan la
política de los detalles tan a fondo que la política no tiene conocimiento de
los detalles y no depende de estos de ninguna manera. Los buenos arquitectos
diseñan la política para que las decisiones sobre los detalles se puedan
retrasar y aplazar el mayor tiempo posible.
No hay comentarios:
Publicar un comentario