Cuando una empresa decide crear un departamento de Arquitectura surge la duda de qué tipo de arquitectos deberían conformar dicho departamento.
Dependiendo del papel que juega la Entreprise Architecture en la empresa, y en la medida que ese papel varía, también lo va a hacer la composición del departamento.
Existen diversos tipos de arquitectos; cada uno tiene un cometido distinto y, por ende, buscamos características distintivas entre ellos en conocimientos, habilidades y responsabilidades, así que, si hay distintos tipos de arquitectos, ¿cuáles debo tener?
Tipos de Arquitectos
Sería lógico pensar que, como comentamos en el artículo pilares de la arquitectura empresarial, si son 4 los pilares sobre los que se soporta la Arquitectura Empresarial, deberían existir 4 tipos de arquitectos. Y así es, pero no de forma limitante. Existen algunos otros tipos de arquitectos a considerar.
Antes de ver con qué tipos de arquitectos, aceptados de forma general, podemos encontrarnos, ¿qué es un arquitecto?
Un arquitecto IT define soluciones a los problemas de negocio mediante la aplicación razonada de las tecnologías de la información, verificando que la implementación final de esas soluciones son conformes a la solución diseñada.
Como que esas soluciones pueden ser de diversa índole, establecerse en distintas capas y con disintos niveles de profundidad, deberemos disponer de distintos tipos de arquitectos capaces de dar esa respuesta que el negocio espera obtener.
A la hora de establecer esas soluciones, cada arquitecto pondrá el foco en un aspecto distinto, se aproximará más a la parte tecnológica de la solución o a la de negocio, profundizará más o menos en el foco que le ocupa, y le dedicará un tiempo distinto.
NOTA: no pretendo realizar un Job description tipos de arquitectos, sino una relación con una descripción básica. Posiblemente hayas oído nombrarlos de formas distintas a las que propongo aquí, pero las que establezco son las más habitualmente utilizadas.
Enterprise Architect
Se enfoca en alinear las estrategias y arquitecturas de IT con las del negocio, traduciendo la visión y estrategias de negocio en cambios efectivos en el panaorama tecnológico y en las aplicaciones que le dan soporte, determinando cómo evolucionar; es por tanto un planificador con un rol multidisciplinar a alto nivel.
Debe contemplar los distintos dominios de la arquitectura, tener un elevado conocimiento del negocio, visión global, marcarse objetivos a largo y medio plazo, interlocutar con negocio y el CIO, y crear ‘roadmaps’ que habiliten el cambio deseado.
Domain Architect
Por dominio nos referimos a alguno de los pilares (disciplinas) en los que se asienta la arquitectura empresarial y que vimos en el artículo antes mencionado; podemos verlos como los “cortes verticales” en la arquitectura empresarial. Siendo 4 los pilares (lo que se demomina el BDAT en algunos frameworks de arquitectura), 4 son los arquitectos de dominio que existen.
Todos ellos tienen un rol vinculado a una única disciplina y juega un papel de diseñadores.
Algunas empresas entienden como dominio “cortes horizontales”, que se orientan a líneas de producto o de negocio, en vez de cortes verticales. Nosotros trataremos los verticales.
Business Architect
Se enfoca en interpretar y contextualizar la estrategia y objetivos de la empresa a efectos de garantizar que realiza sus operaciones de forma eficiente, manteniendo alineadas las capacidades que proporcionan los sistemas de información con dichas estrategias y objetivos, asegurando que los procesos de negocio van a estar respaldados por los sistemas de información convenientemente para que no existan impedimentos en la materialización de dichas estrategias y objetivos.
Debe tener contacto estrecho con las áreas de negocio y conocer bien tanto la cadena como los flujos de valor de la empresa, así como las capacidades de los sistemas actuales a la hora de soportar los procesos de negocio.
No es tema de este artículo, pero no, no es lo mismo un Business Architect que un Business Analyst, aunque existen puntos en que entroncan, ni es lo mismo una cadena de valor que un flujo de valor.
Application Architect
Se enfoca en usar de la mejor forma las tecnologías concretas con la que está hecha una aplicación de la que es responsable; realiza el diseño a alto y, quizás, a bajo nivel, que provee del detalle de la arquitectura final de la aplicación de la que es responsable.
No sólo tiene conocimiento de las tecnologías usadas en esa aplicación, sino que conoce perfectamente qué funcionalidades provee la aplicación, con quién y cómo se integra, el modelo de datos subyacente, el código de la aplicación, etc.
Technology Architect
Se enfoca en usar de la mejor forma los elementos de infraestructura requeridos por las aplicaciones y en incorporar nuevos elementos que permitan subsanar deficiencias o plantear soluciones mejores (innovación técnológica); realiza el diseño a bajo nivel que provee del detalle de la arquitectura final de las infraestructuras de la que es responsable.
No sólo tiene conocimiento de las infraestructuras usadas, sino que conoce perfectamente qué servicios ofrecen y sus relaciones.
Information Architect
Se enfoca en usar de la mejor forma los activos de información requeridos por las aplicaciones, y en determinar el valor que se obtiene de la explotación de esa información; realiza el diseño de bajo nivel que provee del detalle de la arquitectura de datos sobre la que deben operar las aplicaciones (qué repositorios y bajo qué modelos), cómo debe estar securizada, por quién debe der ser accesible o cómo debe de ser distribuida.
No sólo tiene conocimiento de los almacenes de datos, sino que conoce perfectamente sus estructuras, relaciones y tecnologías.
Solution Architect
Se enfoca en obtener una solución global (end to end) al problema concreto a solventar en función de los requerimientos de negocio y técnicos, haciendo que todos los dominios de la arquitectura se conjuguen en la medida y proporción adecuadas para conformar dicha solución.
Juega un doble rol: diseñador y coordinador multidisciplinar, que debe proporcionar la arquitectura final de alto nivel del proyecto en el que participa, asegurando que las soluciones se ajusten al diseño establecido.
Habitualmente es la persona del área de arquitectura que está en contacto directo con los arquitectos de dominio.
Deberá tener conocimiento de los sistemas y soluciones de la empresa, así como de los componentes tecnológicos que las sustentan y de aquellos que, no formando parte del ‘stack tecnológico’ de la empresa, puedan ser necesarios en un futuro inmediato como parte de una arquitectura de solución.
Otros tipos de arquitectos no tan comunes
Los tipos de arquitectos habituales son los que hemos enumerado, pero puede haber otros, en función del contexto de cada empresa.
Aquí te explico un par que hemos creado ex profeso, por necesidades concretas que nos han empujado a ello, pero puedes tener otros, en los que no voy a entrar, como el Cloud Architect, si tu empresa está muy basada en el la nube, o el Business Intelligence Architect, si tu empresa pone mucho foco en temas de inteligencia de negocio, o distintos Platform Architects que se centren, cada uno de ellos, en algún componente tecnológico del que la empresa dependa o apueste mucho, como pueda ser una herramienta de EAI como WSO2, o una herramienta de RPA, como UiPath, etc.
Integration Architect
Se enfoca en conformar soluciones de integración, tanto internas como internas, entre distintos sistemas que deben interactuar entre ellos. Estas integraciones pueden ser tanto centradas en aplicación como centradas en datos.
Deberá tener conocimiento sobre las distintas capacidades de integración que disponen las aplicaciones y componentes tecnológicos de la empresa, los servicios que prestan y que pueden exponer, quizás, en forma de API, así como de sus almacenes de datos y los flujos de negocio que provocan la interacción entre aplicaciones.
Cobran un rol muy importante cuando hablamos de las denominadas composite applications.
Security Architect
Se enfoca en establecer los mecanismos de seguridad necesarios para que los sistemas minimicen los riesgos a los que están expuestos, y puedan responder adecuadamente en caso de producirse una brecha de seguridad.
Deberá tener conocimiento en las distintas tecnologías de seguridad de la empresa y de cómo éstas son usadas y por qué en los distintos sistemas.
No voy a comentar si este tipo de arquitecto debe depender del CISO, y por tanto del área de seguridad, o del área de arquitectura; cada empresa debe decidir, pero este arquitecto debería existir (o al menos su función).
¿Y el Chief Architect?
No, no me olvido del Chief Architect, Architecture Director o Architecture Leader; es quien dirige el departamento de arquitectura pero no quien hace el trabajo de campo, de ahí que no lo aborde en este artículo.
¿Qué tipos de arquitectos debería tener?
No todas las empresas tienen las mismas problemáticas ni objetivos.
Decidir con qué tipo de arquitectos conformar el departamento dependerá de esas problemáticas/objetivos que el área de IT, con el CIO al frente, requiera alcanzar.
En mi caso, el departamento está integrado por los siguientes tipos de arquitectos:
- Solution Architect
- Technology Architect
- Application Architect
- Integration Architect, que asume un papel muy importante como API Product Manager.
Si bien ejerzo de Chief Architect, trato de desempeñar también el rol de Enterprise Architect, ayudado por el resto de mis compañeros, pero es algo que espero cobre sentido por sí mismo en un futuro no muy lejano.
Conclusión
Como hemos visto, el elenco de arquitectos depende de tu “película particular”; es muy amplio, y debes escoger aquellos que sean capaces de solventarte la papeleta, según los objetivos que requieran alcanzarse o problemas a solventar.
En mi caso particular, en el que he desempeñado el rol de Chief Architect en 2 empresas (llamémoslas A y B), me he visto inmerso en 3 tipos de problemáticas / objetivos principales muy distintas que han sido los detonantes de la conformación de un departamento de arquitectura y que han marcado la tipología de arquitectos inicialmente requerida:
- Falta de acomodación de las estrategias de IT respecto de las de negocio → se ha dado en A
- Dispersión de sistemas y tecnologías → se ha dado en A y en B
- Abordar un cambio de tecnologías y arquitecturas (pasar de un sistema monolótico altamente acoplado a una arquitectura de microservicios) → se ha dado en B
En función de las problemáticas a la que te enfrentes y el tipo de empresa, deberás optar por unos arquitectos u otros; no puedes, por tanto, optar por una estrategia de “café para todos”.