Ontología

Los errores de ontología que todos hemos cometido en Foundry

En Foundry es muy fácil pasar de la base de datos a la ontología, de ahí a la aplicación, a las acciones y a la automatización. Justo por eso aparece el primer error clásico, el efecto demo: los casos de uso se pegan demasiado al dato. Modelas los objetos de la ontología calcando un sistema concreto, con sus virtudes y también con sus defectos, porque casi toda aplicación acumula trampillas y apaños para que algo funcione en su propio front. Después llega otro departamento, para el que «cliente» es un concepto parecido, y haces una ontología para el A y otra para el B, con una capa superior que intenta ponerlos de acuerdo. A veces eso es una feature; muchas veces es un bug y una montaña de parches. Y la tentación contraria tampoco sirve: modelar toda la empresa antes de construir nada es irrealizable y antipareto, porque Foundry es caro y lo que necesitas es sacarle partido cuanto antes.

Lo que nos funcionó fue buscar primero los casos de uso más definitorios del negocio. ¿En qué departamento es el cliente más importante, o dónde está el core de la empresa? Ese cliente es el primero que modelas, pensando en la especificidad de ese departamento pero con la picardía de saber que va a cambiar. Te pegas al caso para ser rápido, sin atarte. Cuando integras más datos, Foundry fomenta tener menos tipos de objeto y más genéricos, y para eso existen herramientas como las interfaces, que describen la forma común de varios tipos de objeto, o los objetos con varios orígenes de datos, en los que un mismo objeto se alimenta de distintos datasets. También puedes agrupar propiedades de distinto tipo en una sola con las propiedades struct. Y no hace falta crear objetos distintos por tonterías de estilo: un cliente en España y otro en Reino Unido no necesitan dos tipos de objeto para tener su bandera. Eso se resuelve con propiedades y con el formato condicional, más aún si construyes aplicaciones fuera de Workshop.

El segundo error es irse al otro extremo: superobjetos gigantes que luego hay que doblar con virguerías para meterlos en un Workshop. A veces lo mejor es duplicar una propiedad de otro objeto en lugar de encadenar tres search arounds, porque recorrer enlaces entre tipos de objeto cuesta más que filtrar por una propiedad del mismo objeto. El equilibrio depende de lo que te duela. Si lo que pesa es el volumen y el coste de las consultas, duplica lo mínimo y separa los objetos. Si lo que necesitas es velocidad en la operativa, evita los search arounds y las búsquedas sobre objetos enormes. Si lo que quieres es generar valor rápido con muchas aplicaciones, quizá te convengan objetos grandes y muy centralizados.

Para decidir ese equilibrio hay que saber cómo funciona la ontología por debajo, y nosotros lo sabemos. Las consultas las resuelve su motor de consultas, Highbury, y llevamos años viendo cómo responde. Lo rápido es lo que el motor puede resolver directamente en la capa de almacenamiento, como una consulta base filtrando por propiedades del propio objeto: la documentación la describe como la vía de ejecución más rápida. Lo lento y caro es recorrer enlaces con search arounds, agregar, trabajar con propiedades derivadas o lanzar búsquedas avanzadas. Y cuando el conjunto supera por defecto los 100.000 objetos, la consulta pasa a ejecutarse con Spark, con más latencia y más cómputo. Las cifras de coste de consultas, vigentes desde enero de 2026, lo reflejan: como mínimo 2 compute-seconds por una consulta base, 5 por un search around o una agregación y 10 por una propiedad derivada o una consulta avanzada, y el coste real puede ser mayor según la complejidad. Por eso un diseño que evita saltos innecesarios se nota tanto en la factura como en la velocidad. Los servicios que hay detrás los describe la arquitectura de la ontología. Hay tantas respuestas como clientes, departamentos y herramientas. En todas hemos estado, y lo que hacemos es un assessment ajustado a tu operativa y a las decisiones que necesitas poder tomar.

Para profundizar (documentación de Palantir)

¿Quieres revisar tu ontología? Hacemos un assessment ajustado a tu operativa.

Agenda una Discovery Call