Un colega hace unos días me preguntó que podía leer para poder mejorar su conocimiento, básicamente pidiendo consejo sobre cómo partir ya que tiene muy poca experiencia programando, lleva solo unos meses trabajando y aún está terminando su carrera. Bueno luego de conversar con él para saber que esperaba, que estaba interesado en aprender y cual era el foco de la pregunta, me confesó que le gustaría llegar algún día a ser arquitecto de software, por eso se acercó a hablar conmigo, porque pese a tener un cargo de arquitecto si no más de gestión, a falta de un arquitecto he estado supliendo el rol en la empresa donde trabajo.

La verdad es que no le quise contestar de inmediato, pese a que lo primero que se me vino a la cabeza fue el libro de patrones de diseño del GOF, o los videos de clean code de Martin Fowler, no me pareció sensato que partiera por ahí, puede ser mucho digerir para cuando uno recién está partiendo, y no me malinterpreten, no tiene que ver con capacidad, ya que creo que aprende muy rápido y está alcanzando el paso del resto de los programadores de la oficina, sin embargo es empezar por el lugar incorrecto, pese a este ser conocimiento crucial para un arquitecto, siempre es mejor partir por la base, poner los cimientos firmes y duraderos para que el resto de las cosas encaje de manera coherente y no se tengan que dejar espacios. Además por otro lado en una pelada de cable vía chat con mi amigo Gómez (que últimamente es la única forma de comunicación que estoy teniendo con él) le dije que me hacía falta y que yo no conocía un manual de referencia de arquitectura de software, donde se tocaran no sólo las técnicas de arquitectura de software, sino además las herramientas y los conocimientos necesarios, para que uno pueda consultarlo y repasar cuando haga falta, quedamos de tomarnos un café y pelar el cable para ordenar la idea y hacer una especie de investigación si encontrábamos material adecuado para ello. Cuento corto juntando las dos cosas voy a escribir algunas entradas adicionales a mi blog que trate temas de arquitectura y conocimiento sobre arquitectura de software, la idea es que sea una guía de referencia y no un lugar donde se describe y define a cabalidad cada uno de los conocimientos, por lo que puede ser que falte posteriormente una investigación sobre el tema tratado, o incluso se puede solicitar que ahonde en el tema en caso que algo no halla quedado claro.

Bueno dejándose de rodeos, partiremos por lo temas más básicos, ¿que es la arquitectura de software? y ¿que se necesita para ser arquitecto?, primero, se confunde generalmente la arquitectura de software con la ingeniería de software, yo creo que la arquitectura de software forma parte de uno de los procesos de la ingeniería de software, mientras la ingeniería de software se preocupa del proceso de creación software completo, con una visión sistemática y completa, la arquitectura de software se enfoca sólo al proceso de diseño de un producto o sistema, donde no solo se tiene que preocupar del diseño de los algoritmos involucrados en el desarrollo, sino tener una visión general mucho más amplia teniendo clara las interacciones del software y enfocándose en los diferentes puntos que implican calidad del mismo, Philippe Kruchten lo explica mucho mejor que yo, dice:

”La arquitectura de software, tiene que ver con el diseño y la implementación de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto número de elementos arquitectónicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos de desempeño de un sistema, así como requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y disponibilidad.”

Pese a no estar de acuerdo con Philippe Kruchten en aspectos metodológicos, que tienen que ver con la ingeniería del software más que con la arquitectura, creo que su definición es bastante acertada y me quedo con ella.

Y ahora ¿que se necesita para ser arquitecto?, me parece que es una lista de características que puede llegara ser infinita, por lo que sólo resumiré algunas de las que encuentro más importantes.

  • Conocimiento: Claramente una característica de un arquitecto de software es el conocimiento, de la plataforma, de la forma de trabajar, del negocio, de la tecnología y del equipo, no es necesario que lo sepa todo a la perfección, ya que para eso son los especialistas, pero sí debe tener el conocimiento suficiente para poder tomar decisiones que ayuden a mejorar la sinergia de todos los aspectos mencionados, ya que todas esas son las aristas de conocimiento que se deben tomar en cuenta, que se saca con impulsar una iniciativa de tecnología si nadie puede trabajar en ella, o hace que el negocio responda lento y sea inviable, o que no se tengan los medios económicos necesarios para soportarla.
  • Experiencia: No solo el conocimiento teórico es necesario, entre las funciones del arquitecto está lidiar con personas y problemas de la tecnología, y problemas que en teoría no ocurren y problemas que en la teoría ocurren y están bien documentados, pero en la práctica no son importantes o que el modelo de negocio está construido de tal forma que tales condiciones no se dan, para esos casos la experiencia es necesaria y absolutamente importante.
  • Liderazgo y negociación: No vivimos en un mundo ideal donde todo el mundo nos espera y podemos escribir un código muchas veces hasta que estemos orgullosos de ellos, estamos supeditados a tiempos, plazos, expectativa y factores humanos, es por eso que un buen arquitecto debe saber qué hacer, cómo lidiar con las circunstancias y que sacrificios hacer para poder cumplir con las expectativas y plazos, sin dejar de lado la motivación al equipo, la capacitación constante al mismo y trabajar como facilitador para eliminar problemas y prácticas que entorpecen el desempeño normal y correcto del equipo.
  • Visión del negocio: Una de las cosas más importantes bajo mi punto de vista, la informática es una ciencia de apoyo, y, amenos que sea en un contexto de investigación, no se hace arquitectura de software por arquitectura de software, si no para resolver problemas en función del negocio, no hay que perder de vista el negocio, el arquitecto es la pieza clave que debe tener la capacidad de alinear los proyectos con la realidad tecnológica y hacerlos coexistir en función del negocio y las metas de negocio.