Unitarios vs Federales
Si alguien creyó que las patentes son siempre sobre asuntos novedosos, bueno, habría que reconsiderarlo. En el año 1990, Hewlett Packard patentó una forma de detectar si una rutina de software corría sobre un procesador 286 o un 386. ¿Cómo? Algún iluminado en HP vió que el procesador Intel 386 había implementado unos nuevos bits en el registro de estatus que en el 286 estaban siempre en 1. Entonces dijo: ah, entonces si trato de poner en cero esos bits y no puedo, ¡es un 286! Eureka. Sin ponerse colorado, HP fue y lo patentó. Acá abajo, el diagrama de flujo de este “método”:
Ahora, si uno tuviese la posibilidad a mano de una rutina similar pero para detectar un buen ingeniero/a de Sistema de uno medio pelo, probablemente consistiría en poner a esta persona a cargo de un sistema donde la arquitectura física y la funcional (a veces llamada también arquitectura lógica en ciertos círculos ingenieriles sistémicos) no coincidan. ¿Qué quiero decir con esto? Veamos primero qué es una función en un sistema.
Cualquier sistema complejo hijo de buen vecino es una “bolsa” de funciones. Por ejemplo, una pava eléctrica1 tiene que contener la función “calentar agua”—o, para ser más precisos, “incrementar la energía cinética promedio de las moléculas del fluido contenido”—si pretende ser usada como tal. Ahora bien, si la pava calienta el agua usando energía eléctrica a través de una resistencia para transferir calor por conducción, usando un magnetrón o fisión nuclear, eso ya forma parte de la arquitectura física. En cualquier caso, la función debe estar sí o sí; cómo la implementamos es una decisión nuestra y esa decisión suele estar formateada por la coyuntura: costo, simplicidad, seguridad, regulaciones, etc.
A medida que la complejidad del sistema crece, la cantidad de funciones que contiene obviamente crece. Además, la composición interna de éstas se vuelve más jugosa y la interacción entre funciones también se vuelve más complicada. Y ahí es donde se puede desatar el desastre.
Uno puede ir por lo simple: una arquitectura federada. En estas, se asigna una función exclusivamente a un elemento físico que la sintetiza. Entonces, todo está alineado y contenido. Es simple identificar los límites y las interfaces porque todo está bien demarcado. Hay que decirlo, diseñar arquitecturas federadas es como jugar en modo “beginner”. Es fácil ser ingeniero de sistemas de arquitecturas federadas, porque no hay mucho trabajo mental que hacer. La función sigue la forma, y viceversa. Uno puede señalar con el dedo funciones porque estas viven dentro de componentes fácilmente identificables. El gran problema de las arquitecturas federadas es que son, para usar un término estrictamente científico, fofas. Tienen tendencia a subutilizar recursos; en muchos casos resulta prohibitivo asignar una y solo una función a un bloque físico. Por ejemplo, en aeroespacio, ahorrar peso es fundamental y tener computadoras que hacen una y solo una cosa es un lujo que ya nadie se puede dar. Pero además temas como consumo de potencia y otros menesteres no suelen ser el fuerte del estilo federado. Como si esto fuera poco, las arquitecturas federadas fomentan la formación de “silos”. Ya vamos a ver qué significa esto.
Por otro lado, en arquitecturas integradas o unitarias, función y forma se divorcian para siempre y, dependiendo de la lucidez de la ingeniería de sistemas presente, puede ser en malos términos. En este tipo de arquitecturas se combinan varias funciones en un bloque o componente físico. El mapeo directo se rompe para siempre y ahí es donde se pone más picante. Porque además la sociología mete la cola. Tenemos que volver a la famosa observación de Mel Conway hace más de 60 años atrás, quien dijo, palabras más, palabras menos:
— Che guarda que la arquitectura de un sistema y la forma en que se agrupa la gente que lo diseña están más relacionadas de lo que ustedes creen, eh.
Lo que el bueno de Mel nos intentaba decir es que, además del problema de que todo se vuelve más confuso cuando los componentes físicos de un sistema y sus funciones no son más uno a uno, también tenés el problema de cómo la gente que lo diseña va colaborar. Porque resulta que la gente necesita interactuar y comunicarse para poder ingenierear algo bien y de repente se encuentran con que lo que antes era una pregunta de escritorio a escritorio y un make all ahora es un documento de requerimientos, tres reuniones de kick off y un proceso de calidad de 500 páginas porque ahora el software corre en una unidad de otro grupo como librería estática. Es fácil ver que el impacto va a ser considerable. La función ya no juega más de local ni tampoco la gente que la entiende y la maneja.
Si vos tenías un sistema complejo con arquitectura federada donde una función primordial era sintetizada por una cajita mágica que contenía todo: hardware, software, sistema operativo y la mar en coche, todo bien acoplado y de golpe te ponés creativo y decis: no, ahora voy a redistribuir esta función en estas otras cajitas en pos de cierta supuesta “eficiencia”, muy probablemente rompiste todo. Se rompió todo porque ahora la integridad de esa función quedó sujeta además a las fuerzas sociológicas descritas por don Conway.
Se entiende, sin embargo, que muchas veces el enfoque federado crea burbujas o “tribus” que crecen aisladas de la civilización y de ahí surgen intentos de conquista que no siempre terminan bien.
¿Hay solución? O hay que dejar todo como está y no tocar absolutamente nada? Bueno, como mínimo, hay que apuntar a que aquellos que toman las decisiones vean que al jugar con funciones y componentes físicos están jugando con cierto fuego. Es decir, con un orden establecido que va más allá de cables, procesadores y código fuente. Fundamentalmente, ese orden incluye un componente del sistema que tiende a ser olvidado: cierto bípedo implume.
No es que esté llamando “sistema complejo” a una pava eh, es un ejemplo nada más.