Primeros pasos en la arquitectura de software
Así como cuando se construye un edificio, desarrollar buen software exige planeación y seguimiento
Cuando se habla de arquitectura de software, es normal que escuchemos cosas como “estructuras”, “diagramas de modelos”, “comunicación entre sistemas” o entre mismos módulos de un sistema.
Podemos comparar una solución de software con la construcción de un edificio: necesitamos un análisis para estar seguros que el proyecto inmobiliario cumpla con los requerimientos, debe existir un plano o estructura con especificaciones para conocer su composición, así como una lista de materiales para la construcción per se.
Todo esto no es posible sin un rol que lleve a cabo este plan, ¿cierto? La responsabilidad de que ese edificio sea sólido, seguro y que no se derrumbe en desarrollo de software se le llama solution architect (arquitecto de soluciones).
En este artículo vamos a conocer sobre el rol de un arquitecto, el proceso de desarrollo, cómo la arquitectura es relevante en cada paso para construir software, aspectos a tomar en cuenta en una decisión arquitectónica de un sistema y otros temas importantes.
Antes de dar una definición de arquitectura debemos tener en mente las etapas que existen en el desarrollo de software. Estas han ido evolucionando a la par de metodologías ágiles, es por eso que en años anteriores el proceso era distinto. Las etapas de las que voy a platicarles son:
1. Análisis de requerimientos
En esta primera etapa, se identifica y comprende el problema que se desea solucionar basándose en requerimientos del negocio y usuarios. Es la razón de existir de la solución.
2. Diseño de la solución
Se realiza un análisis profundo del problema. Aquí es donde un analista de negocio, un arquitecto o un equipo de desarrollo trabajan en conjunto para plantear posibles soluciones. El resultado de esta etapa deberá ser un modelado, documentación de la solución o tecnologías necesarias.
3. Desarrollo de evaluación
Está alineado con el prototipado rápido, pero tiene más que ver con la creación y acumulación de sistemas. En esta etapa se obtienen resultados pequeños que van evolucionando.
4. Despliegue
En esta etapa el software construido se pone a disposición del usuario final, se requieren roles de infraestructura que se encarguen de esto, por ejemplo si se está trabajando en una aplicación web necesitemos servidores donde alojar nuestro código, una infraestructura que soporte balanceo de carga y escalabilidad, etc.
5. Mantenimiento y Evolución
Esta etapa es para resolver bugs que surjan o se agreguen nuevas funcionalidades, es una etapa repetitiva de Desarrollo y despliegue.
Teniendo en cuenta estas etapas en la parte de Diseño de la solución y Desarrollo de Evaluación es donde debemos encontrar los problemas a los que nos vamos a enfrentar, Freed Brooks nos dice en su libro de “No Silver Bullet” que podemos dividirlos en dos tipo de problemas.
Problemas Esenciales
Trata de cómo entender el concepto de lo que vamos a solucionar, entender el diseño que vamos hacer y se dividen en 4 categorías.
- Complejidad: Cuando el problema a resolver es complejo en sí mismo. Ejemplo:
En una aplicación sobre transportes, el calcular el tiempo o cuál es la mejor ruta, etc. Puede ser tan complejo dependiendo la capacidad de la funcionalidad. - Conformidad: Entender en qué contexto se usará el producto y cómo se adecuada al contexto imperfecto. Ejemplo: ¿Requiere internet, qué disponibilidad existe de Internet?, ¿Requiere actualizaciones mayores?
- Tolerancia al cambio: La medición de cuánto podemos adaptarnos a los cambios. Un ejemplo habitual son las leyes de facturación o de impuestos ya que son distintas por países y no nos permiten que hagamos cálculos simples…
- Invisibilidad: Dificultad de entender su forma, ya que es intangible, solo existen en código o documentación
Problemas Accidentales
Tienen que ver con las plataformas, tecnología a usar, lenguajes, frameworks, integraciones, api’s, etc. Estos son los problemas que son más comunes encontrar.
- Lenguajes de alto nivel: Lenguaje de programación de alto nivel es un tipo de lenguaje de programación que permite al programador escribir programas (algoritmos) que son más o menos independientes de un tipo particular de computadora (del hardware). Estos lenguajes son considerados de alto nivel porque son más parecidos al lenguaje natural humano y más lejanos al lenguaje de las máquinas.
- Multi-procesamiento: Resuelve el problema del feedback al momento de programar.
- Entornos de programación: Un entorno de programación es un programa o conjunto de programas que engloban todas las tareas necesarias para el desarrollo de un programa o aplicación.
“Considero a la especificación, diseño y comprobación del concepto la parte difícil de hacer software.
(…) Si esto es cierto, hacer software siempre será difícil. No existe la bala de plata.”
No Silver Bullet (Frederick P. Brooks Jr., 1986).
Esta frase de F. Brooks es interesante, no existe una solución absoluta que se adapte a cualquier problema, es eso. Es importante tener esto mente, piensa en esas situaciones cuando estas en busca de alguna librería o framework, debemos hacernos la pregunta “¿Qué está resolviendo esta tecnología? “ “¿Está resolviendo un problema esencial o accidental?” si es accidental, está bien, puede traernos beneficios pero no quiere decir que debamos usarla siempre, entonces ….
¿Cómo resolver las dificultades esenciales?
En su libro Brooks plantea 4 formas de resolverlas
1. No desarrollar:
Si tenemos un problema muy complejo tal vez la mejor opción es no reinventar la rueda, quizás la mejor solución es usar un sistema ya existente.
Ejemplo:
En un sistema que requiera un módulo de facturación, puede ser muy complejo ya que involucra leyes, cálculos complejos, una opción es integrar una api que ya haga todo eso.
2. Prototipado rápido
Se evoluciona el sistema a pasos pequeños y siempre se busca obtener el feedback lo antes posible. “¿Es lo qué necesitabas?”, “¿Quieres que evolucione a partir de esa funcionalidad o hago otra nueva?”
3. Desarrollo evolutivo
Está alineado con el prototipado rápido, pero tiene más que ver con la creación y acumulación de sistemas. Obtener resultados pequeños pero esos mismos van evolucionando.
4. Grandes diseñadores
Tienen capacidad para abstraerse del problema y crear una solución simple, elegante, que resuelva de la mejor forma y a la vez tenga los mejores atributos de calidad.
Bien, ya sabemos cómo organizar los problemas que puedan surgir en un proceso de desarrollo de la arquitectura, pero…
¿Qué es la arquitectura?
Leyendo sobre el tema me topé con definiciones de distintos libros que se complementan muy bien.
“ Es la estructura del sistema, compuesta por elementos de software, sus propiedades visibles y sus relaciones”
Software Architecture in Practice(Bass, Clements y Kazman, 2003)
“El conjunto de decisiones principales de diseño tomadas para el sistema”
Software Architecture Foundations, Theory and Practice (Taylor, 2010)
Veamos ejemplos más ilustrativos de arquitecturas:
Este diagrama explica lo que sucede detrás de escena cuando escribimos un tweet. El problema que resuelve es hacer llegar en tiempo real ese nuevo tweet a distintos usuarios, incluyendo la app móvil.
Netflix
Netflix se enfrentaba al problema de optimización de la aplicación, la solución fue segmentar responsabilidades en su arquitectura de servicios.
React Native
Esta arquitectura se concentra en la forma en que React Native construye la UI. Como ven, no es tan compleja como las anteriores. El punto es que resuelve una necesidad.
Todos estos diagramas describen a alto nivel un sistema de software. Cada uno es diferente y eso es porque el problema que resuelven:
- En el de Twitter lo importante es el alcance de datos.
- Netflix busca balancear la carga de información
- React Native quiere optimizar el renderizado de su front end.
Todo esto es relevante para tomar la decisión de una arquitectura y el estilo adecuado.
Objetivos del arquitecto
El arquitecto tiene varias partes interesadas (stakeholders), así que debe conectar los requerimientos de cada uno de ellos con la implementación del sistema.
Stakeholders involucrados con diferentes requerimientos
- Cliente. Entrega a tiempo y que no rebase el presupuesto.
- Manager. Comunicación clara entre los equipos que participan en el desarrollo del sistema.
- Dev. Desarrollo fácil de implementar y mantener.
- Usuario. Disponibilidad del producto.
- QA. Fácil de probar.
El arquitecto de software debe gestionar los siguientes puntos para cada stakeholder:
- Encontrar los riegos más altos en el desarrollo del sistema (Cliente).
- Desarrollar un sistema con módulos y flexible (Manager).
- Desarrollar software con el punto anterior y fácil de cambiar (Dev).
- Implementar estrategias para la disponibilidad del sistema (Usuario).
- Diseñar un sistema modular, en el que se pueda probar cada parte sin dificultades (QA).
La unión de estos requerimientos (funcionales / no funcionales) va a llevar al arquitecto a tomar decisiones que impactan directamente en el desarrollo del software.
Por último, comparto un texto de F. Brooks que me pareció muy interesante:
“ Necesitamos grandes diseñadores. Los grandes diseñadores no son programadores que simplemente saben utilizar una tecnología, sino ingenieros que saben abstraer ese problema puntual y entender el problema general. Saben diseñar una solución que es elegante y también simple. Saben diseñar un sistema que resuelva de la mejor forma el problema y que a la vez tenga los mejores atributos de calidad”.
¡Nos leemos luego!
