¿Cómo vamos en «arquitectura»?
La palabra “arquitectura”, en creación de soluciones de negocio basadas en software, ha sido utilizada de múltiples maneras a lo largo de los años. Por lo que aún hoy su significado se diluye fácilmente en una conversación de nivel superficial. Para utilizar significativamente palabras como «arquitectura», «arquitecto», «arquitectural/arquitectónico», o incluso «arquitectar/arquitecturar» es necesario indicar con ejemplos o con ideas adicionales cuál es la intención detrás de la palabra. De otro modo se explica lo inútil de las conversaciones o discusiones en las que se utilizan esas palabras y en realidad se refieren a ideas diferentes. Por ejemplo, alguien que proyecta las funcionalidades generales a futuro para una aplicación de negocio, así como los productos cuya adquisición se propone, pero que no es responsable de su diseño detallado, podría decir que define la arquitectura de tal aplicación. Por otro lado, quien tiene en sus hombros la responsabilidad de entregar tal aplicación, o evolucionarla a una siguiente versión con mayor capacidad funcional, con igual o mayor estabilidad, podría decir que se ocupa de la arquitectura real. Probablemente ambos tienen razón, parcialmente.
Reconozco haber participado en ese tipo de discusiones y haber apoyado determinadas perspectivas (ver referencias [3] a [6] más adelante). He buscado entender diligentemente a qué se refieren mis interlocutores en dichas discusiones. También me he remitido a la intención con la que esas palabras se utilizan en la disciplina artística de proyectar edificaciones y ciudades; la arquitectura de hoy que proviene del ejercicio estético de personajes históricos como Vitruvius o Hipodamo de Mileto. Por supuesto, en software estamos a años luz de llegar siguiera a los talones de tal profesar artístico. Tal brecha en los niveles teórico y práctico es otra evidencia de la etapa naciente en la que aún está la profesión de creación de soluciones de negocio basadas en software.
En este contexto, a la fecha, sólo he podido encontrar dos maneras de usar la palabra «arquitectura» con las que se intenta un acercamiento a una interpretación basada más en la virtud que en el vicio, más en la destreza —en el arte— que en el sinsentido, más como los arquitectos de antaño.
Primera: la que maestros como Frederick P. Brooks Jr., e Ivar Jacobson, y otros, enseñan acerca de la usabilidad. La arquitectura es la interfaz de usuario con la que éste concibe al sistema y donde se ve reflejada la integridad conceptual de dicho sistema. La referencia [1] remite más al respecto. Bajo esta perspectiva un arquitecto puede o no dominar los detalles del diseño detallado (también conocido como «código fuente») pero si los domina entonces está en mejor posición para arquitecturar.
Segunda: la que arquitectos como Alan Hakimi proponen bajo la idea del Zen de la Arquitectura. La arquitectura es una forma simbólica para interpretar eficazmente la realidad. Implica creatividad e inventiva de nuevos campos semánticos que proyecten una nueva realidad conceptual sobre la que una organización se transformará. Bajo esta perspectiva no hay necesidad alguna que un arquitecto tenga ni siquiera noción de aspectos técnicos. Pero para ejercer bien este rol el arquitecto requiere contar con una sólida educación científica y filosófica. Al discutir este punto con el propio Alan Hakimi, dado el analfabetismo científico y filosófico tan diseminado en la práctica del desarrollo de software, observo la necesidad de que el mismo individuo interesado sea quien haga algo al respecto de su propia educación. Pues, incluso, tal educación científica y filosófica no sólo es útil para ejercer esta segunda manera de ver a la arquitectura sino también para la primera —la referencia [7] menciona más al respecto.
Referencias