Telfo Networks

Arquitectura

Qué sistema debe ser el núcleo de tu arquitectura

Casi todas las empresas tienen el mismo problema de fondo: varios sistemas que creen ser el dueño del mismo dato. Elegir cuál manda es la decisión más barata y la que más problemas evita.

4 min de lectura

Equipo revisando en pantalla la arquitectura de sistemas de una empresa

Cuando una empresa crece, el software se acumula. Primero llegó el programa de facturación, luego la tienda online, después una herramienta de almacén y en algún momento alguien empezó a llevar los clientes en una hoja de cálculo compartida. Ninguna de esas decisiones fue mala por separado. El problema aparece cuando hay que responder a una pregunta aparentemente simple: ¿cuál es el precio de este producto?

Y resulta que hay tres respuestas distintas según dónde mires.

El concepto que lo ordena todo: origen de verdad

Para cada tipo de dato —clientes, productos, precios, stock, pedidos— tiene que haber un único sistema que manda. Es el que se puede editar. Los demás reciben una copia y la muestran, pero no la modifican. A eso se le llama origen de verdad, y es la decisión de arquitectura que más discusiones ahorra a lo largo de los años.

Lo importante es que la elección se hace por tipo de dato, no por sistema. Es perfectamente normal que el ERP mande sobre productos y precios, el CRM sobre los datos comerciales del cliente y el sistema de almacén sobre el stock físico. Lo que no puede pasar es que dos sistemas se crean dueños de lo mismo.

Cómo se decide quién manda sobre cada dato

No hay una respuesta universal, pero sí cuatro preguntas que casi siempre la producen:

  1. ¿Dónde nace el dato? Si el stock cambia físicamente en el almacén, el sistema de almacén parte con ventaja. Si un precio se negocia en una reunión comercial, difícilmente lo va a saber primero la tienda online.
  2. ¿Quién lo edita a diario? El sistema donde trabaja la persona que mantiene ese dato es el candidato natural. Obligar a alguien a salir de su herramienta habitual para actualizar algo es la forma más segura de que deje de actualizarlo.
  3. ¿Qué sistema tiene el modelo más completo? Si en el ERP un producto tiene variantes, familias e impuestos, y en la tienda online solo tiene nombre y precio, el ERP es el que puede alimentar al otro y no al revés.
  4. ¿Qué pasa si ese sistema se sustituye dentro de tres años? Conviene que el origen de verdad sea el sistema más estable, no el que se cambia con cada moda.

El error habitual: sincronización bidireccional por defecto

Cuando dos sistemas pueden escribir sobre el mismo dato, hace falta decidir qué ocurre si los dos cambian a la vez. Y esa decisión no tiene buenas respuestas: o gana el último que escribe, y entonces se pierden cambios en silencio, o hay que construir una lógica de resolución de conflictos que nadie va a mantener.

La sincronización en un solo sentido es más aburrida y muchísimo más fiable. Se elige bidireccional solo cuando el caso lo exige de verdad, y entonces se define por escrito quién gana ante un conflicto y qué se registra cuando ocurre.

Núcleo no significa monolito

Elegir un núcleo no obliga a meterlo todo dentro del mismo programa. Al contrario: una arquitectura sana suele tener un núcleo estable —normalmente el ERP o el sistema de gestión principal— rodeado de aplicaciones especializadas que hacen mejor su trabajo que un módulo genérico.

Lo que aporta el núcleo no es funcionalidad, es referencia: un lugar donde el código de cliente, el de producto y el de pedido significan siempre lo mismo. Con eso resuelto, añadir una herramienta nueva es un proyecto de semanas. Sin eso resuelto, cada herramienta nueva multiplica el desorden.

Cómo empezar si esto ya está desordenado

Lo normal es llegar a esta conversación con el problema ya montado. En ese caso el orden que funciona es este:

  • Listar los tipos de dato importantes del negocio. Suelen ser menos de diez.
  • Para cada uno, anotar en qué sistemas vive hoy y quién lo edita.
  • Decidir el origen de verdad de cada uno, aunque hoy no se cumpla.
  • Ordenar los desajustes por lo que cuestan: casi siempre el primero es precios o stock.
  • Corregir de uno en uno, empezando por el más caro y no por el más fácil.

Es un trabajo que se hace una vez y se nota durante años. No exige cambiar de software ni acometer un proyecto grande: exige tomar decisiones y escribirlas.

Un dato con dos dueños no tiene ninguno.

Siguiente paso

Cuéntanos qué necesitas resolver

Da igual si es una necesidad concreta o un proyecto completo todavía sin definir. La primera conversación sirve para entender el problema y decir con franqueza qué haríamos y qué no.