Saltar al contenido
Arquitectura de CanopyA fondo6 min de lectura

Su marca, sus módulos, su nombre encima

Un solo código, tres despliegues que se leen como el software de tres empresas. Por qué el conjunto de módulos importa más que el logo, por qué resolver la marca por petición desde un despliegue compartido pone en riesgo la relación del comprador con su cliente, y para qué sirve de verdad el botón de exportación.

La vista de propiedad de Canopy mostrando tres despliegues de un mismo código bajo distintos nombres de producto, asistentes, puertas de acceso y conjuntos de módulos

La pregunta que responde esta sección: qué tiene que ser cierto antes de que un comprador ponga su propio nombre sobre software que construyó otra persona. La forma más rápida de hacer que un portal de cliente se sienta como software rentado es dejarle encima el nombre del proveedor. El cliente del comprador inicia sesión y ve un producto del que nunca ha oído hablar, vestido con colores que no son los del comprador, con un enlace de soporte que lleva a otra parte. Cada uno de esos detalles le dice al cliente que el negocio con el que está tratando es un inquilino. La mayoría de las ofertas de marca blanca atienden esto con un espacio para el logo y un color de acento, que es un tema encima de un sistema compartido, y un tema es exactamente tan delgado como suena: la primera cadena de texto sin marcar, la primera ilustración por defecto, el primer módulo vacío que el comprador no usa y no puede quitar, y la ilusión se acabó. Así que una instalación de Canopy no es un tema. Es el sistema entero, cargando el nombre, la marca y los colores del comprador, con las partes que no necesita apagadas. Un solo código corre despliegues que se ven y se comportan como productos genuinamente distintos: su propio nombre de producto en todas partes, su propio logo, su propia paleta de acento a lo largo de toda la interfaz y no en una barra superior, su propio asistente con su propio nombre y su propia frase de apertura, sus propias puertas de inicio de sesión y su propio conjunto de módulos. Tres instalaciones del mismo código pueden estar una junto a otra y leerse como el software de tres empresas, porque al nivel en que el usuario está operando, eso es lo que son. El conjunto de módulos es la parte que los compradores subestiman hasta que la ven. Un negocio sin buzón en su portal no recibe una bandeja vacía con un mensaje amable sobre conectar una. Un negocio que nunca va a comprar un diagnóstico de sitio web no recibe una pestaña fija en cero, invitándolo a preguntarse qué se está perdiendo y si está en el plan equivocado. Cada superficie visible que no aplica a un comprador no está atenuada ni encerrada detrás de una venta adicional. No está. Esto importa más que el logo, porque una función vacía es un anuncio permanente de que el software se construyó para alguien más y que el comprador está usando un subconjunto. El personal del comprador debería abrir el producto y ver una herramienta hecha para su negocio, porque en términos operativos eso es lo que es. Consideré el enfoque convencional, que es un despliegue único que sirve a todos los clientes con la marca resuelta por petición a partir del dominio. Es mucho más barato de operar y es lo que hace casi todo en esta categoría. Lo rechacé por la misma razón que da la sección de arquitectura, y la pregunta de la marca vuelve el razonamiento inusualmente concreto. En un despliegue compartido, la marca del comprador es una fila en una tabla de configuración que mi código lee en cada petición. El comprador no es el dueño de su propia identidad de producto; es una consulta. Si la consulta sale mal, o si la caché quedó tibia con datos de otro inquilino, o si una consulta olvida el filtro de inquilino durante una sola versión, el cliente del comprador ve el nombre de otra empresa en el portal del propio comprador. Eso no es una falla teórica. Es la falla ordinaria de los sistemas multi-inquilino, y aquí su radio de daño cae directo sobre la relación del comprador con su cliente. La respuesta por instalación elimina la falla en lugar de defenderse de ella. Una instalación es una base de datos, un inicio de sesión y un despliegue, todos del comprador, sin infraestructura compartida entre él y nadie más. No hay ninguna cuenta central mía por la que pasen los datos y no hay ninguna columna de inquilino en ninguna parte que se pudiera consultar mal. Por eso el argumento de propiedad es honesto en lugar de ser un eslogan: literalmente no hay nada que se pueda filtrar entre clientes, porque no hay otros clientes dentro de la instalación. La marca no se resuelve al momento de la petición desde una tabla. Es lo que la instalación del comprador es. Lo que esto me cuesta es real y lo elegí a sabiendas. Un cambio de marca es un despliegue y no una actualización de base de datos. Un conjunto de módulos nuevo es configuración aplicada por instalación y no un interruptor accionado desde el centro. Aprovisionar toma horas y no segundos. Construí herramientas para que el impuesto operativo quede acotado, pero el impuesto existe, se acumula con cada instalación, y lo paga el estudio y no el comprador. Esa es la dirección correcta para que caiga, porque el comprador es quien está pagando por el resultado. La autoridad dentro de una instalación son cuatro niveles, asignados por persona y revocables en cualquier momento, y una cuenta deshabilitada no puede iniciar sesión en absoluto. Los niveles van desde control total, que incluye decidir quién más entra, hasta un nivel de solo lectura que puede navegar por todas partes y será rechazado por cualquier control que cambie algo. La propiedad importante no es el número de niveles. Es que el propio administrador principal del comprador asigna y revoca todos ellos sin que yo intervenga, y que cada asignación queda a su vez registrada. Un acceso que el comprador no puede cambiar por su cuenta es un acceso que en realidad no controla. Y la salida es un control en la página de ajustes y no un ticket de soporte. Cada entidad se exporta a CSV y la base de datos completa se exporta de una vez. Esta es la cláusula que vuelve al resto de la sección comprobable en lugar de retórica. Cualquiera puede afirmar que un comprador es dueño de su instalación. La afirmación solo significa algo si el comprador puede ejercerla un martes por la tarde sin pedir permiso, sin un periodo de aviso y sin una conversación sobre por qué lo quiere. La prueba que la propiedad tiene que pasar es que el comprador pueda despedirme y seguir operando mañana por la mañana, y un botón de exportación que puede pulsar hoy es la parte de esa prueba que puede correr mientras todavía está contento con el arreglo. La exclusión honesta: la capa de marca blanca es real y está corriendo en despliegues vivos, pero qué cliente usa qué edición les toca decirlo a ellos y no a mí. Las tres instalaciones que se muestran en el recorrido son negocios inventados, construidos para demostrar la capa, no una lista de clientes. Un proveedor que demuestra su discreción nombrando a los clientes sobre los que fue discreto ha demostrado lo contrario. La consecuencia operativa que el comprador siente es que el software deja de ser algo a lo que se suscribe y empieza a ser algo que tiene. Su personal abre un producto con el nombre de la empresa encima, que contiene las partes del negocio que de verdad opera y ninguna de las que no. Sus clientes inician sesión en el dominio propio de la empresa y no se topan con mi nombre en ninguna parte. Y la propiedad detrás de esa presentación no es una promesa en un contrato, es la forma del despliegue: su base de datos, su inicio de sesión, su dominio, su botón de exportación, y ninguna infraestructura compartida entre él y nadie más en el mundo.