spinner

Qué es un Solutions Architect y por qué tu empresa lo necesita

El Solutions Architect es la figura encargada de crear una arquitectura fácil de comprender para una solución de software y de dirigir estratégicamente el proceso de desarrollo. ¿Quieres saber más sobre este perfil y por qué tu empresa lo necesita? Sigue leyendo.

Muchas empresas en la vorágine de la llamada transformación digital, se preguntan cómo pueden afrontar todos los cambios que requiere la organización. En muchos casos, las empresas hacen este ejercicio de manera interna, evaluando lo que tienen y a lo que quieren llegar de la mano de personas clave dentro de los equipos de IT. Este enfoque queda en muchas ocasiones, asociado a los aspectos más tecnológicos perdiendo la visión de negocio. De esta forma, se pueden llegar a cometer errores en la selección de las soluciones que han de soportar las demandas actuales y futuras de la empresa.

Si en la empresa existe el perfil de Arquitecto de Soluciones (Solutions Architect o SA en adelante), esta tarea de identificar el qué, el cómo y el cuándo, puede resultar más sencilla. El SA velará por la adopción de una tecnología que soporte los requerimientos actuales y futuros del negocio de la empresa, alineando de esta forma a todos los actores involucrados en la transformación y siempre teniendo el foco en el actor principal, el cliente.

Quizás la función más relevante y posiblemente más conocida de los SA es la de convertir los requerimientos de negocio y funcionales de una organización en una solución, que permita cubrir todos ellos con las garantías necesarias la continuidad del negocio.

Si mi empresa no tiene un Solutions Architect, ¿necesito una persona con este perfil?

A lo largo de mi carrera, he ido ejerciendo diferentes perfiles de arquitecto, pasando desde el mundo de la integración y procesos, hasta llegar al de arquitecto de soluciones. Como Solutions Architect, he podido constatar cómo este rol puede ayudar a la compañía con las diferentes etapas de evolución de la tecnología y los procesos relacionados. Sin embargo, antes de contestar a la pregunta que abría este punto, creo que debemos entender qué es la Arquitectura Empresarial y qué papel juega dentro de la empresa.

¿Qué es la Arquitectura Empresarial?

Aunque existen varios marcos o frameworks de arquitectura como IAF de Capgemini, NIST o Zachman, para guiarnos utilizaremos TOGAF (The Open Group Architecture Framework) como referencia dado, que es uno de los más utilizados en la actualidad.

“El Objetivo de la Arquitectura Empresarial es describir los componentes de una empresa, sus relaciones, cómo colaboran e interactúan entre sí. Es el Mapa que proporciona un entendimiento común de la organización y se usa para alinear la estrategia y los requerimientos tácticos.”
— Fuente: TOGAF

En el mundo ideal o en las grandes empresas, existen diferentes tipos de roles de arquitectura. Así podríamos encontrar a los Arquitectos Empresariales (Enterprise Architects) también llamados en ocasiones Arquitectos Globales, a los Arquitectos de Soluciones (Solutions Architects) y por último los Arquitectos de Dominio (Domain Architects). A estos últimos se les puede denominar de diferentes maneras, como puede ser Arquitectos de Disciplina. En estas disciplinas podemos encontrar Infraestructura, Networking, Cloud (si no está incluida en la primera), Integración, Procesos y Datos.

Mención especial, tienen los perfiles de seguridad y es por ello necesario aclarar por qué no ha sido incluido en el párrafo anterior. Si bien muchas empresas consideran el apartado de seguridad como un perfil de Domain Architect, es importante indicar que el SA deberá estar siempre acompañado de quién valide que la arquitectura a entregar cumple con las garantías necesarias de seguridad. Es por ello que los Security Architects, o Security Specialists deberán estar al mismo nivel que los SA. El hecho de no añadirlos como un rol más en la arquitectura es debido a que tienen una función muy concreta y transversal en todo el recorrido de la arquitectura. Tanto es así, que se trata de equipos a los que pueden consultar cualquiera de los perfiles de arquitectura o ingeniería. Su trabajo puede estar integrado en cada uno de los documentos o entregarles de arquitectura o incluso, disponer de su propio documento anexo a cada uno de ellos.

