My study notes to become a solutions architect - Fundamentals | ES

  
  ,

TLDR: Durante todo este tiempo, siempre me ha llamado la atención el tema de la arquitectura de software, cómo, con un problema, podemos presentarle una solución al cliente que le permita cumplir las expectativas. Durante los inicios de mi carrera me enfrenté a muchos desafíos, y escribo este post para el Ramiro de esa época. Espero que alguien pueda encontrar de utilidad estas notas.

Todas estas notas fueron un compilado de varios cursos, especialmente el Solutions Architect School que brinda la empresa para la que trabajo actualmente llamada Epam. Ese curso se basó en el libro “Software Architecture in Practice 4th edition” del SEI (Software Engineering Institute).

¿Qué es Arquitectura?

The software architecture of a system is the set of structures needed to reason about the system. These structures comprise software elements, relations among them, and properties of both. (SEI)

Software architecture is the process of defining a structured solution that meets all of the business, technical, and operational requirements. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality. (Microsoft Application Architecture Guide)

Hay muchas definiciones al respecto, pero algo importante a tener en cuenta es que la arquitectura consiste en elementos y la relación entre esos elementos. Estos elementos tienen atributos o propiedades. Y el diseño de una arquitectura es basada en la variedad de todos los requerimientos.

Cabe resaltar que hay muchas formas de resolver un problema; si a dos personas de diferentes organizaciones se les presenta el mismo problema, es probable que la solución sea diferente. Esto se debe a las influencias y experiencia del arquitecto; pero también los stakeholders, los business goals, la organización y su ambiente, los requisitos (en especial los architecturally significant), las restricciones, las tecnologías, etc.

Hay muchos stakeholders en una solución, estos tienen diferentes necesidades y expectativas. Incluso entre ellos se pueden contradecir. Algunos de estos son:

  • Clientes
    • Costo
    • Funcionalidad
    • Tiempo de comercialización
    • Calidad
  • Usuarios
    • Usuario final
      • Usabilidad
      • Rendimiento
    • Administrador del sistema
      • Configuración del sistema
      • Configuración de seguridad
      • Copia de seguridad y recuperación
  • Gestión
    • Consecución de objetivos estratégicos
    • Mantener bajos los costos de desarrollo
    • Cumplimiento del cronograma
    • Calidad del producto

La organización y su ambiente también influyen en la arquitectura. Algunos de estos aspectos son:

  • Estructura de la organización
  • Procesos en la organización
  • Utilización de la fuerza laboral
  • Inversión en activos
  • Calendario de lanzamiento

Las tecnologías también influyen en la arquitectura. Las tendencias, estándares, estilos de arquitectura y patrones comúnmente usados afectan la arquitectura.

Y finalmente, la experiencia del arquitecto, su experiencia positiva/negativa con tecnologías y patrones anteriormente usados. Y su educación y entrenamientos anteriores también influyen.

¿Qué tipos de arquitecto existen?

  • Enterprise Architect, es alguien más enfocado al negocio, a la estrategia técnica de la empresa.
  • Solution Architect, es alguien más enfocado en la solución de un problema en particular, lograr los business goals de la compañía.
  • Technical Architect, es alguien más enfocado en la tecnología, en la implementación de la solución con un buen diseño técnico y de servicios.
  • Hay más, como Infrastructure Architect, Data Architect, Integration Architect, etc.

Pero el enfoque de este post es en el Solution Architect. Aquí hay una descripción de otra persona que me gustó mucho:

An architecture of a solution, where a solution is a system that offers a coherent set of functionalities to its environment. As such, it concerns those properties of a solution that are necessary and sufficient to meet its essential requirements. (Danny Greefhorst, Erik Proper)

El rol ha cambiado mucho a lo largo del tiempo, hay un libro muy interesante llamado “The Architect Elevator” y hay un post de Martin Fowler que habla sobre esto. Puedes leer más aquí: The Architect Elevator — Visiting the upper floors. Pero en general, es una metáfora de que el arquitecto debe estar en contacto con el penthouse (los directivos que dirigen la estrategia) y con el engine room (donde se construye el software), moviéndose entre los diferentes niveles de la organización.

Para un arquitecto, es importante estar relevante en tecnologías y tendencias. No se espera que escriba código todos los días, pero sí poder realizar pruebas de conceptos y poder involucrarse con el equipo de desarrollo. También es importante tener habilidades blandas, como la comunicación y la negociación con los diferentes stakeholders. No estar desconectado de la tecnología y poder entender los problemas técnicos que se presentan.

¿Qué compone a un Solution Architect?

  • Conocimiento del dominio de negocio.
  • Conocimiento de la tecnología.
  • Metodologías, procesos y prácticas.
  • Liderazgo y habilidades de comunicación e influencia.

Uno de los mentores un día me contó una gran descripción de un Solution Architect:

