Arquitecto programador en AECO: del prototipo al producto

«Ya que funciona, lo ponemos para toda la empresa». Qué manera tan económica de convertir un script en infraestructura: basta pronunciarlo y dejar que su autor absorba versiones, permisos, soporte y despliegue por simpatía. El prototipo no ha cambiado; solo ha aumentado la gente que dependerá de él. El arquitecto programador entra precisamente en ese salto, donde entender el proyecto importa tanto como saber escribir código y alguien tiene que poner límites antes de repartir accesos.

Un arquitecto programador en AECO puede conectar el conocimiento de proyecto y BIM con el desarrollo de herramientas digitales. El nombre del puesto no es universal y sus límites varían entre organizaciones. Aquí lo entenderemos como una función híbrida que ayuda a convertir necesidades del trabajo en soluciones comprobables y mantenibles. Seguiremos un caso hipotético de control de parámetros para ver qué aporta, con quién necesita colaborar y por qué escribir el primer script es solo una parte de su trabajo.

Traduce el problema del proyecto antes de diseñar la aplicación

Supongamos que varias oficinas quieren revisar sus modelos contra unas convenciones de información. El primer script comprueba lo que necesitaba un proyecto concreto. Antes de compartirlo hay que reunir ejemplos y distinguir reglas comunes, configuración de proyecto y excepciones. Si cada oficina utiliza códigos parecidos con significados distintos, unificar el nombre de una propiedad no resuelve automáticamente la diferencia. Puede limitarse a volverla menos visible.

La función híbrida aporta valor al hacer esas preguntas con suficiente conocimiento del modelo y del software. ¿Qué elementos entran? ¿Qué dato se espera? ¿Qué debe bloquear una entrega y quién puede aceptar una excepción? Las respuestas se convierten en ejemplos y resultados esperados. El responsable BIM y los usuarios deben poder discutirlos sin leer una implementación. Todavía no necesitamos elegir una base de datos para descubrir que dos equipos llaman «tipo» a cosas diferentes.

Ese trabajo incluye observar cómo se resolverá un fallo. El usuario necesita localizar el elemento y entender la condición; el responsable de información puede necesitar comparar entregas; soporte necesita reconocer la versión de la herramienta. Son usos relacionados, pero no idénticos. Diseñar solo para la pantalla del autor del prototipo deja fuera a quienes van a vivir con el resultado. La experiencia de proyecto ayuda precisamente a reconocer esas situaciones antes de convertirlas en solicitudes urgentes.

Conviene acordar asimismo qué queda fuera. Quizá la primera versión solo informa y no corrige; quizá no revisa modelos vinculados o solo admite ciertas versiones. Esos límites permiten construir una aceptación concreta. Un alcance pequeño que puede demostrarse es un punto de partida sólido. Una herramienta que promete «comprobar cualquier modelo» acaba necesitando explicar sus límites después, normalmente en el momento menos oportuno.

Separa las partes que van a cambiar por razones distintas

El script inicial puede mezclar acceso a Revit, lectura de una hoja, reglas y creación del informe. Una organización más mantenible separa el adaptador del modelo, la evaluación, la configuración y la salida. Así una regla puede probarse con datos simples y el código que conoce Revit se concentra en su API. No se trata de introducir capas por elegancia. Se trata de que cambiar el catálogo no obligue a tocar también la forma de abrir un documento.

La fuente de cada dato necesita un contrato. El adaptador puede devolver identidad, clase de elemento, valor observado y contexto suficiente para evaluar. El motor de reglas devuelve estado, condición y evidencia. Si después se añade IFC, habrá diferencias que revisar; una estructura común no garantiza equivalencia entre todas las propiedades y relaciones. La arquitectura facilita estudiar esas diferencias en vez de esconderlas detrás de un campo llamado Valor.

El contexto de la aplicación impone límites reales. En Revit, leer un modelo desde un complemento y modificarlo no son operaciones intercambiables con ejecutar una función en un servidor. La documentación de transacciones establece condiciones para escribir en el documento. El conocimiento del dominio ayuda a anticipar vínculos, grupos, fases y parámetros, mientras el desarrollo especializado convierte esas condiciones en comportamiento fiable.

La distribución también influye en el diseño. Un complemento puede acercar la herramienta al trabajo del usuario; un servicio puede centralizar determinadas reglas o resultados, con sus requisitos de acceso y operación. No existe una respuesta general que convierta todo en web o todo en escritorio. Documenta por qué se elige una opción y qué consecuencias tiene. Una tecnología elegida para un contexto no debería terminar convertida en ley natural porque ya figura en el diagrama.

