Sonata software and the genealogy of BIM – Preview with dark background and typographic style, BIM Culture by Factory268

Sonata, el BIM y el software pre-Revit

Umberto Rinaldi

Si preguntáramos por ahí quién inventó Revit, la respuesta sería casi siempre la misma: Autodesk. Año 2000, más o menos. El software que cambió la forma de diseñar edificios, nacido en algún laboratorio californiano junto con el resto del catálogo de Autodesk. Es una respuesta cómoda, pero es incorrecta.

Revit no nace de la nada, y tampoco nace de Autodesk —que lo compra en 2002, cuando el producto ya existía desde hacía años. Nace de una herencia técnica que comienza mucho antes, de una época en la que el 3D era considerado ciencia ficción y el resto del sector seguía encantado con el 2D de AutoCAD, lanzado hacía apenas tres años.

Existe un software, de 1986, que ya hacía cosas que hoy consideramos obvias: muros que "saben" albergar puertas y ventanas, vistas que se actualizan solas, un modelo que se comporta —no por casualidad— de una manera sorprendentemente familiar. Se llamaba Sonata. Y antes de llegar a Revit, su historia pasa por un ático, un préstamo bancario y un acuerdo frustrado por un desplome bursátil que nadie podría haber previsto.

Sonata nace en un ático

Jonathan Ingram en 1986 tiene 24 años. Ya trabaja en el sector; en GMW Computers contribuyó a Rucaps, uno de los primeros intentos serios de llevar la lógica 2D de plantas y secciones hacia algo más parecido a un modelo. Pero para Ingram no es suficiente. Mientras otros se conforman con añadir vistas 3D a un sistema pensado para el 2D, él ve algo más: un modelo único, paramétrico, donde cada objeto conoce sus propias relaciones con los demás: muros que reconocen las aberturas, vistas que se mantienen sincronizadas por sí solas, detección de colisiones, renderizado integrado.

Una idea demasiado grande para quedarse dentro de la empresa en la que trabaja. Así que se va. No abre un estudio, no encuentra un socio, no busca financiación de capital riesgo. Pide un préstamo bancario, se compra una estación de trabajo y se encierra en un ático. Literalmente: es allí donde trabaja, solo, durante dos años.

Es la escena que en una película sería el montaje de la transformación: el protagonista aislado, obsesionado con una idea que nadie a su alrededor está viendo todavía, mientras el resto del mundo avanza convencido de que el 2D es suficiente. El genio en el garaje, solo que aquí el garaje es un ático en Londres y la idea no es un ordenador, sino el primer verdadero antepasado del BIM.

En 1986 el trabajo ha terminado. El software se llama Sonata. Sale al mercado un año antes que ArchiCAD, quince años antes que Revit, y causa sensación. Gana premios. Ingram, por el trabajo realizado en Sonata (y en lo que vendrá después), recibirá años más tarde la Prince Philip Gold Medal, uno de los mayores reconocimientos de ingeniería británicos. Pero la verdadera pregunta no es qué construyó. Es cómo, porque lo que hay dentro de Sonata es donde comienza realmente la historia que nos lleva a Revit.

Vintage/tech concept – stylized 80s workstation, isolated laboratory atmosphere. Warm/desaturated tones, yellow brand accent – Blog by Factory268

Sonata vs Revit: la comparación técnica

Al observar las especificaciones de Sonata hoy, la sensación es extraña. No parece un antepasado lejano, parece un prototipo.

El corazón del sistema era una modelización sólida paramétrica y orientada a objetos: los objetos no eran geometría bruta, sino categorías que sabían relacionarse entre sí. Una puerta insertada en un muro no permanecía allí por casualidad; el muro "sabía" albergarla y generaba automáticamente los detalles asociados. ¿Suena familiar? Es el mismo principio host/insert sobre el cual construimos nuestras familias todavía hoy.

Y no termina ahí. Plantas, secciones y vistas 3D se actualizaban juntas, automáticamente, con cada modificación: la misma promesa que hoy llamamos "coordinación del modelo". Sonata generaba mediciones (quantity take-off), gestionaba la secuencia constructiva e incluso tenía un motor de renderizado integrado (Ingram escribió su tesis doctoral sobre ello). Todo esto en una estación de trabajo Unix, en 1986.

Entonces, ¿qué falta? ¿Qué separa realmente a Sonata de Revit, si el concepto de fondo es el mismo? La respuesta es el acceso.

Sonata era potente, pero para construir y modificar esa lógica paramétrica se necesitaba un lenguaje de programación dedicado. El personal era formado específicamente para usarlo; no es un detalle marginal, es la diferencia entre una herramienta para especialistas y una herramienta para toda una profesión. Sonata tenía el motor. No tenía la cabina de conducción.

