El rol de un arquitecto de soluciones suele requerir altos conocimientos técnicos al igual que funcionales, en varias ocasiones se encarga de ser ese puente entre la arquitectura empresarial y la arquitectura técnica.
En el siguiente artículo, hablaré un poco acerca de cómo ha sido mi experiencia como arquitecto de soluciones para un proyecto en específico.
¿Cuál fue la oportunidad de negocio o el problema que abordó este proyecto? ¿Cómo se relaciona con el negocio y la misión del cliente?
La empresa se encarga principalmente de la gestión de seguros de arrendamiento.
El requerimiento era la de una solución en la que sus socios comerciales pudieran autenticarse en un portal web existente de la empresa, permitir una verificación de crédito de sus clientes, así como la posibilidad de firmar un contrato en nombre de un arrendador y un arrendatario.
¿Cuál fue el alcance y la complejidad de la oportunidad de negocio o problema?
El cliente ya poseía un portal web para tratar con el mercado privado individual y la oportunidad comercial se limitaba a crear una solución que pudiera integrarse sin problemas al entorno existente, otorgando acceso a las partes interesadas comerciales y reformulando la estrategia para cumplir con los nuevos requisitos de negocio.
La solución requería implementar varias estrategias comerciales, integración con terceros proveedores, reutilización de la base de datos existente sin comprometer la infraestructura, seguridad o experiencia del usuario.
¿Cuál fue su relación y cómo fue la comunicación con la gestión de clientes y de usuarios?
La comunicación con el cliente se mantuvo fluida desde el inicio, me convertí en contacto clave para el cliente junto con otro arquitecto que lamentablemente tuvo que marcharse poco tiempo después del inicio del proyecto.
Como quería conocer bien a los usuarios, decidí trabajar cerca con ellos durante un período de tiempo para comprender sus inquietudes. Asistí a varias reuniones de socios de negocios para hablar con los gerentes y con los usuarios al inicio del proyecto con el fin de escuchar sus necesidades.
Mis funciones abordaron la recopilación de requisitos, dividiéndolos en atributos funcionales, de restricción y de calidad, reuniéndome con las partes interesadas para comprender sus necesidades, contacto frecuente con la administración del cliente sobre la solución futura y explicando el presente y la visión.
De igual forma trabajé con la arquitectura de la solución de alto nivel y con el modelo de datos y lo presenté al resto del equipo de desarrollo. Mi rol como arquitecto de soluciones se situaba entre la arquitectura funcional y la arquitectura técnica, ya que tenía que trabajar tanto con los requisitos funcionales del cliente, así como con el equipo de desarrollo a cargo de la implementación técnica.
Diría que una de las situaciones más complejas con las que tuvo que lidiar el proyecto estuvo relacionada con la entrega de nueva solución que respondiera a las altas demandas de los requisitos comerciales manteniendo la solución existente para el mercado privado sin interrupciones en el tiempo de actividad y de experiencia de usuario.
¿Cómo se capturó, documentó, aclaró, perfeccionó, detalló, priorizó y aseguró la integridad de los requisitos funcionales y no funcionales?
Al comienzo del proyecto, realizamos varios talleres con las diferentes partes interesadas para comprender las necesidades, los objetivos y las limitaciones del negocio. Más tarde, los arquitectos del equipo de entrega capturaron los requisitos y comenzaron a clasificarlos en requisitos funcionales y no funcionales, dichos requisitos se capturaron y se almacenaron en una base de datos, los requisitos se aclararon uno a uno con el cliente y fueron refinados por el equipo de arquitectos.
Luego, el cliente junto con los arquitectos del equipo de entrega los priorizaría y se aseguraría de que cumplieran con las necesidades comerciales antes de convertirlos en historias de usuarios.
¿Cómo se explicó el estado presente y futuro (visión)?
Con el fin de obtener el consenso de la gerencia del cliente, se llevó a cabo una presentación en la que se detalló el diseño de la arquitectura de la solución y de qué manera se podría resolver el problema comercial, así como también de qué manera el equipo de desarrollo podría lograrlo en el marco de tiempo estipulado.
A los desarrolladores se les presentó la solución de manera más técnica, descomponiendo la arquitectura en varias piezas de bloques de construcción técnica desde el contexto hasta el nivel de código, evaluando los diferentes puntos finales que el portal haría uso en base a estándares abiertos, el consenso y las posibles decisiones, las cuales se registraron en tarjetas de registro de decisión de arquitectura.
Los requisitos comerciales se dividieron y se registraron en una tabla. Los requisitos funcionales y no funcionales en una columna y las historias de usuario/trabajo arquitectónico en otra, haciendo coincidir cada requisito con cada historia de usuario específica.
¿Cómo medió las diferentes opiniones de las partes interesadas?
Hubo diferentes opiniones entre los desarrolladores sobre el uso de tecnologías de contenedores (específicamente el uso de Docker) durante la implementación de los servicios en Microsoft Azure. Un lado quería usar contenedores y el otro lado no. Esta diferencia de opiniones persistió hasta que invité al equipo de desarrollo a un taller en el cual se explicaron las ventajas y desventajas de usar contenedores para este proyecto en específico.
El equipo de desarrollo decidió no usar dicha tecnología. La decisión se registró en una tarjeta de registro de decisión de arquitectura y se archivó para ser utilizada en una retrospectiva.
Dado el alcance del trabajo de arquitectura de soluciones que se debe lograr, describa cómo formuló la dirección, influyó en la forma del trabajo y dirigió al equipo de desarrollo.
Lo primero era obtener el mandato de aprobación por parte de mi empleador como arquitecto lead. Luego me dediqué a conocer mejor al cliente y a las partes interesadas. Los primeros días se utilizaron para explicar la visión de la solución y cómo podría resolver las necesidades del negocio.
También tuve la oportunidad de guiar al equipo de desarrolladores a cargo de convertir los requisitos comerciales en soluciones técnicas, introduciendo la visión general de la solución, explicando las diferentes capas de arquitectura, configurando el entorno de desarrollo, prueba y producción, eligiendo la tecnología para cada API, aplicación y base de datos.
Durante la fase de construcción ayudé al equipo guiándolos en el desarrollo de los diferentes servicios hasta la finalización del proyecto.
¿Qué habilidades de liderazgo utilizó para llevar a cabo su tarea?
Diría que una combinación de empatía, pensamiento estratégico, creatividad, escucha activa, construcción de relaciones, mentoría y toma de decisiones.
¿Qué estándares se requirieron en la solución?
La mayoría de los estándares fueron definidos por el cliente, otros eran regulaciones propias del país de adopción, se adoptó el estándar ISO/IEC/IEEE 42010:2011, GDPR (UE), Finanstilsynet (Noruega), ISO/IEC 20000-1, ISO 22301, WCAG 2.0, entre otros.
Describa las decisiones arquitectónicas que tomó y cómo determinó, documentó y comunicó esas decisiones para respaldar y racionalizar el diseño de su solución.
Hubo varias decisiones arquitectónicas en este proyecto, como, por ejemplo, cómo estaría compuesto el sistema, cuales tecnologías a usar, el método de desarrollo, estrategia de implementación, estrategias de comunicación, entre otros.
La mayoría de las decisiones tuvieron fundamento en el diálogo con las diferentes partes interesadas, entendiendo los estándares actuales, las necesidades del negocio y un ajuste frente al problema que presentaba el cliente.
Las decisiones se documentaron en una serie de tarjetas de decisiones arquitectónicas en las que el equipo explicaría la situación, estrategia decidida, los pros y contra de la decisión, la factibilidad de la implementación de dicha decisión y la estrategia de reversión.
Las decisiones se comunicaron a todas las partes interesadas.
¿Cómo evaluó la integridad técnica, la coherencia y los riesgos inherentes de la solución?
Fui responsable de la evaluación de la solución en el proyecto realizando una evaluación de riesgos con el fin de identificar el nivel inicial y residual de los riesgos, así como su gestión, incluyendo la identificación continua de riesgos, evaluación, mitigación y definición de medidas de contingencia, seguimiento y control y la medición de la eficiencia de identificación basada en técnicas de gestión de riesgos del estándar TOGAF.
De igual forma se evaluó la seguridad teniendo en cuenta áreas de interés como autenticación, autorización, garantía, disponibilidad, protección de activos, administración y código, así como pruebas unitarias y pruebas de integración de la solución, trabajando en conjunto con el líder de proyecto para evaluar la agilidad del equipo después de los informes de la herramienta de seguimiento, y de la capacidad del equipo para asumir las tareas pendientes.
Describa cómo seleccionó, empleó y construyó modelos apropiados para hacer inferencias y justificar el diseño de la solución o para responder preguntas arquitectónicas.
El modelo de arquitectura más usado fue el modelo C4 de documentación para la arquitectura de software creado por el arquitecto de software Simon Brown.
El modelo C4 consiste en un conjunto de diagramas para visualizar la arquitectura en 4 capas.
El modelo ayudó a comunicar de forma clara desde el contexto de alto nivel de la solución, pasando por los contenedores, los componentes, hasta llegar a la capa de código.
También se utilizó el Lenguaje Unificado de Modelado (UML) para visualizar el diseño de las Apis al igual que la especificación Archimate para describir la relación entre los dominios comerciales en la solución, así como una adaptación del estándar TOGAF.
¿Cómo identificó los elementos que ponen en riesgo la integridad de los aspectos de la arquitectura de la solución?
Elaboré una matriz de riesgos como parte de una estrategia de mitigación de riesgos realizada al inicio del proyecto que incluía la posibilidad de que el riesgo suceda y la consecuencia de dicho riesgo, así como la descripción del riesgo y la acción a tomar.
Durante el desarrollo del proyecto extenderíamos dicha estrategia para incluir la identificación continua de riesgos, evaluación, mitigación, definición de medidas de contingencia, seguimiento, control y medición de la eficiencia de la identificación.
¿Cómo se determinó que la solución cumplía con los criterios de validación de la arquitectura documentada?
Se definieron y ejecutaron un conjunto de estrategias, como las pruebas de aceptación del usuario junto con el cliente para validar que los flujos funcionales cumplían con los criterios de la arquitectura de la solución, así como la realización de pruebas de integración realizada por el equipo de desarrollo para asegurarse de que todas las integraciones en la API eran exitosas.
Realizamos una demostración del sistema al final de cada sprint para mostrarle al cliente cómo se comportaba el sistema y anotar cualquier desviación de los requisitos comerciales iniciales.
También se creó un plan de lanzamiento y entrega, de igual forma, las variaciones fueron registradas, priorizadas y trasladadas a un backlog donde los desarrolladores podían trabajar en su mitigación.
¿Qué podría haber hecho diferente en el proyecto?
Siento que pude haber documentado mejor el conocimiento comercial y técnico del equipo anterior que trabajó en la primera solución, así como haber planificado una mejor transferencia de conocimiento del anterior equipo de arquitectura.
De igual manera, me hubiese gustado haber podido realizar el programa de entrenamiento de IASA Architect Core antes de este proyecto, ya que el curso proporciona una buena base al igual que herramientas relevantes para el éxito de un arquitecto empresarial o técnico.
Fuentes
https://btabok.iasaglobal.org/architecture-decision-record/
https://www.scrum.org/resources/what-is-a-sprint-retrospective
https://www.opengroup.org/archimate-forum/archimate-overview
https://twitter.com/simonbrown
https://www.iso.org/standard/50508.html
https://www.finanstilsynet.no/
https://www.iso.org/standard/70636.html
https://www.iso.org/standard/75106.html
https://www.w3.org/WAI/standards-guidelines/wcag/
https://www.opengroup.org/togaf
https://en.wikipedia.org/wiki/Acceptance_testing
https://en.wikipedia.org/wiki/Integration_testing
https://www.scrum.org/resources/what-is-a-sprint-in-scrum
https://iasaglobal.org/Public/Learn/Course-Offerings/Certified-IT-Architect—Foundation.aspx
