Cada panel, aplicación y agente necesita las mismas respuestas sobre tu negocio

Lo primero es que el significado de los datos generalmente nunca se ha documentado. Cosas como: qué se considera un producto; si cuatro registros describen el mismo artículo o cuatro diferentes; qué implica el estado de un pedido sobre si aún se puede cancelar; cuál de cinco registros de clientes corresponde al cliente real y cuál dirección es la vigente… Todo esto es información que alguien en la empresa conoce, y cada proyecto encuentra a esa persona, le pregunta, codifica su respuesta y la entrega. Pero eso significa que cada vez, la respuesta se va con el proyecto.

Lo segundo es que el acceso a los sistemas que gestionan los datos se negocia proyecto por proyecto. El equipo responsable del sistema más antiguo asume el riesgo de tu cambio y recibe poco del beneficio, así que cuando dicen que no es una prioridad este trimestre, están tomando una decisión razonable desde su perspectiva. Y como cada nuevo proyecto llega a preguntar por separado, se les pide asumir ese riesgo varias veces al año por razones que no tienen nada que ver con su propia hoja de ruta.

Lo tercero es que nada de esto se acumula. La integración se construye para este proyecto. Las definiciones viven en el código de este proyecto, o en una hoja de cálculo que alguien mantuvo por un tiempo. A los diez proyectos, has pagado por el mismo trabajo diez veces y aún no puedes señalar un único lugar donde viva la respuesta.

Cualquiera de estos problemas por separado es manejable. Juntos, explican por qué una solicitud que suena a dos semanas termina siendo dos trimestres.

Estos dos términos se escuchan cada vez con más frecuencia (generalmente de parte de proveedores, y generalmente sin mucha explicación). Corresponden a los tres problemas mencionados anteriormente y son más mundanos de lo que parecen.

Una ontología es la respuesta escrita al primer problema. Registra lo que su empresa entiende por las cosas sobre las que opera: un producto, un pedido, un cliente, una promoción, lo que sea relevante en su contexto, junto con qué sistema almacena la verdad de cada uno. También captura las relaciones, de modo que una consulta sobre un pedido puede rastrearse hasta el cliente que lo realizó y los productos que contiene. Una ontología es a la vez un documento y un modelo, y la mayor parte del esfuerzo para producirla radica en lograr que las personas lleguen a un acuerdo.

Una capa semántica es la respuesta a los otros dos problemas. Se sitúa frente a los sistemas que ya tiene y utiliza la ontología para realizar dos funciones: la primera es determinar qué sistema contiene la respuesta a una consulta entrante, y la segunda es determinar qué sistemas deben actualizarse (y en qué orden) cuando algo cambia. Los proyectos se comunican con la capa en lugar de conectarse individualmente a cinco sistemas distintos.

Ninguno de estos elementos reemplaza nada. En cambio, ambos se sitúan por encima y operan transversalmente sobre los sistemas que utiliza hoy, lo que significa que no hay migración ni necesidad de esperar a que se complete una.

Hasta ahora, el equipo responsable del sistema antiguo gestiona un flujo constante de solicitudes individuales, cada una con su propio riesgo y su propia integración. Pero si la capa semántica cumple su función, cada capacidad del sistema más antiguo se integra una sola vez, por personas que negocian con sus propietarios una sola vez, y todos los proyectos posteriores acceden a ella a través de la capa. La exposición del equipo propietario pasa de recibir varias solicitudes de acceso al año por parte de distintos equipos, a gestionar una única interfaz que ellos mismos ayudaron a definir.

Este enfoque simplificado y optimizado hace que el equipo tienda a decir que sí con mayor frecuencia. El intercambio les deja con menos riesgo a asumir, a cambio de una sola conversación bien llevada.

Suena como algo obvio, pero es importante ser honesto sobre cuándo el retorno de tu esfuerzo realmente aparece: no con el primer proyecto, sino con el segundo.

El primer proyecto carga con la mayor parte del trabajo. Paga el costo de definir las entidades que toca e integrar los sistemas que necesita. El segundo es el que puede reutilizar ambas cosas y dedicar su tiempo a lo que se le pidió construir. Y a partir de ahí se multiplica: para el tercero o cuarto, poner algo en marcha se acerca más a una configuración, porque las definiciones ya existen, los accesos ya existen y las preguntas ya están resueltas.

Conseguir financiamiento para una fundación en sus propios términos es un argumento más difícil de lo que parece. Requiere alineación entre más equipos que cualquier proyecto individual, y el beneficio recae sobre trabajo que nadie ha definido aún y que normalmente debe esperar un ciclo presupuestario. Mientras tanto, la empresa ya ha financiado otra cosa.

Por eso hay que construir la fundación por debajo de eso.

Toma el proyecto que ya tiene un patrocinador y una fecha límite. Ejecútalo. Pero conserva el trabajo de definición como un artefacto compartido en lugar de enterrarlo en el código de ese proyecto, y coloca la integración detrás de una capa a la que el siguiente proyecto pueda acceder. Gastarás algo más de lo que habrías gastado, pero lo que obtendrás a cambio es que el siguiente proyecto parte desde donde este dejó las cosas.

Mantén la primera entrega pequeña. Limítate a una entidad, dos consumidores, un trimestre y una prueba concreta de si funcionó. Resiste la tentación de modelar todo el negocio antes de lanzar algo, ya que históricamente eso es exactamente cómo este tipo de trabajo ha salido mal.

Una nota: la parte difícil de esto es una negociación entre personas que actualmente no están de acuerdo. Decidir qué significa un "cliente activo" es una conversación entre las áreas del negocio que dependen cada una de su propia respuesta, y ningún arquitecto puede resolverla por ellas. Pon en la sala a alguien que pueda tomar esa decisión.

Observa lo que está en la hoja de ruta para los próximos dos trimestres. Identifica los proyectos que necesitarán leer o modificar datos que residen en más de un sistema, y cuenta cuántos de ellos están a punto de resolver por su cuenta qué es un producto o un cliente, cada uno por separado.

Luego elige el primero en salir a producción y resuelve la parte compartida correctamente durante el proceso. Todo lo que venga después parte desde el punto de partida que creaste en el camino.