En este mes quiero dedicar un
espacio para explicar a detalle que es la arquitectura de software y como se ve
el trabajo de un arquitecto de software en la vida real, más allá de la teoria y
aplicada a las empresas reales que tienen una real arquitectura de software. ¿Por
qué usar tanto la palabra real?, porque la arquitectura es uno de esos términos
ampliamente usados, y en esta región, en muchos casos y para pesar de quienes
somos profesionales en esta área, mal usado y mal interpretado por perfiles
tanto técnicos como administrativos de las organizaciones. Hablemos entonces
con un ejemplo que se aleja de la tecnología sobre la arquitectura de software,
las capas o tipos que tiene, así como su evolución en el tiempo.
Para empresa quisiera hacerles
una pregunta que espero contesten para ustedes mismos antes de continuar. Usted
tiene el proyecto de construir una nueva casa a su gusto, está considerando
nuevas características que requiere pues ahora con dos hijos pequeños, mascotas
y a su padre viviendo con usted, las necesidades que tenia cuando compro la
casa donde vive ahora han cambiado. Usted requiere alguien para transmitirle
las ideas y que pueda hacer un plano de todas sus necesidades y asegurarse que
sea estéticamente correcto y estructuralmente también, que considere su presupuesto,
su visión a futuro, tal vez una piscina mas adelante con un área de juegos. ¿A
que profesional contrataría? (Si alguno quiere dejarme su respuesta en los
comentarios es bienvenida).
Pues la respuesta más común es, a
un arquitecto. Y es que en el negocio de la construcción esta claramente
separado el concepto de arquitecto, así como están el de maestro de obra,
constructor, albañil, etc. Lastimosamente esa línea en la tecnología no esta
bien definida, en gran parte, por culpa de nosotros, los profesionales en esta área
que tampoco la tenemos clara.
Entonces, que es la arquitectura
de software: No es otra cosa que un conjunto de patrones que proporcionan un
marco de referencia para guiar la construcción del software. Esto quiere decir que
para hacer un software TAMBIEN se hacen planos. Ahora, y donde nosotros los que
estamos en esta profesión pecamos es en creer que cualquier diagrama con
flechas es una arquitectura de software, además tenemos que diferenciarla de la
arquitectura de soluciones o de integración por ejemplo. Les quiero mostrar
algunos diagramas que he visto con el titulo de arquitectura de software:
No solo son incorrectos, sino que
no existe un único diagrama para describir una arquitectura, existen distintas
vistas que permiten en realidad diseñar un software, como el modelo de 4+1 views
de Kruchten por ejemplo. Claro, estos modelos algunos demasiado teóricos se alejan
de lo que debería de hacerse realmente en una organización, y como todo no es
una receta mágica, pero puedo compartirles cuales son aquellas vistas de una solución
tecnológica que generan más valor:
1. Diagrama
de arquitectura de solución: Este diagrama permite entender la solución
como un todo, mostrando normalmente componentes tecnológicos como cajas negras.
Este es un diagrama muy general que por si solo no expresa la totalidad de una
arquitectura. En este tipo de diagramas pueden evidenciarse patrones de alto
nivel como, patrones de integración, patrones de consumo de datos, etc.
2. Diagrama
de arquitectura de software: Normalmente este describe como esta construido
un sistema, y evidencia su patrón de arquitectura, podemos observar mas de uno,
alguna parte con tubos y filtros, otra usando algo tipo MVC o en capas, etc.
Este debe describir todos los componentes a alto nivel de un sistema y sus
interrelaciones. Y es este uno de los que menos he visto en los últimos años,
pues ya nos acostumbramos a pintar nuestras soluciones tecnológicas como cajas
negras y a dejar por dentro aun códigos monolíticos corriendo sobre “Arquitecturas
de últimas tendencias”, esto sobre todo por temor a decir que aun nuestra
arquitectura, en la nube y todo en muchos casos, sigue siendo monolítica. Es así
como nos atrevemos a construir un conjunto de apis usando por ejemplo .net y
hacer que estas no sean mas que fachadas que en realidad siguen invocando un
sistema monolítico, entonces la velocidad, independencia y posibilidad de
desplegar las apis como verdaderos microservicios se pierden, pero claro, esto
no lo vemos en un diagrama general de cajas negras, es así como quienes no
conocen esto a profundidad son engañados por las nuevas invenciones y “evoluciones”
de sus contextos tecnológicos.
3. Diagrama
de arquitectura de infraestructura: Este diagrama muestra todo el mapa
a detalle del contexto de hardware que ayudara a soportar la solución de software,
y siguen necesitándose así la solución este en la nube, es bueno saber, por
ejemplo de ser una solución Amazon, en que tipo de instancias estas desplegado,
como usaste los módulos EBS de persistencia entre otros, además de los componentes
de red, luego no nos asombremos cuando implementamos un software y no funciona al inicio pues se nos olvido
abrir puertos en el firewall entregar permisos entre otros, ese tipo de
solicitudes se visualizan con este diagrama.
4. Diagrama
de despliegue: Es importante siempre poder relacionar el hardware y el
software y este diagrama lo permite, identificar que esta desplegado en cada
componente de infraestructura y como están conectados, protocolos, seguridad
entre otros.
5. Diagrama
de integración: Ha tomado muchísima relevancia con los nuevos esquemas
de integración y la desaparición de los sistemas (todo en uno), ahora prevalece
el tener pequeños componentes de software que se conectan y por lo tanto tener
un diagrama que permita conocer esas interrelaciones y acceder a los contratos
o descripciones de métodos y variables entre las integraciones es fundamental,
esto puede administrar por ejemplo de ser el caso usando un api management. Además
si está usando microservicios contenerizados, le permitirá junto al diagrama
anterior, entender como están desplegados sus microservicios y en que
contendedores y donde residen.
6. Diagrama
de Arquitectura de datos: Y ojo que esto no es el diagrama entidad relación,
es más, en esta entrada no estoy para nada hablando de diagramas de diseño
detallado, eso puedo tocarlo después, estoy hablando de la descripción de sus
fuentes de datos, gobierno de información, migración de data histórica, etc. La
data hoy en día es lo que finalmente más valor genera, pero es raro ver a un “arquitecto”
diagramando esta vista.
¿Parece mas complicado que pintar
cajas negras o servidores con flechas?, claro que lo es, por eso es arquitectura,
por eso es una profesión especifica dentro de la rama de tecnología, por eso no
todos podemos simplemente hablar de las arquitecturas si no tenemos claro que
son los patrones, que son los atributos de calidad y como funcionan en son de las
arquitecturas y de las necesidades del usuario. También debemos como
profesionales ser sinceros y decir lo que tenemos y lo que no tenemos, si
construimos un “microservicio” que invoca
5 procedimientos almacenados de una base de datos, la cual funciona con una
arquitectura monolítica no estoy haciendo microservicios, es más ni siquiera
podre desplegarlos en un contenedor, debemos de dejar de usar los términos de
manera incorrecta, vender información falsa, llenar la cabeza de nuestros CEO’s
con datos incorrectos que después frente a una sala de personas expertas los harán
quedar como unos ignorantes en el tema. Las arquitecturas de software así como
las arquitecturas de las casas han evolucionado, pasamos de sistemas monolíticos
a arquitecturas orientadas a servicios y ahora estamos hablando de microservicios,
no todo aplica para todos y no todo debe hacerse por ejemplo con microservicios
porque es lo último. Pero tampoco es cierto que, si a su casa de los años 20 le
cambia la pintura de la fachada, sus cimientos y tuberías no seguirán siendo de
los años 20.
Por favor, para hacer
arquitectura de tecnología, así como lo haría para su casa, contrate a un
arquitecto de tecnología, esto hace diferente que sea tan difícil hacer un
cambio en un sistema, o que para hacer un cambio debe hacerse en la madrugada
porque hay que apagar todo o que cuando
corren procesos grandes todo se pone lento, o que cuando se va a hacer algo
nuevo debe de lidiar con la obsolescencia y problemas de lo viejo, es lo único que
asegura software de calidad, testeable, durable, escalable, adaptable…
moderno!!!
¡¡¡Feliz semana!!!
No hay comentarios.:
Publicar un comentario