Construye para hoy. Planifica para mañana. Planifica para el fallo.
También en 28 idiomas
English · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Módulo 5 de 7 del capítulo Pensar como un arquitecto de datos, el primer capítulo del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: La arquitectura es el arte de las compensaciones · Siguiente: Conoce tus herramientas: las nueve preguntas
La pregunta que responde este módulo: ¿Cómo diseñas para los requisitos de hoy mientras planificas para el crecimiento y para el fallo?
Uno de los errores más fáciles en arquitectura es diseñar solo para los requisitos que tienes delante. Tenemos un proyecto, un backlog y requisitos. Construimos algo que los cumple. Funciona, y cantamos victoria. Seis meses después el negocio cambia, o los datos crecen, u otra unidad de negocio quiere usarlo, o adquirimos una empresa, o un sistema nuevo necesita integrarse, o falla algo para lo que nadie se preparó.
Nada de eso debería sorprender a un arquitecto. No podemos predecir todo lo que va a pasar, pero podemos diseñar sabiendo que algo pasará. Por eso miro la arquitectura a través de tres lentes:
Construye para hoy. Planifica para mañana. Planifica para el fallo.
Necesitas las tres.
Construye para hoy
Sección titulada «Construye para hoy »La arquitectura empieza por el problema que realmente tenemos. Suena obvio, pero los arquitectos podemos cometer el error contrario al pensamiento de corto plazo: podemos sobrediseñar. ¿Y si adquirimos doce empresas, tenemos mil millones de clientes, nos expandimos a 40 países y cada sistema necesita integración en tiempo real? Quizá. Pero ¿son posibilidades reales o estamos inventando problemas? La arquitectura no trata de construir el sistema más sofisticado que podamos imaginar. Trata de construir el adecuado.
Así que empieza por hoy: lo que necesita el negocio, los volúmenes, usuarios y transacciones reales, con qué frecuencia cambian los datos y qué tan rápido tienen que moverse, quién necesita acceso, y de dónde vienen y adónde van los datos. Y, sobre todo: ¿por qué? Esas respuestas nos dan algo concreto que diseñar.
Busca los requisitos implícitos
Sección titulada «Busca los requisitos implícitos »Los requisitos que te dan no son necesariamente todos los requisitos que tienes. Casi siempre hay requisitos implícitos.
El negocio dice: “Necesitamos los datos de clientes en Salesforce”. Bien. Entonces alguien tiene que ser dueño de esos datos y decidir qué tan actualizados deben estar. Necesitamos saber qué pasa cuando el sistema de origen está caído, cómo nos daremos cuenta cuando falle la sincronización y qué lado gana cuando Salesforce y el origen no coinciden. Necesitamos un período de retención, un modelo de acceso, una decisión sobre los campos sensibles y una forma de corregir los datos malos.
Nada de eso estaba en la historia de usuario. Todo sigue siendo arquitectura. Gran parte de convertirse en arquitecto es aprender a reconocer las preguntas que todavía no se han hecho.
Conoce tus números
Sección titulada «Conoce tus números »Empujo constantemente a los arquitectos a cuantificar. No me digas que hay muchos datos; dime cuántos. ¿Diez mil, diez millones, cien millones, mil millones? Son arquitecturas muy distintas. No me digas que la integración se ejecuta con frecuencia: ¿cada hora, cada minuto, mil veces por segundo? No me digas que estamos creciendo rápido. ¿Qué tan rápido?
Cuando no tengo un número mejor, mi base es un crecimiento anual del 30 %. No es una predicción; es una forma de forzar la conversación. Si alguien me dice que hoy tenemos 10 millones de registros, no quiero que la discusión se quede en 10 millones. Al 30 % anual estaremos en unos 13 millones el año que viene, 17 millones el siguiente y unos 22 millones el año después. Ahora hablemos del diseño. Si el negocio me dice que el 30 % es ridículo, perfecto: dame el número real. La idea es que el crecimiento forme parte de la discusión de arquitectura.
A esto lo llamo el Número de Ceros de Steve (Steve’s Number of Zeros). Un cero de más puede cambiar por completo tu arquitectura. Diez mil, cien mil, un millón, diez millones, cien millones: la funcionalidad no cambió y puede que el requisito tampoco, pero la arquitectura sí podría.
¿Recuerdas las citas del módulo 1? Pongámosles los números reales. Más de 1.200 locales, 100 citas por local al día, seis días a la semana, unos 305 días al año. Son más de 36 millones de citas en el primer año. Cada visita crea dos registros, así que más de 73 millones de registros. Ahora conserva cinco años de historial, creciendo un 30 % al año, y pasas de 650 millones de registros. La misma funcionalidad, el mismo requisito. Un par de ceros más y una arquitectura muy distinta.
Planifica para mañana
Sección titulada «Planifica para mañana »Una vez que entiendo el hoy, miro hacia adelante: ¿qué es razonablemente probable que cambie? El volumen es parte de ello, pero mañana no es solo más. También puede significar distinto: más productos, unidades de negocio y países; requisitos de privacidad diferentes; nuevos canales e integraciones; una fusión o adquisición; una nueva estrategia de datos maestros o plataforma de analítica; un agente de IA consumiendo información que se diseñó solo para personas.
Por eso me importa tanto que la arquitectura pueda crecer por adición en lugar de por mutación constante. Si el negocio agrega un producto, ¿el modelo lo admite? Si otro sistema necesita los datos, ¿podemos exponerlos de forma limpia? Si el volumen se dispara, ¿tenemos adónde ir? Si cambia la estructura del negocio, ¿tendremos que desarmar el modelo de datos? No intentamos predecir el futuro a la perfección. Intentamos no acorralarnos.
No construyas hoy el mañana
Sección titulada «No construyas hoy el mañana »Aquí hay un equilibrio. Planificar para mañana no significa construir hoy el sistema de mañana. Si tenemos 100.000 registros y podríamos tener 100 millones en cinco años, eso no significa construir ahora la arquitectura de 100 millones de registros. Puede traer un costo y una complejidad que todavía no necesitamos.
La pregunta que quiero responder es: ¿puede la arquitectura de hoy evolucionar hacia la de mañana? Si podemos empezar de forma simple con un camino claro hacia adelante, eso suele ser mejor que pagar el costo de la complejidad años antes. El peligro no es empezar en pequeño. El peligro es empezar en algún lugar sin ningún sitio adonde ir.
Planifica para el fallo
Sección titulada «Planifica para el fallo »Ahora la parte de la que a nadie le gusta hablar: las cosas fallan. Nunca he diseñado un sistema en el que cada componente estuviera disponible para siempre, cada integración tuviera éxito, cada usuario ingresara datos perfectos y cada sistema externo se comportara exactamente como dice su documentación. Así que no diseñes ese sistema.
Pregunta qué puede fallar y luego pregunta qué pasa cuando falla. Una integración agota el tiempo de espera. Una API rechaza una solicitud. Una carga nocturna procesa 800.000 registros y falla en 200.000. Un sistema de origen se cae. Un usuario ingresa datos no válidos. Un identificador externo aparece dos veces. Un sistema de más arriba cambia el formato de un valor sin cambiar el nombre del campo. Un proceso tiene éxito en un sistema y falla en otro. No son casos límite inusuales. Así se ve producción.
Un éxito parcial sigue siendo un fallo que tienes que entender
Sección titulada «Un éxito parcial sigue siendo un fallo que tienes que entender »Los fallos parciales son especialmente peligrosos en arquitectura de datos. Imagina mover un millón de registros y que el proceso informe que terminó. Genial. Pero ¿llegó un millón, o 999.997, y cuáles son los tres que faltan? Quizá fallaron 200.000, algunos se crearon dos veces, o todo llegó y algunos campos fallaron en la transformación.
“Trabajo completado” no es lo mismo que los datos son correctos. Un arquitecto de datos piensa en la conciliación: ¿cómo sabemos qué debería haber pasado, qué pasó realmente y cuál es la diferencia? ¿Y qué hacemos al respecto?
Esto es lo que hago cuando los sistemas se complican. Los registros van de A a B, de izquierda a derecha. Luego B devuelve algo: una confirmación por cada registro que recibió y guardó. Ahora A puede comparar lo que envió con lo que se confirmó. Si cada registro tiene su confirmación, la ejecución tuvo éxito. Si falta alguna confirmación, no lo tuvo, diga lo que diga el estado del trabajo, y sabemos exactamente qué registros atender: reintentarlos, enviarlos a una persona o lanzar una alerta.
Falla con elegancia
Sección titulada «Falla con elegancia »Cuando ocurre un fallo, quiero saber qué hace el sistema a continuación: si reintenta, y si lo hace automáticamente o no; qué pasa si la misma transacción se procesa dos veces; adónde van los registros fallidos y si los registros buenos siguen fluyendo después de uno malo; a quién se alerta, con qué información, y cómo vuelve a ejecutar lo que falló; y cómo se entera un usuario de que algo salió mal.
Y, sobre todo: ¿podemos recuperarnos sin empeorar el problema? Una estrategia de reintentos que crea datos duplicados no es una gran estrategia de recuperación. La buena arquitectura asume el fallo y nos da un camino de vuelta.
Monitorea lo que importa
Sección titulada «Monitorea lo que importa »Planificar para el fallo sin monitoreo no es realmente planificar. Si una integración falla a las 2:00 a. m. y nadie se da cuenta hasta que un cliente llama tres días después, no teníamos una arquitectura operativa. Teníamos esperanza.
Decide qué tiene que ser observable: ¿se ejecutó el proceso, cuánto tardó, cuántos registros se procesaron, cuántos tuvieron éxito y cuántos fallaron? ¿Los volúmenes son de repente distintos de lo normal? ¿Crece el trabajo pendiente, aumentan los errores? La arquitectura no termina cuando el despliegue tiene éxito. Alguien tiene que operar este sistema mañana, y eso es parte del diseño.
Piensa en las tres direcciones
Sección titulada «Piensa en las tres direcciones »Sigue aplicando las tres lentes durante el resto del curso. Cuando diseñamos un modelo de datos: ¿funciona hoy, puede crecer mañana y qué pasa cuando los datos están mal o incompletos? Una integración: ¿mueve los datos de hoy, puede con el volumen y los sistemas de mañana y qué pasa cuando un lado está caído? Grandes volúmenes de datos: ¿qué tenemos hoy, hacia dónde van los números y cómo nos recuperamos cuando una operación grande solo tiene éxito en parte?
La tecnología cambia de un capítulo a otro. Las preguntas no.
La arquitectura existe a lo largo del tiempo
Sección titulada «La arquitectura existe a lo largo del tiempo »Un desarrollador a veces puede mirar un requisito y preguntar: “¿Esto funciona?”. El arquitecto tiene que preguntar más: ¿funciona hoy, seguirá funcionando mañana y qué pasa cuando no funcione en absoluto? Esas tres preguntas nos llevan más allá de la implementación y hacia la vida del sistema.
No predecirás cada requisito futuro ni evitarás cada fallo. Ese no es el objetivo. El objetivo es construir algo adecuado para lo que sabemos hoy, dejarnos un lugar adonde ir mañana y tener un plan para cuando la realidad no coopere.
Construye para hoy. Planifica para mañana. Planifica para el fallo. Usaremos esas tres lentes una y otra vez.
Lo que decide aquí un arquitecto
Sección titulada «Lo que decide aquí un arquitecto »- Cuáles son los volúmenes y el crecimiento reales, y qué números cambiarían el diseño.
- Qué requisitos implícitos aún no ha dicho el negocio.
- Cómo puede evolucionar el diseño de hoy hacia el de mañana, sin construir hoy el sistema de mañana.
- Qué pasa cuando algo falla: recuperación, conciliación y monitoreo.