Podemos imaginar estos perfiles de arquitectura como si de una pirámide se tratase.

Solutions-Architect

Dentro de dicha pirámide hemos visto como podría ser una distribución de los roles, entendiendo que se necesitarán más roles específicos de especialistas en las diferentes tecnologías. No debe interpretarse que el número de arquitectos que aparece en cada nivel es el que debe existir, se trata únicamente de un gráfico explicativo.

Los arquitectos están involucrados en todo el Ciclo de Vida de Desarrollo de Software (SDLC o por sus siglas en inglés), siendo su intervención más importante dentro del ciclo, en la fase de Diseño de la Solución.

Cada uno de estos roles, tiene unas funciones y responsabilidad concreta en la arquitectura de la empresa:

  • Enterprise Architects (EAs): deberán tener una visión global, enlaza con la toma de decisiones y la estrategia de la compañía, disponiendo de un canal de comunicación directo con la alta dirección. Deben abstraerse del detalle de la tecnología desplegada en la empresa, manteniendo el foco en el largo plazo de la estrategia técnica. Han de trabajar en conocer las nuevas y futuras tecnologías y sus capacidades dado que pueden ser claves para la evolución de la empresa. Son los encargados de definir los Principios de Arquitectura que se han de seguir, la aprobación o selección de proveedores de soluciones que las garanticen y las recomendaciones en su uso y adopción. Un ejemplo de ello basado en las decisiones de dirección tecnológica a adoptar sería, si la empresa debe o no pivotar hacia un mundo totalmente en la nube, híbrido o bien, permanecer en on-premise. Como nota diremos que también son conocidos como Global Architects.
  • Solutions Architects (SAs): serán los encargados de transformar esas decisiones estratégicas-tecnológicas y utilizarlas en soluciones que se adapten a las mismas cumpliendo con los principios de arquitectura. Trabajarán en la adopción de herramientas o piezas de software que permitan desplegar esas capacidades en la compañía. Su visión debe estar totalmente asociada a la de negocio y sus procesos. Es aquí, donde la figura del Technical Leader (especialista de la tecnología de un dominio de negocio) ayuda al SA con el conocimiento necesario de estos procesos. El diseño de arquitectura no sólo ha de atender a las demandas de la estrategia de la empresa, si no que además deberá soportar los requerimientos actuales y de futuro que puedan plantear las áreas de negocio sin perder el impacto que pueda suponer a los clientes. Fruto de su trabajo será el documento de Modelo de Solución de Arquitectura (en SDLC se define como HLD – high-level design), en el que han de converger diferentes visiones (negocio y procesos, cumplimiento, seguridad, etc.) de una manera sintetizada para ayudar y guiar a los Domain Architects y equipos de ingeniería o desarrollo en su trabajo. Es por ello qué podríamos decir que los SAs están a mitad de camino entre la decisión estratégica y los equipos de tecnología. Un ejemplo de ello podría ser la adopción de una solución SaaS para cubrir un área funcional de la compañía.
  • Domain Architects (DAs): cuando el SA entrega el documento de solución de arquitectura con una pieza de software o una solución concreta, son los DAs por medio de su especialización quiénes se ocupan de cada una de las áreas técnicas del mismo. Como ya se ha indicado, tendrán perfiles que pasarán por Infraestructura, Networking, Cloud, Integración, Procesos y Datos. Dependiendo del tipo de solución y del área implicada, el DA deberá completar su parte en el documento de Modelo de Referencia Técnica (en SDLC se define como LLD- low-level design) detallando cada uno de los elementos que intervienen en la arquitectura. Este documento junto con él acompañamiento a los equipos de ingeniería o desarrollo serán su función concreta, velando que el entregable cumple con todo lo indicado en los documentos de arquitectura. Este perfil, también ha de trabajar de manera muy estrecha con el Technical Leader, pues deberá validar que se cumplen los requisitos establecidos para el soporte de negocio.