Los SA son como un pato, un pato puede nadar, pero no como lo hace un pez; un pato puede volar, pero no como lo hace un pájaro. Un SA no debe ser un maestro en todo, pero debe tener conocimientos en diferentes áreas. Poder idealizar una solución, diseñar cómo se podría implementar y definir el mantenimiento de la misma son cosas que un SA debe hacer.

¿En qué se involucra un Software Architect?

  • Pre-ventas: un SA debería poder tomar un RFP (Request for Proposal) y poder proponer una solución técnica que cumpla con los requisitos del cliente. Poder estimar el costo y el tiempo de desarrollo (Roadmaps) con el PM. Un diseño arquitectónico de alto nivel y decisiones iniciales.
  • En producción, puede ayudar en un proceso de Discovery, realizando workshops on/off site, clarificando temas técnicos con el cliente, como por ejemplo las tecnologías, integraciones y cómo el cliente maneja su TI. Aquí también se hace un diseño de arquitectura y revisión de arquitectura. También hacer una gobernanza de la arquitectura, etc.
  • Entre otras cosas, podría hacer entrevistas, charlas, escribir artículos, etc.

Suena como a muchas tareas, ¿no? Pero principalmente en la etapa del diseño de arquitectura, se compone de múltiples pasos. En este proceso se analizan los Business Drivers, objetivos y las preocupaciones de los stakeholders. Después de tener eso, se obtienen y priorizan los requisitos, porque aquí se pueden identificar los ASRs (Architecturally Significant Requirements), que son los requisitos que afectan la arquitectura de la solución. Después se definen los Quality Attributes principales y qué técnicas (Tactics) se van a usar para poder cumplirlos. Se mira el estado actual de la arquitectura del cliente, y finalmente se diseña y documenta la arquitectura objetivo.

Muchas veces se hace un proceso de Architecture Review, en el que se valida la arquitectura de acuerdo a los business goals actuales y los futuros.

Las Estructuras y Vistas Arquitectónicas

Hay un concepto interesante que intentaré explicar aquí y son los Structure, Viewpoint y Views.

  • Structure: Es la forma en que se organizan los elementos de un sistema y las relaciones entre ellos.
  • Viewpoint: Es una perspectiva desde la cual se puede ver la arquitectura de un sistema.
  • View: Es lo que tú ves, la representación de la estructura.

Entonces un arquitecto diseña estructuras. Y se documentan vistas de esas estructuras.

Dicho esto, un architecture Viewpoint son como un grupo de convenciones para construir, interpretar, usar y analizar un tipo de architectural view. Un ejemplo es una vista de deployment.

Para concluir, es importante entender la perspectiva de los stakeholders, para poder diseñar las vistas adecuadas.

Tipos de Estructuras Arquitectónicas (Architectural Structures)

  • Módulo (Module): Aquí, los elementos son los módulos, que actúan como las unidades de implementación. Esto ayuda a determinar las áreas de responsabilidad de cada módulo.

    • Descomposición (Decomposition)
    • Usuarios (Users)
    • Capas (Layers)

  • Componente y Conector (Component-and-Connector): Los elementos son componentes en tiempo de ejecución y sus conectores, que establecen cómo se conectan entre ellos. Esto ayuda a entender cómo los componentes interactúan entre sí y cómo se mueve la data entre ellos. También se puede comprender cómo cambia la estructura durante la ejecución.

    • SOA (Arquitectura Orientada a Servicios)
    • Basado en Eventos (Event-Based)
    • Cliente-Servidor (Client-Server)

  • Asignación (Allocation): La interacción entre los elementos del software y los ambientes externos, donde el software es desarrollado o ejecutado.

    • Despliegue (Deployment)
    • Implementación (Implementation)
    • Asignación de Trabajo (Work Assignment)

Arquitectura Empresarial (Business Architecture) para SA

Cualquier organización que diseña un sistema (definido de manera amplia) producirá un diseño cuya estructura es una copia de la estructura de comunicación de la organización. - Melvin Conway, 1967

Como lo indica la cita anterior, la estructura de comunicación de una organización se refleja en la arquitectura de software que se produce. Comprendiendo esto, podríamos identificar adecuadamente los módulos y componentes, y asignar correctamente al responsable, lo cual ayuda en este proceso. También es importante comprender que una versión optimizada del diseño de un Arquitecto de Soluciones (SA, por sus siglas en inglés) podría tener un gran impacto en la organización, mostrándole cómo los negocios se podrían llevar a cabo de una manera más optimizada.

Work in progress…

Libros recomendados

  • Software Architecture in Practice 4th edition (Len Bass, Paul Clements, Rick Kazman)
  • Documenting Software Architectures: Views and Beyond, 2nd Edition (Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judith Stafford)
  • Designing sofrware architectures: A practical approach (Humberto Cervantes)
  • Software architecture for developers (Simon Brown)
  • C4 model for visualizing software architecture (Simon Brown)
  • Patterns for Fault Tolerant Software (Robert Hanmer)
  • Release it! Design and Deploy Production-Ready Software, Second Edition (Michael T. Nygard)