Revit llega quince años después con exactamente esa pieza que faltaba: el Family Editor. No un lenguaje que aprender, sino una interfaz gráfica: la misma idéntica lógica paramétrica de Sonata, hecha manipulable por cualquiera que sepa dibujar, sin escribir una línea de código. Ahí es donde el BIM deja de ser un experimento de laboratorio y se convierte en un flujo de trabajo escalable para todo un estudio, para todo un sector.

En otras palabras: Sonata demostró que la idea funcionaba. Revit demostró que la idea podía funcionar para todos.

Sonata vs. Revit: A Comparison of the Features of the Two Parametric Modeling Software - by Factory268

La oportunidad perdida

En 1987, un año después del lanzamiento, Sonata está haciendo exactamente lo que debía hacer: convencer al mercado de que el futuro era suyo. Y entre quienes se dan cuenta está Autodesk.

Según el propio Ingram, se estuvo muy cerca de un acuerdo de adquisición. Las negociaciones estaban avanzadas y los términos básicamente definidos. Luego, en cuestión de días, todo se desmorona; no por un desacuerdo, no por un detalle contractual, sino porque el mundo entero se distrae con algo mucho más grande: el Lunes Negro, el desplome de los mercados financieros del 19 de octubre de 1987, uno de los días más negros de la historia de Wall Street. El acuerdo, simplemente, no se firma.

No hay ninguna moraleja obvia que sacar de esto; no es un error de Ingram, no es una oportunidad desperdiciada por negligencia. Es el tipo de episodio que en la historia de la tecnología sucede más a menudo de lo que se piensa: un timing perfecto arruinado por un evento que no tiene nada que ver con el producto en sí.

Pero el motivo por el cual vale la pena contarlo no es la mala suerte en sí. Es lo que sucede después, quince años más tarde: Autodesk, la misma empresa que en el 87 estaba a punto de comprar Sonata, comprará Revit en 2002: el heredero indirecto de esa misma lógica técnica, que alcanzó su madurez a través de un camino completamente distinto.

A veces las empresas no persiguen las ideas correctas. Las encuentran dos veces, con una generación de diferencia, hasta que llegan al momento en que el mercado finalmente está listo para acogerlas.

Black Monday, October 19, 1987 — minimalist-style chart showing the stock market crash — financial market collapse and Autodesk's failed acquisition of Sonata.

De Sonata a Reflex y a PTC

Perdida la oportunidad con Autodesk, Ingram no se detiene. Vuelve al ático —metafóricamente, pues el proyecto ya ha crecido— y sigue desarrollando lo que había construido. Sonata evoluciona, se perfecciona, se convierte en una aplicación más completa y más madura: Reflex.

Reflex lleva la misma lógica de Sonata a un hardware nuevo, las estaciones de trabajo Silicon Graphics IRIX, y luego a PC de escritorio con la versión Pro Reflex: un paso hacia un público más amplio, aunque todavía lejos de la escala que alcanzará Revit.

En 1996 llega el giro que nadie, diez años antes, habría previsto: Reflex es vendido a PTC (Parametric Technology Corporation) por una cifra que, según las fuentes de la época, rondaba los 30 millones de dólares. El propio Ingram entra en PTC como CTO.

PTC, cabe decir, no es una empresa cualquiera en el mundo de la modelización paramétrica. Es el gigante del CAD mecánico, famoso sobre todo por Pro/Engineer, la aplicación que ya había redefinido el diseño paramétrico en el sector industrial. La adquisición de Reflex tiene un objetivo preciso: usar esa tecnología para entrar en el mercado de la construcción, un sector que PTC ve como la próxima frontera de crecimiento.

Sobre el papel, el acuerdo tiene todas las condiciones necesarias. PTC tiene el dinero, la tecnología consolidada de Pro/Engineer y ahora también a Reflex y a su creador. Sin embargo, la estrategia no despega; el mercado de la construcción demuestra ser más difícil de penetrar de lo esperado y la iniciativa se reduce progresivamente. Pero dentro de PTC, en esos años, hay también otras dos personas que están mirando exactamente la misma tecnología con ojos diferentes, y que poco después tomarán una decisión que cambiará todo.

El puente humano

Leonid Raiz e Irwin Jungreis trabajan en PTC como desarrolladores clave en Pro/Engineer, el mismo software estrella del CAD paramétrico mecánico que ha hecho de PTC un gigante. Están allí cuando llega Reflex y están allí el tiempo suficiente como para comprender algo que casi nadie más en la empresa parece ver con la misma claridad: PTC tiene en sus manos la tecnología correcta, pero está intentando venderla al mercado equivocado, con el enfoque equivocado.

En 1997 toman una decisión clara. Dejan PTC y, en su liquidación, se llevan algo muy concreto: una licencia no exclusiva del código fuente de Reflex. No empiezan de cero. Empiezan con quince años de trabajo que pasan por Sonata y Reflex, heredados legal y técnicamente.