No todas las empresas tienen la posibilidad (por tamaño o madurez) de tener un equipo de arquitectura tan extenso y segmentado. Dado ese caso, al menos sí es recomendable disponer de un perfil intermedio capaz de intermediar entre la arquitectura empresarial (cerca de las decisiones estratégicas) y de los equipos de desarrollo (en ocasiones haciendo de arquitecto de dominio).

Por supuesto, estos perfiles pueden llegar a encontrarse en consultoras y ser perfiles que puedan tener un recorrido en el tiempo en el que la compañía realice su transformación o adopción de su arquitectura, aportando los entregables correspondientes a su perfil y ayudando a los equipos de la empresa en el objetivo propuesto.

¿Qué puede aportar un SA?

Entre las tareas de SA no está únicamente el de la generación de documentos de solución de arquitectura. Si no existe un perfil de EA en la empresa, el SA también deberá realizar las hojas de ruta (roadmaps) de la evolución de la arquitectura conforme la empresa vaya modificando sus procesos, ajustando las capacidades, extendiéndolas o suprimiéndolas, si es el caso.

Este mapa de arquitectura, deberá mostrar las capacidades funcionales asociadas a las aplicaciones o soluciones desplegadas. En él, se definen los escenarios de situación actual, a corto-medio plazo y a futuro. Éste se irá actualizando conforme se actualizan las aplicaciones o las capacidades necesarias en la empresa, ajustando los escenarios para reflejar la realidad. La información del mismo puede bajar desde el departamento la funcionalidad, la aplicación, su ubicación hasta la infraestructura.

En algunas empresas toda esta información está contenida en un repositorio de arquitectura. Existen aplicaciones específicas para generar este repositorio. Por ejemplo, basado en el framework definido por TOGAF tenemos ArchiMate.

TOGAF define a la una visión más completa y a la forma de uso de dicho repositorio como el modelo “Enterprise Continuum”. En otras ocasiones se utilizan portales documentales con una determinada estructura o gestores de proyecto que contienen toda la documentación asociada.

Es importante indicar que toda la documentación antes citada, podrá tener más o menos detalle, dependiendo de la implicación de los arquitectos (o del SA) en los diferentes dominios. Es por ello que en algunas empresas, el SA es el encargado de generar la información de arquitectura a alto nivel mientras, los arquitectos de dominio o los responsables de las áreas (aplicación, red, infraestructura, seguridad, integración, datos, etc.), añaden todo el detalle a la misma.

Dentro de este repositorio también estarán incluidos todos los documentos que hayan sido realizados por los arquitectos, cómo los Modelos de Solución de Arquitectura o los Modelos de Referencia Técnica (TRM en TOGAF).

Sea como fuere, toda esta información, ha de ser mantenida y enriquecida siempre para poder ser consultada en cualquier momento teniendo siempre una visión realista de la arquitectura.

“La arquitectura empresarial determina qué artefactos de arquitectura y soluciones incluye una organización en su Repositorio de Arquitectura. La reutilización es una consideración importante en esta decisión.”
— Fuente: TOGAF

¿Cómo trabaja un SA?

Ya se han comentado varias de las funciones que debe realizar un SA como son el alineamiento con negocio y la estrategia tecnológica de la empresa, mantener el repositorio de arquitectura o la generación de modelos de solución. Es precisamente la creación de ese documento una de las tareas principales de los SA y para ello, hemos de entender qué es un modelo de solución de arquitectura.

Se trata de la documentación que genera el SA para detallar los requisitos funcionales y no funcionales y soluciones de arquitectura en los que esté involucrado. Si bien TOGAF propone una estructura para este documento, lo ideal es adaptarla dependiendo de las necesidades o responsabilidades que puedan tener las diferentes áreas técnicas. Esto determinará el nivel de detalle de dicho documento.

