Encuentra aquí algunas recomendaciones que tenemos para alguien que está dando sus primeros pasos en el rol de Arquitecto de Soluciones (SA).

Iniciar con un rol de SA es complicado, ya no te encuentras tan cerca del código y algunas veces tu trabajo es muy similar al de un estudiante de jardín de niños (dibujar rectángulos y colorear).

Para hacer tu iniciación más sencilla, hemos recabado aquí algunas recomendaciones que se alinean con las expectativas de este rol.

deja al equipo aprender

La urgencia de querer arreglar las cosas a punta de código es muy tentadora. Sin embargo, es necesario que permitas al equipo aprender; esto es, dejarlos ser exitosos y fallar por su propia cuenta.

Es importante recordar que tu trabajo más relevante en este punto es ser un facilitador técnico, proveer la vision tecnológica del proyecto, y revisar que las cosas no salgan del margen del diseño que has sugerido (erosión de la arquitectura).

Deja que los ingenieros en el equipo analicen, combatan y aporten información para ayudar a madurar el diseño propuesto.

se realista

Aceptar la realidad es difícil, más aún si ésta no se alinea con las cosas que habíamos planeado; pero está bien, siempre aprendemos cosas nuevas en el camino, o simplemente algo salió mal, y es algo con lo que debes estar bien; no intentes hacerlo funcionar.

Esto no solo aplica hacia ti. Como parte de la cadena de comunicación, es muy seguro que tú debas defender el punto de vista del equipo frente al cliente. Esto requiere estar de acuerdo con los puntos que el equipo de ingeniería haya proporcionado (y a los acuerdos a los que hayas llegado con ellos) para permitirte negociar las opciones disponibles con los clientes.

no tiene que salir a la primera

Un punto que no se suele hablar de forma explícita en temas de arquitectura es que, no es realista pensar que el diseño inicial sea esa bala de plata que funcionará durante toda la vida del proyecto. Eso no sucede en la vida real.

Es posible que tanto el incremento de conocimiento sobre los requerimientos o la evolución durante las iteraciones de un requerimiento, lleven a la necesidad de cambiar la arquitectura. Esto es precisamente parte de la ingeniería que debe aplicarse en el diseño de la arquitectura:

• Analizar el problema actual
• Definir la arquitectura que resuelve el problema
• Definir los parámetros para medir el éxito de los cambios, por ejemplo: mejorar el performance de la aplicación, reducir el tiempo de la publicación de cambios, reducir el tiempo de sincronización de datos, etc.
• Planear cómo/cuándo hacer los cambios
• Vender la idea con el cliente y el equipo de ingeniería
• Medir los impactos y retornos de inversión

aprende los patrones

Existen muchos patrones de diseño, y es seguro que no necesites saber todos desde el día uno, pero puedes comenzar con ponerle nombre a los patrones de los proyectos en los que has o estás participando. Esto te ayudará a entender como sobrellevar algunos de los retos a los que te enfrentas.

Personalmente, encuentro la documentación de Microsoft referente a patrones de arquitectura como una gran fuente de aprendizaje.

Los patrones de arquitectura de software son elementos sobre los cuales siempre debemos actualizarnos, hace unos unas décadas Cliente-Servidor era el modelo arquitectónico más relevante, ahora es algo que para ambientes web se da por sentado y hablamos de: arquitecturas basadas en eventos, arquitectura lambda, etc.

genera documentación

La documentación es de suma importancia, permite que cualquier persona nueva al proyecto pueda entender las decisiones que hemos tomado y los planes que tenemos a futuro.

Hay muchos artefactos que comúnmente se consideran para formar parte del blueprint, estos son los que consideramos más relevantes para iniciar:

• Topología de software - describe todos los componentes existentes del sistema y sus tipos de interacciones.
• Seguridad - indica las puertas de seguridad que tenemos entre nuestros componentes (o hacia el exterior) para evitar ataques.
• Registro de Decisiones de Arquitectura (ADR, por sus siglas en inglés) - Como su nombre lo indica, contiene las decisiones más relevantes para la arquitectura. Por lo general, incluyen elementos que no sean estándares y proporcionan el contexto para entender la razón por la cual se llego al estado actual.

Adicional a los artefactos del blueprint de arquitectura, siempre es bueno documentar las pruebas de concepto para que los desarrolladores inicien las tareas con un punto de partida avanzado.

genera buena documentación

Utiliza diagramas sencillos de entender y reduce el alcance de cada uno, de tal manera que sean fáciles de interpretar para todos. Es muy común involucrar demasiados elementos (interacciones, actores, flujos, etc.) que generan una carga cognitiva alta, la cual podría prevenir al resto del equipo de tener un entendimiento claro de la documentación sin tu asistencia.

Cuando hablamos de documentación de arquitectura, es esperado que consideremos lo siguiente:

• Propósito del documento
• Audiencia
• Problema
• Análisis
• Propuesta de solución
• Impacto
• Suposiciones
• Riesgos

Los puntos anteriores proveen al lector con la información necesaria para entender la sugerencia y perspectiva del equipo técnico, y facilita tener una opinión al respecto.

También, es muy importante aprender a contar las historias. Algunas personas son más visuales y utilizan presentaciones; otras logran capturar sus ideas mejor en texto. Para un SA, saber contar una historia, es relevante ya que ésta será la herramienta más importante para lograr hacer acuerdos con todos los involucrados.

conclusiones

Iniciar con el rol de SA requiere preparación, tanto inicial como continua.

Existen muchas otras cualidades más allá del área técnica, que forman parte del rol: capacidad de negociación, relaciones interpersonales, y habilidades para generar documentación clara y concisa.

Pero si algo hemos aprendido hasta este punto, es que cualquier transición lleva tiempo y esfuerzo, y no debemos esperar ser perfectos, si no mas bien, estar abiertos a escuchar y mejorar de manera progresiva y consistente.