¿Qué es un arquitecto?

Durante 33 años me he considerado un desarrollador. Manejar varios lenguajes siempre ha sido de mi interés y disfruto hacerlo -aun cuando, a veces, puede ser frustrante. Mi primer gran amor al desarrollar fue C y después C++. Pude lograr, después de mucho esfuerzo de equipo e individual, sacar al mercado un producto orientado a la construcción. Tenía miles de clientes y fue el primero en su tipo en tener una versión para Windows 95.  

Recordando esos tiempos he analizado la arquitectura de este producto. Uno de los retos fue crear los componentes para que el software se ejecutará rápido en un equipo de cómputo con muchas limitaciones. Después de mucho investigar, lo logramos; pero se hizo evidente que la falta de lineamientos provoco que la etapa de desarrollo tomará mucho más tiempo del estimado. Conclusión, nuestra arquitectura era casi inexistente. La consecuencia de ello fue la toma de decisiones basadas muchas veces en mis ocurrencias.  

Después de 30 años, reflexiono sobre ¿qué hubiera pasado si hubiese existido un arquitecto para el producto? ¿Qué lineamientos debimos seguir para ajustarnos a las características solicitadas por miles de clientes? ¿Cómo responderíamos a los requerimientos del negocio? 

Existen diferentes tipos de arquitectos: Empresariales, de Soluciones y Técnicos. El conocimiento del arquitecto tiene su base en el conocimiento de muchas áreas, algunas de manera superficial ya que su rol no se basa en el dominio técnico profundo. La forma de enfocarlo está en que el arquitecto conoce un amplio espectro de tecnología, mientas que un desarrollador profundiza más en sus conocimientos técnicos para poder ser un experto (server / cliente o back-end, front-end).  

Desde mi punto de vista, el rol más importante del arquitecto es evitar las ocurrencias del equipo de desarrollo. Definir los lineamientos estructurales de la solución es una de las etapas importantes y trascendentes del arquitecto. La toma de decisiones sobre que tecnologías usar y como serán implementadas es otra de las funciones importantes de un arquitecto. Mediante mapas -blueprints, el arquitecto mostrará el camino a seguir al equipo de desarrollo y establecerá el marco para si en caso de ser requerido se atiendan funciones que impacten a los requerimientos solicitados por el negocio. Y no, no es una actividad de solo unas semanas -generalmente en mis proyecciones indicaba solo dos semanas a arquitectar -un error común. El arquitecto es un enlace también con el negocio para mediante un lenguaje ubicuo -Diseño orientado a dominios, poder traducir el impacto de la arquitectura en el objetivo final y su evaluación en el momento de hacer pruebas de aceptación por parte del usuario. También seguirá la ruta para acompañar al equipo de desarrollo en crear pruebas de concepto, seguir los lineamientos y asegurar la calidad tanto del desarrollo como de la arquitectura seleccionada. La arquitectura y su toma de decisiones está basada en los documentos de requerimientos que son creados por los analistas de negocio -Software Business Analyst.  

Y aquí puede surgir la pregunta: ¿este es el camino que deseo seguir profesionalmente? Antes de decir no a algo, solo inténtalo y podrás decidir si te gusta o no. Mi camino es que en algún momento dejaré de desarrollar -me cuesta cada vez más entender retos de algoritmos. Una parte interesante es que como arquitecto puede uno aportar con conocimientos a los retos que tiene un producto, negocio o solución. Pero de esto hablaremos en otro artículo.