La industria del software siempre ha sostenido la premisa básica de que la arquitectura es importante. Por asociación, el papel del arquitecto siempre se ha considerado importante, pero lamentablemente, no siempre está claro qué es la arquitectura o cuál debe ser el trabajo de un arquitecto.
¿Se necesitan arquitectos, o puedes tener grandes equipos de desarrollo? Si se necesitan, ¿qué deberían hacer? ¿Necesitan sentarse en torres de marfil? Si no tienes gente con el título de «arquitecto», ¿aún necesitas gente que haga ese trabajo de forma efectiva? Para responder a estas preguntas, necesitamos tener claro qué es la arquitectura.
¿Qué es la arquitectura de software?
Hay varias definiciones, pero me gusta un par que Martin Fowler ha escrito y hablado:
y
Las cosas importantes podrían ser cosas como el código, la comprensión del dominio/negocio o las interacciones del sistema. Podría incluir cosas con altos niveles de abstracción; tal vez los detalles de cómo interactúan los múltiples microservicios. O podría ser a niveles bajos, como un algoritmo de datos particular que es crítico para su negocio. Esta confusión hace difícil ser exacto en lo que es la arquitectura, pero si le preguntas a los técnicos superiores del proyecto, definitivamente tendrán una respuesta.
Sin embargo, si ese conocimiento de lo importante no se comparte entre los miembros del equipo, entonces la arquitectura pretendida se oculta con el tiempo y corre el peligro de ser suplantada. Si la mayoría de los desarrolladores creen que algo más es más importante, eso se convierte en la arquitectura de hecho. O peor aún, si no hay un entendimiento común, entonces las cosas se convierten en una anarquía y el sistema se convierte en un enredo.
Un entendimiento común de cómo funcionan las cosas podría provenir de un código limpio, documentación u otros tipos de comunicación. Puede ser difícil mantener el entendimiento del sistema en la cabeza, por lo que esto explica por qué los diagramas de arquitectura y otros documentos se crean tan a menudo para compartir el entendimiento entre los miembros del equipo.
Si combinamos las definiciones y decimos que la arquitectura del software es «un entendimiento común de cómo funcionan las cosas importantes», entonces se deduce que la arquitectura impacta a cada desarrollador (y probablemente a otros también, como las operaciones y la seguridad) y ellos la impactan a su vez.
El papel de un arquitecto
Dada la definición anterior, un arquitecto debe ser alguien que pueda identificar correctamente las cosas importantes, ser capaz de explicarlas y evangelizarlas. Los conocimientos técnicos son fundamentales, pero no suficientes. El papel de un arquitecto incluye la comprensión del valor empresarial, el pensamiento y el diseño de sistemas y la comunicación.
Valor comercial
La elegancia o la creatividad de una arquitectura es irrelevante si no aporta valor. En el contexto de una empresa, ¿la arquitectura ayuda a la empresa a cumplir sus objetivos? ¿Mantiene los costos bajos y permite los cambios que generan ingresos? En el contexto de un proyecto de código abierto, ¿la arquitectura permite que el software pueda cumplir sus objetivos? Un arquitecto debe estar comprometido con la empresa para poder comprender estos objetivos.
Gregor Hohpe escribe que «la arquitectura rara vez es buena o mala – es apta o no apta para el propósito». Él plantea que un arquitecto necesita interactuar con el liderazgo y presentar la arquitectura como «opciones de venta». ¿Cómo será la arquitectura (especialmente a un alto nivel) buena para el negocio? ¿O los tecnólogos sólo están haciendo lo que creen que es limpio o siguiendo ciegamente la estrategia de otras empresas? El artículo también dice: «Las empresas deben invertir más en la arquitectura que les permite aplazar las decisiones».
En , nuestros arquitectos han adoptado «un enfoque de principios para la arquitectura». Este enfoque comienza con la identificación de objetivos estratégicos como la entrega rápida de experiencias sorprendentes, la orientación a los datos y la seguridad. A continuación, decide qué principios apoyan esos objetivos, como equipos multifuncionales, infraestructura de nube o pequeñas bases de código. Luego, enumera qué prácticas van junto con esos principios; cosas como la entrega continua, el desarrollo basado en pruebas o la minimización del acoplamiento entre equipos. Este enfoque le ayuda a alinear sus objetivos arquitectónicos con el valor empresarial.
Pensamiento de Sistemas y Diseño
Un arquitecto necesita ser capaz de entender y diseñar las cosas importantes. Este es posiblemente el aspecto mejor entendido del papel de un arquitecto.
Un arquitecto debe ser capaz de describir la arquitectura y explicar cuáles son los puntos fuertes y débiles. Siempre hay compensaciones, y el arquitecto debe ser capaz de explicar por qué se tomaron las decisiones y para qué se seleccionaron las cualidades.
A medida que los sistemas crecen, se vuelven más complejos y pueden surgir nuevos comportamientos. Los arquitectos necesitan tener habilidades de pensamiento sistémico que les permitan predecir y planificar el cambio. ¿Es la arquitectura flexible, lo que hace fácil continuar creciendo y cambiando? ¿O es rígida y propensa a ralentizar el negocio?
Comunicación
Volviendo al aspecto del «entendimiento común» que forma parte de la arquitectura, es crítico que un arquitecto sea capaz de ayudar a otros a entender las partes importantes así como las razones detrás de ellas.
Cuanto más grande es una organización de desarrollo, más difícil e importante se hace este trabajo. Si los equipos no están alineados con la arquitectura, es probable que se desvíen del curso e introduzcan nuevas complejidades. Una de las mejores maneras de ayudar a los equipos a mantenerse alineados es que el arquitecto pase tiempo codificando con ellos y entrenándolos. En lugar de dar instrucciones como mandamientos desde lo alto, el arquitecto debe estar abierto a la colaboración y a las ideas de los que están más cerca de los problemas.
En un artículo sobre los arquitectos en las organizaciones empresariales, Kevin Hickey dice que cuando trabajas en varios equipos, «tu papel ya no es tomar decisiones, sino ayudar a otros a tomar la decisión correcta y luego irradiar esa información». «No creo que eso signifique que un arquitecto no sea responsable de hacer ninguna elección, sino que sus elecciones deben ser generalmente a niveles más altos de abstracción (fuera del área de trabajo de un equipo) y que no deben ser imponentes para los equipos. Deje que los equipos hagan su trabajo y asuman su propia responsabilidad por ello. En cambio, el trabajo del arquitecto se trata de influir. Se trata de promover una visión, construir puentes y facilitar la educación.
Una señal de que un arquitecto ha hecho bien su trabajo es que los equipos entienden cómo encajan en el panorama general, y pueden hacer su trabajo de forma independiente sin impactar negativamente en el sistema.
En , una de las formas en que facilitamos un entendimiento común es a través de una reunión semanal del «Gremio de Arquitectura». Cualquiera es bienvenido a asistir y animamos a cada equipo a enviar al menos un representante. Durante la reunión tenemos presentaciones y discutimos temas relacionados con el sistema mayor para los equipos de desarrollo y operaciones.
La arquitectura afecta a todos
Dado que hemos definido la arquitectura en términos de comprensión de los aspectos importantes de un sistema, el papel del arquitecto es, en efecto, un papel clave para una organización de software, sin el cual nos exponemos a los riesgos de no satisfacer las necesidades de la empresa o de que la gente tire en direcciones opuestas.
Eso no significa necesariamente que tenga que haber alguien con el título de Arquitecto, pero alguien debería desempeñar ese papel. Muchos de los buenos promotores que conozco comparten sin duda alguna algunas de las habilidades de un arquitecto. En algunos casos, yo diría que ellos son arquitectos, aunque normalmente para un subsistema, como en el caso de los contextos delimitados de $0027s. Está bien (incluso es preferible) tener arquitectos en diferentes niveles de abstracción.
Cada sistema tiene una arquitectura, ya sea intencional o no. Si no quieres que la tuya se convierta en un desastre al azar – o quieres que se recupere de serlo – entonces necesitas buenos arquitectos y personas comprometidas con el avance de ese entendimiento compartido.
Categorías: cultureTags: architecture