Hace mucho tiempo que tenía pendiente presentar la más que importante posición de Solutions Architect, aunque cierto es que en algunas empresas puede ser la misma figura el Solutions Architect y el Enterprise Architect o, simplemente, The Architect. A título personal, y ya por el 2008, hace un poco más de 10 años, que vengo trabajando dichas posiciones: era y es uno de mis retos personales.
A continuación comparto un Diagrama para poder escenificar rápidamente lo que vendría a ser una estructura de Gobierno para la toma de decisiones en Arquitecturas técnicas, teniendo en cuenta tanto la estrategia del negocio, de datos y de software. Veamos:
Como decía anteriormente, aquí se diferencia entre Solutions Architect y Enterprise Architect, en caso que no exista la posición de Enterprise, podríamos asociarla, permitidme que sea entre comillas, a un “CTO”. Pero sería la posición más cercana.
La base de todo, para mí siempre lo será, es la estrategia de negocio. Nunca debería ir nuestra estrategia técnica contra la estrategia de la empresa, más bien, deberá reforzarla. Es por ello que la base de nuestro Gobierno será nuestra visión empresarial y, hay que decir, que para mi un Solutions Architect también forma parte del Business, teniendo la necesidad de conocer procesos y participando en las decisiones.
Un siguiente nivel, sera la metodología, muy importante para poder sustentar nuestras decisiones, ya sean técnicas o no. Aquí podemos encontrar un sin fin de opciones, ya que de metodologías hay más que colores. Pero, son una pieza clave para nuestra organización.
La estrategia de datos, no es exclusiva de los Business analyst o posiciones parecidas, al contrario, los datos nos ayudaran a corroborar y mejorar nuestras decisiones. Sean técnicas por ejemplo o de visión de negocio. En algún que otro post anterior ya hemos hablado de estrategia de negocio a partir de los datos o como los datos nos pueden ayudar a democratizar nuestra empresa.
Seguidamente tenemos pilares, es posible que en nuestra empresa tengamos más de un Producto y, si se permite, poder especializar a ese Solutions Architect por productos o verticales. En caso que no pueda ser, entonces será el uno. Un Solutions Architect es una persona que domina tanto el negocio como la tecnología, dedica un 50% de su tiempo a estar conectado con negocio y el otro 50% con la tecnología. También dedica todo su esfuerzo o casi por completo, a indagar en las profundidades de su Producto, hacérselo suyo y proponer, de forma constante: mejoras.
Seguramente podríamos refinar un poco más lo que sería la visión tecnológica, que iría más allá de las posiciones, pero sin duda alguna quien debería liderar tal es el Enterprise Architect o, como decía anteriormente, el CTO en caso que sea directamente la persona que tenga ese Role.
Recuperemos la metodología por un momento, de nuevo, ya que por ejemplo para poder determinar nuestro camino tecnológico y más, en cuanto a Arquitectura técnica, deberemos tenerla presenta para poder dibujar esa visión tecnológica y, por ejemplo: TOGAF® nos podría ayudar.
Seguramente podríamos detallarlo mucho más, pero sin duda alguna la gobernanza de una proyecto tecnológico es una complicada misión y el poder acompañarse de posiciones estratégicas como la de un Solutions Architect es una más que buena decisión.
Libro recomendación
La recomendación de hoy es el libro de Peter A. High: “Implementing World Class IT Strategy: How IT Can Drive Organizational Innovation”, quien nos dará un más que interesante paseo por la estrategia de IT en las nuevas organizaciones.
NOTA: Recuerda que si pulsas en el enlace del libro, me gano una pequeña comisión sin que a ti te cueste nada extra y me estarás ayudando con los costes de mantenimiento del Blog.
Comentarios, opiniones y valoración: Me gustaría saber qué tienes que decir a través de las redes sociales mediante el hashtag #theninjacto.
Autor: Joakim Vivas