Reparte responsabilidad y comprueba el recorrido completo

El responsable BIM o de información define las condiciones de intercambio; quienes conocen la disciplina revisan su interpretación; desarrollo aporta profundidad técnica; operaciones y seguridad intervienen según el despliegue. El arquitecto programador puede conectar esas conversaciones y prototipar partes del recorrido. No sustituye automáticamente a todos los especialistas. Un perfil que intenta asumir cinco profesiones suele convertirse en un cuello de botella con una tarjeta de visita muy larga.

El reparto debe verse también en permisos y decisiones. Ejecutar un diagnóstico, cambiar una regla corporativa y aprobar una excepción son acciones distintas. En el caso hipotético, un modelador podría revisar su modelo mientras otra función controla las reglas compartidas. La autoridad técnica debe corresponder a una responsabilidad reconocida por la organización. Tener acceso a un botón no demuestra que se deba tomar una decisión contractual o de diseño.

Las pruebas necesitan casos de proyecto y comprobaciones técnicas. Las reglas pueden evaluarse con datos conocidos; el adaptador requiere modelos controlados; el recorrido del usuario necesita comprobar que el informe permite actuar. Un resultado correcto en una función no demuestra que la persona encuentre el elemento ni que pueda recuperar una ejecución fallida. Ahí el perfil híbrido aporta escenarios que no aparecen al revisar únicamente tipos y respuestas.

Antes de compartir una versión, prepara una forma de identificarla y volver a una anterior si hace falta. La documentación de versiones publicadas de GitHub muestra un mecanismo para distribuir paquetes asociados a versiones; no es el único, ni obliga a hacer público un proyecto interno. Lo importante es evitar que varias copias modificadas circulen con el mismo nombre y que soporte dependa de adivinar cuál ejecutó el usuario.

Convierte mantenimiento y uso en parte del producto

Una herramienta compartida necesita instrucciones de uso, versiones soportadas y un responsable cuando falla. Los mensajes deberían ayudar a distinguir datos incompletos, configuración incorrecta y errores de la aplicación. El diagnóstico técnico puede conservar detalles adicionales sin convertir una excepción interna en la única explicación para el usuario. «Revisa la columna Código: falta en la tabla seleccionada» permite actuar. «Error de objeto» invita a buscar al autor del script por cualquier canal disponible.

Observa también si las reglas producen demasiados falsos positivos y cuánto trabajo requiere revisar el informe. El número de ejecuciones no basta para demostrar utilidad. Una herramienta puede usarse mucho porque es obligatoria y seguir siendo difícil de interpretar. Los datos de uso, recogidos con el alcance adecuado, deben ayudar a mejorar la solución; no hace falta almacenar modelos completos ni convertir la revisión técnica en una medición individual de productividad.

Las incidencias repetidas pueden revelar que falta una prueba, que una convención es ambigua o que la interfaz está pidiendo una decisión que el usuario no puede tomar. Responder a cada caso con otra opción no garantiza una solución mejor. A veces hay que aclarar el proceso, corregir el catálogo o retirar una función. El mantenimiento aporta conocimiento sobre el producto y debería tener un lugar en su planificación, aunque resulte menos fotogénico que presentar novedades.

Para desarrollar este perfil, empieza por herramientas pequeñas que alguien pueda revisar y utilizar. El portfolio debería explicar el problema, las decisiones, las comprobaciones y los límites, además del código. Profundiza en fundamentos de software y pide revisión donde falte especialización. No existe una proporción obligatoria entre arquitectura y programación: la organización necesita capacidades concretas, no una mezcla ideal definida por el título.

Una oficina pequeña puede resolver estas necesidades con un responsable BIM y apoyo de desarrollo, sin crear un puesto específico. Cuando traducir entre dominio y software sea trabajo sostenido, la función híbrida tendrá un alcance más claro. La señal útil es que la solución y sus decisiones puedan entenderse fuera del portátil de quien la creó. Si toda la empresa usa tu prototipo pero solo funciona mientras estás disponible en una videollamada, el siguiente desarrollo quizá sea el equipo.

Una herramienta compartida necesita algo más que el teléfono de quien la hizo. Define qué promete, cómo se distribuye, quién decide sus cambios y quién responde cuando falla. Si esas tareas siguen escondidas bajo «es un script pequeño», lo pequeño es la parte del presupuesto que les habéis reservado. El producto ya está pidiendo atención, aunque nadie quiera llamarlo así.