Carrito de compras

Historia de dos arquitecturas

22 jun. Ilustración de infraestructura

En la novela "Historia de dos ciudades" del escritor británico Charles Dickens, se retrata una historia que trascurre en dos países en los albores de la Revolución Francesa: una de las ciudades se refiere a París, y la otra a Londres.  En contraposición, una de las ciudades simboliza la paz y la tranquilidad, mientras que la otra representa el caos y la agitación.

Tomando prestada la referencia del señor Dickens, me referiré el día de hoy a dos perfiles de pensamiento en nuestro entorno tecnológico, que he podido identificar en los años que tengo de experiencia y que en cierto modo refleja formas diferentes de realizar nuestro trabajo y que con ciertas diferencias, aplica tanto a arquitectos de soluciones, como ingenieros de software, desarrolladores, entre otros, pueden ponerle el nombre que gusten, donde de alguna u otra forma, sin que nos demos cuenta cuenta, caemos dentro de uno u otro esquema.

Imaginemos por un lado, un arquitecto de soluciones con una amplia experiencia en el diseño y construcción de soluciones tecnológicas, cuyos trabajos a lo largo de los años, reflejan un proceso de construcción muy estandarizado y muy similar entre todos sus trabajos, utilizando tecnología y tendencias del momento en que fue diseñado y construido.  Es un profesional muy reconocido en la industria por sus recursos tecnológicos y también por sus colegas.

Por otro lado, hay otro arquitecto, que igual que el anterior, posee amplia experiencia en el diseño y construcción de soluciones igualmente exitosas, cuyo historial operativo refleja implementaciones muy diferentes entre sí, empleando en cada uno de ellos metodologías y tecnologías diferentes, en algunos casos quizás no tan avanzadas técnicamente como se hubiera deseado, y en otros casos, con soluciones brillantes, y cuyos trabajos mantienen una tasa de aceptación y fidelidad, por parte de los usuarios finales, extremadamente alta, siendo muy buscado y recomendado por estos.

Es cierto que hay escalas de grises entre ellos, pero para efectos de este artículo, piense, por un segundo, entre estos dos modelos únicamente, y considere (no importa si es arquitecto, desarrollador, QA, codificador, etc) en cuál de ellos está y en cuál de ellos desearía estar.

Y no se trata de decidir si uno es mejor que el otro (cada uno presenta sus ventajas y desventajas claramente) si no, de esos dos perfiles, donde se encuentra, si le gustaría cambiar, y ante esa reflexión, preguntarse ante todo ¿Por qué?

Para uno de ellos, la arquitectura y la tecnología es un fin en sí mismo.  Trabaja para que su diseño sea tecnológicamente superior.  Para el otro, la arquitectura y la tecnología son meras herramientas.

Sin ser realmente conscientes de ello, poco más, poco menos, nos encontramos diseñando y trabajando bajo alguno de estos dos perfiles. 

Como profesionales en el mundo de la tecnología, de alguna forma en nuestro ADN está "codificado" el querer experimentar y utilizar la última tecnología disponible.  Nos encanta aprender, dominar nuevas herramientas y emplearlas en nuestro siguiente proyecto ¡Y eso está muy bien!  Es algo que también se espera de nosotros.

El problema surge cuando se diseñan las soluciones para utilizar la metodología “W”, plataforma “X”, el lenguaje “Y” o el framework “Z”, sin que antes nos preguntemos ¿son las herramientas que se requieren para hacer el proyecto de la mejor forma?

Se cae inconscientemente en el pecado de construir soluciones complejas, terminando con soluciones que utilizan "sobre-ingeniería" en mucha parte de su arquitectura o código.  Se ha escuchado el término, se conocen los riesgos que conlleva, pero ¿realmente intentamos evitarla?

Con facilidad, se olvida el por qué decidimos entrar a este mundo de TI en primer lugar no es sólo porque nos encanta la tecnología, es porque también nos encanta solucionar problemas.  Y para eso se nos contrata.

Es nuestro deber el no perder de vista que no construimos soluciones para las máquinas, construimos soluciones para las personas. 

Aquí es donde entra el punto de vista del segundo arquitecto, donde la tecnología no es el fin en sí mismo, sino una herramienta.  Este profesional conoce las tecnologías, sabe lo que hacen e incluso sabe que pueden existir dos formas de hacer lo mismo, una quizás más “pro” que la otra, pero no sólo porque existe, debe usarla.  Sabe cómo y cuándo debe aplicarlas para solucionar un problema de la mejor forma (y muchas veces, lo clásico es lo mejor) 

Conoce las metodologías, y sabe que son guías de buenas prácticas, pero sabe que cada proyecto, cada cliente, es diferente, y sabe cómo debe aplicarlas “by the book” y cuando hay que reacomodarlas, sin caer en un anti-patrón, claro está.  Ese equilibrio es vital en un arquitecto.

Este profesional conoce muy bien a sus usuarios, y está comprometido con su satisfacción y el valor que su solución les entrega.

Este profesional sabe que muchas veces menos, es más. 

El atacar la complejidad de una solución desde el inicio, con esquemas de trabajo y tecnologías simples, sin caer en la sobre-ingeniería, pero que permitan composición y mejoramiento progresivo, y con el compromiso como profesional de entregar valor a los usuarios con la solución, es una ruta viable de éxito del proyecto y fidelidad de los usuarios.

Pero ese, será un tema para otro artículo.

Manrike Villalobos Báez | Productivity Architect | Ingeniero en Sistemas

¿Te gustó? Entonces comparte la publicación: