Reconstruir la arquitectura de datos de Tech Barcelona, y la confianza para migrar a ella
caso de estudio
Oriol SerraFounder & CEO
Toda organización que lleva unos cuantos años funcionando tiene el mismo problema silencioso. Los datos entran por más sitios de los que nadie sabe enumerar, salen por más puertas de las que nadie ha contado, y nadie ha tenido nunca una semana libre para decidir cómo debería funcionar todo eso.
No se rompe. Eso es justamente lo que lo hace peligroso.
Tech Barcelona vino a nosotros con una migración por hacer. Lo que de verdad necesitaba era la decisión que nadie había tomado todavía: por dónde entran nuestros datos y por dónde salen.
La organización
Tech Barcelona es una de las instituciones que mantienen unida a la comunidad tecnológica de la ciudad, conectando empresas, startups, inversores y organismos públicos. Marina Saurí es su Director of Strategy.
Una organización así funciona a base de relaciones, y las relaciones viven en los datos. Socios, partners, eventos, programas, solicitudes. Cada uno de ellos es un registro en el que alguien tiene que poder confiar.
La situación
Las herramientas se habían elegido de una en una, cada una por una buena razón, ninguna elegida junto a las demás. Así se construye casi cualquier stack.
Con el ritmo que lleva una empresa en el día a día, lo que pasa es que nunca te paras a ordenar las cosas: por dónde te entran los datos y por dónde te salen.
Marina Saurí, Director of Strategy, Tech Barcelona
La palabra que usó para el resultado fue desquadrat, descuadrado. No se hundió nada. Simplemente las cosas no encajaban, y cada pregunta tardaba más en responderse de lo que debería.
El problema real
Una migración es un trabajo técnico con un final claro. Mover los registros, redirigir las integraciones, apagar el sistema antiguo.
Esa nunca fue la parte difícil aquí.
No puedes salir con una migración de una estructura que nadie diseñó nunca. Solo trasladas la misma confusión a una herramienta más nueva.
Si hubiéramos hecho primero la migración, Tech Barcelona habría pagado un cambio de software y se habría quedado con el problema. La arquitectura tenía que decidirse antes de mover un solo registro, porque la arquitectura es lo que la migración iba a transportar.
Así que el trabajo empezó un paso antes de lo que pedía el brief: mapear por dónde entraban los datos, por dónde salían, quién era su dueño entre medias y cuáles de esos caminos existían a propósito.
El riesgo que no era técnico
Hay una parte de este trabajo que ningún documento de alcance cubre, y Marina la nombró antes de que hubiéramos hecho nada.
Siempre es más difícil trabajar con gente a la que no ves cada día. Con tu propio equipo mantienes el control: cualquier duda, cualquier problema que surja, lo resuelves en el momento. Trabajar con alguien externo siempre lleva ese miedo a que las cosas sean menos fluidas, menos ágiles.
Ese miedo es correcto. Es la postura por defecto acertada para cualquiera que ya haya contratado antes a un equipo externo.
Tampoco se puede responder con un discurso comercial. Solo se puede responder con cómo funciona de verdad el trabajo, semana tras semana, y por eso las dos cosas que ella acabó señalando no eran entregables en absoluto.
Qué construimos
Una arquitectura de datos, decidida antes del traslado. Por dónde entran los registros, por dónde salen, qué sistema es dueño de qué objeto y qué pasa en cada traspaso. Escrita como un modelo, no como conocimiento tribal.
La migración en sí. Ejecutada contra ese modelo, para que lo que aterrizara en el nuevo stack fuera la estructura que habíamos acordado y no una copia del desorden antiguo.
Documentación de cada paso. No un documento de traspaso escrito al final, sino la construcción registrada a medida que se construía.
Un flujo diario de información. El problema del equipo remoto resuelto de la única forma posible, eliminando la espera.
Cómo funcionó el trabajo
Esas dos últimas son la razón por la que el proyecto funcionó, y son de lo que habla Marina cuando le preguntan cómo fue.
Me gusta trabajar con Oriol porque tiene esa estructura mental de dejarlo todo documentado. Cuando trabajas con una empresa externa es muy difícil mantener ese seguimiento, y tenerlo todo documentado, el paso a paso, y ese flujo directo de información diario, eso nos ayudó muchísimo.
La documentación se suele vender como un entregable. Es más útil pensarla como lo que hace que contratar a un equipo externo sea seguro. El cliente puede ver cómo se construye el sistema, puede revisarlo sin preguntar y es su dueño en el momento en que termina el proyecto.
El flujo diario hace el mismo trabajo para la velocidad. El miedo era que un equipo de fuera fuera más lento que uno de dentro. La respuesta no es prometer lo contrario, es hacer el ciclo lo bastante corto como para que la pregunta deje de surgir.
Qué cambió
De momento, los datos están en su sitio, que ya es mucho.
Esa frase es todo el resultado, y merece leerse despacio. Datos en su sitio significa que cada pregunta posterior se vuelve más fácil: reporting, segmentación, seguimiento, cualquier cosa que alguien quiera construir después.
Marina también tiene claro qué parte no está terminada, y hace bien.
Siempre hemos tenido cierto pánico a dejar herramientas que conocemos y pasar a otras nuevas, y la adaptación de todo el equipo va más allá del propio proyecto. Pero estoy convencida de que hicimos bien el trabajo, todo está donde tiene que estar, y a partir de aquí irá mucho mejor.
Una migración termina. La adopción no. El sistema puede ser correcto el día que se entrega y aun así costarle a un equipo semanas habitarlo con comodidad, y fingir lo contrario es como se dan por terminados proyectos que todavía no han aterrizado.
Lo que hace una buena arquitectura es que esa adaptación valga la pena hacerla una sola vez. El equipo aprende una estructura que va a aguantar, en lugar de aprender otro apaño que habrá que reconstruir dentro de dos años.
Por qué importa
Este caso no tiene métricas de campaña, y no es un olvido.
Nada de esto iba de generar demanda. Iba de que una organización pudiera confiar en sus propios registros, y de demostrar que un equipo externo puede hacer trabajo estructural sin convertirse en una caja negra. Esas son las dos cosas que deciden si vale la pena empezar el siguiente proyecto.
Para quién es
Organizaciones que llevan funcionando el tiempo suficiente como para acumular herramientas, y que nunca tuvieron un trimestre libre para decidir cómo deberían encajar esas herramientas entre sí.
Donde nada está roto pero nada termina de encajar. Donde hay una migración sobre la mesa y la pregunta de fondo todavía no se ha hecho. Donde el equipo ya se ha quemado antes con un partner externo que entregó algo que solo él entendía.
Si os resulta familiar, el problema no es la herramienta que estáis dejando. Es que nadie dibujó nunca el mapa.
¿Planeáis una migración? Decidid primero la arquitectura.
30 minutos, y salís sabiendo por dónde entran y salen realmente vuestros datos, y qué tiene que cumplirse antes de mover cualquiera de ellos.
Solicitar una llamada estratégica
