Rol del Arquitecto: Reglas del Juego

 Una  de las principales razones por las que ha venido siendo tan dificil definir qué es un arquitecto es por la falta de acuerdo en cuanto a lo que un arquitecto debe hacer. Cómo distintas perspectivas le asignan a dicho rol distintas responsabilidades, por consiguiente el rol en sí mismo pasa a ser diferente según la perspectiva de donde se lo evalúe

Esto me empezó a dar vueltas en la cabeza estos últimos meses, ya que con Simon estuvimos trabajando fuerte en el número 15 del Journal de Arquitectura, próximo a aparecer (*). El tema de este decimoquinto número es, justamente, el Rol del Arquitecto

Como siempre hubo un call for papers (que tuvo lugar durante el pasado mes de Enero), y varias propuestas fueron recibidas, de las que escogimos unas siete u ocho. De estas seleccionadas fueron luego llegando los primeros borradores, por lo que puedo decir que me he pasado el trimestre que va terminando dando vueltas cuan pollo al spiedo alrededor del bendito rol que nos toca jugar

Y lo que puedo anticipar de la edición que estás por recibir es que, como era de esperar, varios artículos se parecen entre sí en el sentido que hablan de un personaje con el que nos identificamos; pero al mismo tiempo discrepan entre sí, porque le atribuyen responsabilidades o conductas que nos puedan sonar cuestionables

Entonces pensé que, como siempre, el origen de las divergencias se remonta a la clásica subdivisión del perfil de arquitecto en

  • Arquitecto Empresarial (o Estratégico)
  • Arquitecto de Desarrollo (o Soluciones)
  • Arquitecto de Infraestructura

Yo asumo que esta subdivisión ya la manejás de taquito, pero si ése no es el caso, leéte este artículo de Simon que lo cuenta bastante claro

La clasificación no está mala y, sobretodo, no es algo que un solo vendor impuso sino que hay no sólo un consenso en la industria: el framework de arquitectura conocido como TOGAF (The Open Group Architecture Framework) considera cuatro Dominios de Arquitectura (Architecture Domains). Estos son, a saber:

Pero no termina acá, también la IEEE a finales de los ’90 dio forma a su especificación IEEE 1471 (forma corta de referirse a Práctica Recomendada para la Descripción Arquitectónica de Sistemas de Software Intensivo), un estándar tanto ANSI como ISO. Esta especificación define Puntos de Vista (Viewpoints) nuevamente asignables a los roles antes descriptos

 

Y sin embargo…

 

Esta taxonomía está bien para organizar información relacionada con estos -tomando prestado de TOGAF- dominios de arquitectura antes descriptos. Pero no tengo claro que en la práctica necesariamente se dé que haya, en una misma organización, arquitectos cubriendo estos roles. No estoy diciendo que esté bien que sea así o que esté mal, sino que en la medida en que estos roles van madurando, las organizaciones ya venían lidiando a su modo con las necesidades a cubrir. Como resultado, tenemos que

  • Una misma persona cubre algunas actividades de uno o más roles, pero no todas las actividades que a ese rol le suelen asignar hoy los estándares
  • Un dado proyecto en una determinada organización puede requerir cierto nivel de cumplimiento con la definición de una arquitectura, pero a un nivel de detalle que puede resultar escaso según las normas de otra organización
  • Distintas organizaciones, partiendo de la base de que tienen distinto tamaño y diferente presupuesto de TI, lidian con distinto headcount (cargos a cubrir disponibles). Como resultado, las tareas de arquitectura a realizar se van a asignar al personal disponible (nuevamente conduciendo a que la relación entre roles y personas termine siendo cualquiera a cualquiera en lugar de 1:1, 1:n, m:n, etc

 

Me siento lejos de la postura de decir que si en la práctica las cosas se dan así, es porque algo esté saliendo mal. Me ha tocado trabajar en proyectos donde ciertas decisiones que afectan a la arquitectura estaban ya tomadas (por ejemplo, plataforma J2EE contra base de datos Oracle sobre ambiente Linux, etc). Siendo esas las circunstancias, un arquitecto de infraestructura tenía poco margen de acción en cuanto a tomar decisiones de plataforma se tratase. Sin embargo, aún le cabía un rol preponderante en el despliegue de la solución (y la asignación de procesos a servidores, etc). No obstante, en los hechos, esta actividad de infraestructura terminó en más de un caso siendo cubierta por el "arquitecto" (así, en genérico) que era también el que diseñaba la solución a desarrollar. Obviamente que no cualquier arquitecto de soluciones podía estar ducho en la infraestructura elegida de antemano, como para definir la mejor manera de montar la solución, pero justamente eso era lo que hacía que ciertos proyectos atraigan a cierta gente que habría quedado al margen en otros proyectos que compartieran ciertas similitudes y ciertas diferencias (por ejemplo, plataforma .NET disparando transacciones vía Host Integration Server contra un CICS el que, a su vez, accede a una base de datos DB/2)

 

Podríamos concluir que los roles oficiales tienen aparejados una serie de actividades, pero que en la práctica de ese menú total de actividades habrá algunas que van a ser cubiertas en forma total, otras parcialmente y aún otras ignoradas

Estas actividades van a ser asignadas a diferentes arquitectos (en genérico) pero no necesariamente según rol sino considerando, en cada caso, el conocimiento que tengan del negocio y la cultura de la compañía, de la plataforma de desarrollo y de los ambientes de ejecución. En ese contexto, no va a ser descabellado aprovechar el expertise de un miembro del proyecto en -digamos- aplicar sintonía fina (fine tuning) a un esquema en Sybase, si bien su actividad principal sea la de definir y liderar el desarrollo de un framework de acceso a datos que encapsule la complejidad de APIs como JDBC o ADO.NET

Será tarea del líder de proyecto, en base a las circunstancias actuales del mismo, definir qué actividades de arquitectura estarán presentes y en qué grado, y a quién/es serán las mismas asignadas

____________________________________
(*) A propósito, desde el número 3 hasta el 14 (el actual) están disponibles en español

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

Una respuesta a Rol del Arquitecto: Reglas del Juego

  1. Juan Pablo dijo:

    Hola,
    Que buen Post sobre la disciplina de Arquitectura.
    El problema del rol de arquitecto pasa por dos factores ambientales de su trabajo.
    Primero que están en un área de trabajo, informática, que es muy inmadura.
    Segundo, su trabajo a diferencia de un programador o analista es  mucho más abstracto, por lo que el resultado de su trabajo puede ser expresado de diferentes maneras lo que ayuda a la confusión del rol.
     Salu2

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s