Dentro de un Modelo de Solución, podemos encontrar estos tipos:

  • Modelo de adopción: cuando se debe generar una arquitectura sin partir de una arquitectura previa
  • Modelo de evolución: cuando se dispone de una arquitectura previa que debe ser evolucionada o transformada
  • Modelo de retirada: cuando se dispone de una arquitectura previa que va a ser desmantelada. En algunas empresas esto es asumido como un modelo de evolución en el que se detalla qué elementos serán retirados. Pero cabe destacar que en empresas en las que el cumplimento obliga a disponer de los sistemas o datos por un tiempo determinado, existe la posibilidad de generar una documentación de arquitectura específico para este fin

Para generar estos modelos de solución, los SA suelen plantear sus documentos de arquitectura en base a “lo que hay” y “lo que debería ser” (en inglés As-Is / To-Be). Aunque pueda parecer que en un modelo de adopción esto no tiene cabida, no es del todo así, dado que es posible que se pueda reutilizar alguna de las piezas de arquitectura existente que dé servicio a otra solución. Este es precisamente uno de los pilares del Repositorio de Arquitectura, fomentar la reutilización.

En los otros dos modelos de solución (o bien para el de evolución sí sólo se considera este), esta visión del “As-Is” es siempre necesaria. Gracias a ella el documento podrá reflejar lo que hay tanto a nivel funcional (llegando si se quiere a los procesos soportados), las aplicaciones, sistemas, integraciones y algo muy importante, los datos.

Posteriormente, el arquitecto deberá desarrollar el diagrama o diagramas de la solución de arquitectura a la que se quiere llegar “To-Be”, así como cubrir todos los apartados antes indicados con aquellos cambios que permitan llegar a la solución planteada. Aquí es donde un SA por medio del conocimiento de las capacidades tecnológicas, los flujos de negocio involucrados y también las limitaciones en los diferentes ámbitos impactados, planteará una solución acorde y realista sin dejar de lado la estrategia, cumpliendo con los principios de arquitectura y siguiendo las recomendaciones por parte de la EA. Es importante señalar que el SA validará el planteamiento de arquitectura conjuntamente con el Technical Leader, dado que han de comprobar que soporta los requerimientos establecidos por el negocio.

Dependiendo de la estructura de IT de la empresa, el SA deberá detallar en mayor o menor medida ese documento de solución de arquitectura. En muchas empresas, hay definidos unos procesos de decisión que pueden atender a diferentes aspectos, siendo los que marcan la implicación del SA, así como el tipo de documento que debe realizarse dependiendo de la tipología de proyecto. Estos documentos pueden mostrar una descripción de alto nivel de las piezas involucradas y cómo estas interactúan entre sí, o bien llegar al “grano fino” y determinar apartados como la infraestructura con los nombres e incluso las direcciones IP’s de los servidores, etc.

Como ya se ha indicado antes, hay empresas en las que ese detalle es suministrado posteriormente por los Domain Architects o los responsables de cada área. Toda esta información detallada, puede añadirse al documento de modelo de solución de arquitectura como anexos, aunque, todo ello suele quedar más como reflejo en los documentos de diseño técnico como los Modelos de Referencia Técnica en los que se detallan aspectos mucho más particulares de las piezas involucradas por áreas de domino.

Como es lógico, toda esta documentación generada por los SAs, los DAs o los diferentes equipos técnicos, se añadirá al repositorio de arquitectura. Esta información deberá estar correctamente versionada y mantenida en el tiempo y disponible para que cualquier área de la empresa (no sólo IT), pueda acceder a la misma si fuese necesario.

Los Solution Architects deben generar arquitecturas estándar, alineadas con la estrategia de la organización, aportando el soporte técnico, funcional, de seguridad y fiabilidad que requieren los procesos de negocio.

El SA en la organización

La implicación de los SA en los procesos organizativos de las empresas suelen quedar definidos por los flujos de trabajo en los que son requeridos. Cada empresa dispone de un modelo organizativo de concepción y desarrollo de tecnología que se ajusta a sus necesidades y a los equipos de trabajo. En TOGAF, este flujo que enlaza procesos organizativos con la arquitectura empresarial, se denomina ADM (Architecture Development Method). Se trata de un flujo de fases iterativas definido para el soporte del ciclo de vida de la arquitectura empresarial. Este ciclo puede ser moldeado en base a las necesidades y madurez de la organización, así como el alcance que requiera la arquitectura en la misma.