El 31 de octubre de 1997 fundan Charles River Software, en Newton, Massachusetts. El objetivo declarado está claro desde el principio: llevar la potencia de la modelización paramétrica —ya demostrada en el ámbito mecánico por Pro/Engineer y en el de la edificación por Reflex— a un público que ninguno de los dos predecesores había logrado alcanzar realmente: toda la profesión arquitectónica, no solo los especialistas dispuestos a aprender un lenguaje de programación.

Hay un detalle que cierra el círculo de forma casi poética: según el propio Ingram, Raiz y Jungreis le ofrecen un papel en el nuevo proyecto. Él rechaza. Después de más de una década entre Sonata y Reflex, se siente agotado; otra aventura del mismo tipo es simplemente demasiado.

Charles River Software, tres años después, cambiará de nombre. Se llamará Revit Technology Corporation.

Concept of the handover from Sonata to Reflex, PTC, Charles River – BIM Culture Blog by Factory268

Si todo esto es cierto —si Sonata ya hacía, en 1986, cosas que hoy damos por sentadas—, ¿por qué casi nadie ha oído hablar de ella? ¿Por qué en los cursos de BIM, en los seminarios web y en las conferencias del sector, la historia comienza siempre con Revit o, como mucho, con Eastman, y Sonata sigue siendo un nombre para expertos?

La respuesta no es una conspiración o una damnatio memoriae. Es más sencilla y más predecible.

El primer motivo es el coste. Sonata funcionaba en estaciones de trabajo Unix y Silicon Graphics, hardware que costaba como un apartamento, accesible solo a estudios con presupuestos importantes. AutoCAD, lanzado pocos años antes, funcionaba en el primer PC IBM. Económico, difundido, al alcance de cualquiera. No es difícil entender cuál de los dos ganó la batalla por la adopción masiva.

El segundo motivo es el flujo de trabajo. El sector de la construcción, a diferencia del mecánico, tiene una tasa de adopción tecnológica históricamente lenta; arquitectos, contratistas y clientes proceden a distintas velocidades, y el paso del 2D al 3D imponía un cambio radical de hábitos que el mercado de los años 80 simplemente no estaba preparado para digerir. Sonata le pedía al sector que diera un salto que el sector mismo todavía no era capaz de dar.

El tercer motivo es la secuencia temporal. Sonata y Reflex llegan antes de que existieran estándares, directrices y una cultura BIM compartida a nivel sectorial. Nacen sin un terreno común donde echar raíces, un poco como lanzar un producto perfecto en un mercado que todavía no existe.

El resultado es que Sonata y Reflex construyeron de todas formas una base de usuarios internacional (Reino Unido, China), pero se quedaron fuera de los focos de la historia oficial, mientras la atención se desplazó por completo a los rivales que llegaron después, con más fortuna de mercado y de timing.

Nunca fue una cuestión de calidad técnica. Siempre fue una cuestión de cuándo.

La regla de BIM Culture

Existe una tentación fácil al llegar a este punto: pensar que Sonata fue "una oportunidad perdida". No lo fue. Sonata hizo exactamente lo que debía hacer: demostró que la idea funcionaba técnicamente quince años antes de que el mercado estuviera listo para acogerla a gran escala. No es un fracaso. Es un prototipo que esperó el momento justo para convertirse en estándar, pasando de mano en mano —de Ingram a Reflex, de Reflex a PTC, de PTC a dos desarrolladores que vieron lo que nadie más estaba viendo en ese momento.

Sonata and "timing": a watch with frozen hands — the theme of "the right idea at the wrong time," BIM Culture Blog by Factory268

La regla de BIM Culture —una idea técnica correcta no basta. Debe encontrar el mercado, el hardware y la cultura profesional listos para recibirla, y cuando este encuentro no ocurre, la idea no muere: espera, cambia de forma, pasa a otras manos, hasta que alguien encuentra la combinación que la hace explotar.

Sonata tenía el motor. Todavía faltaba alguien que construyera la cabina de conducción, y ese alguien, tres años después de dejar PTC con una licencia en el bolsillo y una idea heredada, tenía un nombre muy preciso.

Cómo llegaron Raiz y Jungreis a ello, qué tuvieron que resolver y por qué el Family Editor —no el renderizado, no la modelización paramétrica en sí, sino precisamente esa interfaz— fue la verdadera invención que hizo que Revit ganara donde Sonata y Reflex se habían detenido: es la historia que contamos en el próximo episodio de BIM Culture, "El nacimiento de Revit".


Si quieres profundizar en la genealogía completa del BIM, te recomiendo leer el artículo de BIM Culture El profeta del BIM: Charles M. Eastman.

Regresar al blog

Deja un comentario

Ten en cuenta que los comentarios deben aprobarse antes de que se publiquen.