De 20–25 back offices legacy a un único producto configurable

Tecsidel, dentro del Grupo EYSA, desarrolla y opera software de peajes. La compañía acumula un footprint histórico de 29 países, y ese recorrido dejó aproximadamente 20–25 back offices legacy en operación.

Cada mercado y cada cliente relevante había recibido en la práctica su propia copia del producto: un parque de monolitos con el mismo propósito funcional y sin una base común.

El modelo anterior escalaba por multiplicación. Cada nueva operación implicaba una copia más que mantener, evolucionar y soportar, y el conocimiento funcional quedaba repartido entre esas copias y entre las personas que las habían construido, sin una fuente única a la que acudir.

Con ese punto de partida, cualquier mejora transversal costaba tantas veces como instalaciones existían, y entrar en una operación nueva se parecía más a un proyecto que a un despliegue.

Director de Producto e I+D+i · Tecsidel (Grupo EYSA). Mi responsabilidad en este programa es la dirección de producto del nuevo core: qué se unifica, qué se resuelve por configuración, qué se rediseña y en qué orden.

Las instalaciones existentes siguen en operación para clientes enterprise, así que la transformación tenía que convivir con ellas y no sustituirlas de golpe.

Los clientes imponen modelos de despliegue distintos: unos requieren on-premises y otros aceptan cloud, sobre el mismo producto.

El programa se apoya en un equipo específico pequeño —de 6 → 10 personas a lo largo de aproximadamente dos años—, no en una reconstrucción con recursos ilimitados.

Y una restricción autoimpuesta que condiciona todo lo demás: no abrir forks por cliente.

Unificar por configuración, no por personalización de código. La decisión de fondo fue tratar las diferencias entre mercados y clientes como parámetros del producto y no como variantes del software. La alternativa —un tronco común con ramas por cliente— era más rápida a corto plazo y reproducía exactamente el problema que había que resolver.

Un único repositorio principal para el core. Es lo que hace verificable la decisión anterior: si el código vive en un solo sitio, un fork deja de ser una salida cómoda y pasa a ser una excepción visible.

El mismo producto en cloud y on-premises. En lugar de dos productos con dos ciclos de vida, un modelo de despliegue configurable: cuesta más en diseño y evita duplicar el mantenimiento durante años.

Rediseñar las funcionalidades críticas en lugar de portarlas. Donde el comportamiento heredado solo se explicaba por la historia de una instalación concreta, se rehízo desde el caso de uso; donde estaba justificado, se conservó.

El programa se ejecuta con un equipo específico de 6 → 10 personas a lo largo de aproximadamente dos años, trabajando con Ingeniería y con las áreas que conocen y sostienen las instalaciones actuales.

Buena parte del trabajo de producto ha consistido en convertir conocimiento disperso —repartido entre copias del producto y entre personas— en documentación funcional utilizable como referencia común para definir, construir y responder a clientes.

El modelo está validado: un core configurable, un repositorio principal común, despliegue cloud u on-premises y ausencia de forks por cliente como criterio de producto.

La primera implantación real del producto se completó en agosto de 2026.

La configurabilidad es una decisión de producto antes que una decisión de arquitectura. Mientras las diferencias entre clientes se traten como excepciones legítimas, ningún equipo de ingeniería puede evitar los forks; cuando se convierten en parámetros del producto, la unificación deja de depender de la disciplina individual.

Qué fue responsabilidad directa y qué fue trabajo compartido.

Owned / accountable

Dirección de producto del nuevo core: alcance, criterio de configurabilidad y prioridades.

Led

Equipo específico de producto del programa, de 6 → 10 personas.

Partnered

Ingeniería y las áreas de operación que sostienen las instalaciones actuales.

Contributed

Definición funcional de las capacidades críticas rediseñadas.