“El ADM es iterativo, a lo largo de todo el proceso, entre fases y dentro de las fases”
— Fuente: TOGAF

Para evitar centrarnos en cada una de las fases que define TOGAF, haremos un breve recorrido por los puntos más importantes del trabajo de Solutions Architect en una organización.

  • Fases iniciales – definición de la Arquitectura: se centran en el contexto organizativo, gobierno y alcance que debe tener la arquitectura empresarial. En ellas se definen conceptos como los modelos de trabajo, la visión y los Principios de Arquitectura. Será con estos dos últimos puntos, con los que comienza el trabajo de un SA, ya que deberá alinear los requerimientos de negocio a los mismos. Como hemos comentado anteriormente, estas tareas suelen recaer en los Enterprise Architects.
  • Fases intermedias – ejecución de la Arquitectura: en ellas se dará comienzo a el diseño de la arquitectura de negocio destino, atendiendo a cómo deben ser soportados y apoyados los objetivos de negocio. Es en este punto en el que el SA, colaborará de manera estrecha con los responsables de las soluciones y negocio para dar forma a la solución de arquitectura.En la fase de ejecución de un proyecto los SA, contribuyen al éxito del mismo en su relación con las áreas o disciplinas de desarrollo, aportando cuando es necesario, una visión más concreta de la arquitectura o bien, retroalimentando sus diseños para adaptarlos a los nuevos requerimientos.
    De esta forma, su trabajo estará vinculado a la definición de la hoja de ruta de la arquitectura, la planificación del desarrollo de la misma, las fases de despliegue, los planes de migración e incluso, la gestión del cambio.
  • Fases finales – gobierno de la Arquitectura: finalmente, cuando la solución de arquitectura ha sido desplegada, el SA, deberá responsabilizarse que todas las nuevas piezas o bloques, plataformas o servicios, quedan correctamente definidas y catalogadas. Ello permitirá un gobierno de la Arquitectura Empresarial, que aportará un conocimiento del estado de los sistemas que componen la arquitectura, dotando a la misma, de la capacidad de reutilización, evolución y retirada de los sistemas que la componen, atendiendo a los requerimientos de los procesos de la organización.

Teniendo esto en cuenta, ¿necesita mi empresa un Solutions Architect?

A lo largo de esta entrada, ya se ha visto cuáles son los diferentes roles de arquitectos IT, sus responsabilidades y lo que aportan. El adoptar o no un perfil de este tipo en una estructura de IT dependerá de la empresa y sobre todo, del grado de madurez de la misma. En ocasiones algunas de las funciones de los SA son asumidas por otros roles y puede parecer que el resultado es el mismo. Sin embargo muchas veces, ese compendio de información y conocimiento que debería existir como repositorio de arquitectura, se encuentra diluido en múltiples repositorios departamentales, sin la posibilidad de adopción de una visión común.

Los Solution Architects son parte del crecimiento de la estrategia de la empresa, aportando piezas en las que se sustentan los cambiantes requerimientos de negocio. Democratiza la tecnología, ayudando a la adopción de piezas consolidadas. Y por supuesto, está constantemente aprendiendo sobre nuevas tecnologías y piezas desarrolladas en la organización o sobre los nuevos procesos de negocio que han de ser soportados.

Así pues, deberán de ser los responsables de IT junto con la dirección de negocio, quienes se planteen si realmente necesitan este rol o, si pueden continuar dando soporte a la estrategia de negocio asumiéndolos en los procesos que disponen.

Fuente de la imagen principal: Freepik

Las opiniones vertidas por el autor son enteramente suyas y no siempre representan la opinión de BBVA Next Technologies.

¿Quieres saber que más cosas hacemos en BBVA Next Technologies?