Planifica en papel antes de construir

Clic para la sección anterior: Etapa 1

Las decisiones de arquitectura son las más baratas de tomar y las más caras de equivocar; por eso la Etapa 2 ocurre en papel. Con requisitos sólidos en la mano desde la Etapa 1, aquí es donde creas el plan de alto nivel para cumplirlos. Piensa en la arquitectura del sistema como diseñar una ciudad antes de construir casas o carreteras: decides dónde van las autopistas y los puentes antes de verter el hormigón. En un proyecto IoT, eso significa esbozar el sistema completo en papel o pizarra (el «papel» digital también vale) antes de soldar o programar nada. Esta etapa trata de pensar en el conjunto: tomar ahora las decisiones clave que darán forma al diseño después. Al final de la Etapa 2 tendrás un plano claro de tu producto IoT, y los planos son mucho más baratos de cambiar que las placas de circuito.

Visualiza todo el sistema con un diagrama de bloques

El primer paso es dibujar un diagrama de bloques de todo el sistema: el plano de planta del arquitecto para tu dispositivo IoT y su ecosistema. Esboza todos los componentes principales y muestra cómo se conectan y comunican. Un diagrama de bloques IoT simple podría verse así:

• Sensor → Microcontrolador (MCU/SoC) → Radio inalámbrica → Servidor cloud → App web/móvil (cliente)

Esta cadena es el camino de datos de extremo a extremo. El sensor recoge datos y los alimenta al MCU. El microcontrolador puede procesar algo y luego usa una radio inalámbrica (Wi-Fi, Bluetooth, LoRa, etc.) para enviar los datos a un servidor cloud. El servidor almacena o analiza los datos y los pone a disposición de una interfaz de usuario: un dashboard web o una app móvil. Con el flujo desplegado, todo el equipo puede ver todas las piezas de un vistazo y entender cómo viajan los datos por el sistema.

No te preocupes por las dotes artísticas: cajas y flechas simples bastan. El objetivo es la claridad. El diagrama de bloques es el mapa de conjunto de tu «ciudad» IoT: muestra los componentes centrales y cómo interactúan, y previene malentendidos como que una persona asuma que el dispositivo habla directamente con una app de teléfono mientras tú pretendías que pasara por una API cloud. Cuando todos ven el mismo mapa, menos gente se pierde después.

Decisiones de partición: ¿quién hace qué (y dónde)?

Con el sistema dibujado, el siguiente paso es la partición: decidir qué responsabilidades viven dónde. Quién hace qué: qué tareas pertenecen al hardware/dispositivo, cuáles al firmware y cuáles al lado cloud o servidor. Estas decisiones afectan al rendimiento, el coste, la complejidad y la seguridad.

Algunos ejemplos de decisiones de partición en un sistema IoT:

• Procesamiento de datos: ¿los datos crudos del sensor deberían procesarse o filtrarse en el dispositivo, o enviarse en crudo a la nube para el procesamiento pesado? Procesar en el dispositivo reduce el ancho de banda y la carga cloud, pero necesita un MCU más potente y puede gastar más batería. Enviar datos crudos mantiene el dispositivo más simple, pero el backend debe ser robusto y el enlace de datos necesita suficiente ancho de banda.
• Seguridad de los datos: ¿cifrarás o comprimirás los datos en el dispositivo antes de enviarlos, o lo gestionarás en la nube? Cifrar en el dispositivo protege los datos desde el momento en que salen del sensor, pero exige más del MCU. Hacerlo en la nube mantiene el dispositivo más simple, pero los datos viajan sin proteger durante un tramo: inaceptable en aplicaciones sensibles.
• Almacenamiento e inteligencia: si la conexión cloud cae, ¿el dispositivo simplemente almacena los datos localmente en un buffer, o incluso toma decisiones locales? ¿Puede operar en un modo «degradado» sin la nube? Decidirlo ahora influye en si necesitas memoria o almacenamiento extra en el dispositivo, o lógica extra para escenarios offline.

La partición es un acto de equilibrio: cada parte del sistema debería encargarse de lo que mejor hace. Un pequeño sensor a batería es bueno recogiendo datos y procesando ligero; el número-crunching pesado pertenece a un servidor cloud con energía de sobra. A la inversa, si la aplicación necesita respuesta muy rápida o debe funcionar sin internet, más inteligencia se mueve al edge. No hay una respuesta única: los compromisos vienen de tus requisitos de la Etapa 1.

Iterar sobre estas elecciones es completamente normal. Puedes empezar con «nuestro dispositivo lo hará todo: preprocesamiento, cifrado, toma de decisiones» y luego darte cuenta de que el MCU elegido no puede con la carga de trabajo, o de que su memoria es demasiado pequeña. Ese hallazgo puede mover tareas a la nube. O al revés: procesamiento planeado para la nube se mueve al dispositivo porque la latencia de red es una preocupación. Cazar estos problemas en papel es mucho más barato que descubrirlos después de escrito el código o fabricada una PCB que no puede soportar el firmware. Tómate el tiempo de dividir bien las responsabilidades.

Selección de tecnología: eligiendo las herramientas adecuadas para cada parte

Con un diagrama de bloques y la partición en su sitio, llega la selección de tecnología: decidir las tecnologías o componentes reales para cada bloque, o al menos acotar las opciones. Piensa en ello como elegir materiales para cada parte de un edificio: estructura de acero o madera, paredes de ladrillo o hormigón. En términos IoT, las consideraciones clave incluyen:

• Sensores: ¿qué sensor(es) necesitas? Esto fluye de los requisitos. Lecturas de temperatura de alta precisión pueden pedir un sensor de temperatura digital con interfaz I²C; un detector simple de umbral puede valer con un sensor analógico y un ADC. Considera precisión, consumo, coste y facilidad de interfaz con el MCU.
• Microcontrolador (MCU) o System-on-Chip: elige el cerebro del dispositivo. ¿Debe ser de ultra bajo consumo (para funcionar años con una pila de botón)? ¿Necesita potencia de procesamiento o memoria (para procesamiento en el dispositivo, machine learning o múltiples sensores)? ¿Qué hay del ecosistema: un proveedor preferido, o herramientas de desarrollo específicas? Podrías acotarlo a: «Probablemente un MCU de la familia ARM Cortex-M4: CPU decente y coma flotante para los cálculos del sensor, con modos de bajo consumo para funcionar a batería».
• Conectividad (radio inalámbrica): selecciona cómo se comunica el dispositivo, según alcance, potencia y necesidades de datos. Para un wearable que habla con un smartphone, Bluetooth Low Energy (BLE) encaja bien. Para un gadget doméstico con Wi-Fi disponible, el Wi-Fi es cómodo para la conectividad cloud. Para dispositivos remotos o de área amplia, considera IoT celular (LTE-M, NB-IoT) o radios de largo alcance en banda sin licencia como LoRa o Sigfox para necesidades de poco ancho de banda y largo alcance. Cada una tiene compromisos: Wi-Fi y celular dan acceso a internet pero consumen más; BLE es de bajo consumo pero corto alcance; LoRa es de largo alcance y bajo consumo pero solo para paquetes pequeños.
• Fuente de alimentación: ¿cómo se alimenta el dispositivo? Si va a batería, esa elección da forma a todo lo demás. Una pila de botón exige componentes de ultra bajo consumo en toda la placa —MCU, radio, incluso el sensor— y funciones de gestión de energía como modos de sueño o un protocolo de comunicación eficiente. La alimentación de red te da libertad para usar Wi-Fi tragón o un procesador más fuerte. Considera también el tipo de batería (Li-ion recargable frente a reemplazable) y cualquier circuitería de carga.
• Otros componentes: según el sistema, puede haber más selecciones: pantalla o hardware de UI (LEDs, pantallas, botones), actuadores (motores, relés). Todavía no necesitas números de parte finales para todo, pero deberías tener una lista corta de candidatos probables para cada componente principal.

Seleccionar tecnologías en la etapa de arquitectura mantiene las piezas compatibles entre sí y con los requisitos, y permite comprobaciones aproximadas de coste y viabilidad. Si «probablemente» necesitas un MCU de gama alta y una radio específica de largo alcance, puedes hacer una comprobación de cordura de que el coste combinado cabe en el presupuesto y de que las piezas pueden trabajar juntas (¿interfaces adecuadas? ¿soporte de drivers?). Podrías descubrir que un módulo de radio que te gusta solo se empareja con cierta familia de MCU o necesita un MCU externo: bueno saberlo ahora.

También ten en mente la potencia y el tamaño. Un dispositivo diminuto a batería (un wearable, un sensor remoto) puede forzar un system-on-chip que integra MCU + radio para ahorrar espacio y energía. Un dispositivo muy sensible al coste puede favorecer un módulo todo en uno que combine sensor, MCU y radio. Esta es la etapa para hacer malabarismos con estas opciones en papel y ver qué stack encaja mejor en el proyecto.

Análisis de riesgos y costes: identifica las trampas potenciales pronto

Incluso en esta etapa, un buen arquitecto empieza a listar los riesgos y costes asociados al diseño elegido. Marcarlos ahora es mejor que descubrirlos después. Cosas a considerar:

• Disponibilidad de componentes y lead times: ¿el diseño depende de un componente que podría ser difícil de conseguir? Es común encontrar el chip «perfecto» y luego saber que tiene un lead time de 30 semanas o está perpetuamente agotado. Un sensor de vanguardia puede cumplir todas las especificaciones pero ser tan nuevo que el suministro es limitado. Identifica esos componentes pronto y prepara respaldos o planes de aprovisionamiento. Lo mismo aplica a los componentes de fuente única: un proveedor, un punto de fallo.
• Drivers de coste: escanea el diagrama de bloques y el BOM aproximado buscando elementos caros. Un MCU de gama alta o un módulo celular puede dominar el coste; ¿el caso de negocio lo permite? Si no, reconsidera ahora. El volumen también importa: 2 $ extra por dispositivo está bien para 10 prototipos pero es significativo con 100.000 unidades. Ajusta la arquitectura si hace falta: quizá el MCU con 1 MB de flash no es necesario si 256 KB más un poco más de procesamiento cloud servirían.
• Puntos únicos de fallo: piensa en la fiabilidad. ¿Todo el sistema se rompe si un componente falla o se queda offline? Si el dispositivo pierde la conectividad cloud, ¿queda inútil? Si es así, añade respaldo local: aunque solo sea almacenar datos para enviar después, o un «modo offline» básico. Si el sistema pivota sobre un único servidor cloud, considera redundancia o al menos un plan de caída. Detectar los puntos débiles ahora te permite diseñar mitigaciones: una pequeña batería de respaldo para el reloj en tiempo real, memoria para registrar datos cuando falta la energía o la red.
• Problemas regulatorios y de cumplimiento: un riesgo arquitectónico a menudo pasado por alto. Una tecnología inalámbrica dada puede requerir certificación FCC/CE por emisiones de radio; ciertas bandas de frecuencia tienen restricciones legales en algunos países. El uso sanitario o industrial trae sus propias normas (regulaciones de dispositivos médicos, grados de seguridad). Resalta las necesidades de cumplimiento conocidas ahora para poder presupuestar tiempo y dinero para ellas. Un módulo celular puede necesitar certificaciones de operador, que llevan tiempo; LoRa en una región dada significa respetar límites de duty cycle y potencia. Detectarlas pronto evita el «no podemos enviar porque nunca nos certificamos» de última hora.
• Riesgos de integración y complejidad: marca cualquier cosa técnicamente arriesgada: una plataforma IoT muy nueva, una biblioteca de firmware experimental. Reconócela como riesgo: planifica un prototipo rápido o un spike de investigación para probarla, y mantén un plan B. La conciencia temprana de «qué podría salir mal» te permite diseñarlo fuera o preparar la alternativa.

Un análisis de riesgos y costes en la Etapa 2 significa entrar al desarrollo con los ojos abiertos. Si la parte más arriesgada es un algoritmo de machine learning a medida en el dispositivo, abórdala primero o vigílala de cerca. Si el componente más caro es cierto sensor, sé cuidadoso con el presupuesto en el resto. Ningún producto está libre de riesgos, pero la planificación proactiva es lo que separa los proyectos tranquilos de las carreras de última hora.

Documentar la arquitectura con claridad

Al final de la etapa de arquitectura, documenta la arquitectura del sistema para que sea comprensible y compartible por todo el equipo. Este documento se convierte en el plano al que todos se refieren, así que tiene que vivir en algún sitio accesible: no encerrado en la cabeza del ingeniero principal.

Formas clave de capturar y comunicar la arquitectura:

• Diagramas visuales: muestra el sistema desde distintas perspectivas. Un diagrama de bloques simple (como el de arriba) cubre el contexto de alto nivel del hardware y las principales piezas de software. Algunos equipos usan notaciones formales como SysML o el modelo C4: opcional, pero útil. El punto es ilustrar cómo interactúan hardware, firmware, servicios cloud y usuarios. Para el software (firmware del dispositivo y cloud), un diagrama de componentes UML —o incluso un boceto anotado— puede mostrar qué módulos corren en el dispositivo frente al servidor. No te eches atrás por los acrónimos: cajas etiquetadas y flechas en cualquier herramienta comunican bien. Usa el estilo que tu equipo lea mejor.
• Resumen escrito: acompaña los diagramas con una breve descripción de cada bloque y su papel: «MCU: responsable de leer el sensor y cifrar los datos»; «Cloud: responsable del almacenamiento de datos, la analítica y de proporcionar la REST API para la app». Unos párrafos o viñetas bajo el diagrama eliminan la ambigüedad.
• Bill of Materials (BOM) preliminar: empieza una hoja de cálculo básica de BOM listando los componentes clave (sensor, MCU, módulo de radio) con notas sobre coste estimado, proveedor y lead time o disponibilidad. No cada resistencia y condensador —esos llegan en el diseño detallado— solo las piezas mayores, para que el coste unitario y los riesgos de la cadena de suministro sean visibles. Si el BOM muestra el módulo inalámbrico a 10 $ y todo lo demás a 2 $ combinados, ves de inmediato dónde importa la optimización de coste. Si dos piezas mayores vienen del mismo proveedor, anótalo también: conveniente, o un riesgo.
• Notación y consistencia: con varias personas contribuyendo, acordad la nomenclatura. Si el diagrama dice «Device CPU», otros documentos no deberían alternar entre «microcontrolador» y «CPU» al azar: la inconsistencia confunde. Mantén las etiquetas consistentes y la documentación bajo control de versiones (un documento compartido o una página de wiki basta). Muchos equipos recopilan los diagramas y notas en un breve Documento de arquitectura que circula para feedback y sirve de referencia durante el desarrollo.

El objetivo: cualquier miembro del equipo —incluido uno recién llegado— puede mirar la arquitectura y ponerse al día rápidamente. También ayuda con stakeholders no ingenieros: los product managers o ejecutivos puede que no lean tu código, pero sí pueden leer un diagrama de alto nivel. Una buena documentación de arquitectura tiende un puente entre las ideas y la implementación.

«Diseña dos veces, construye una»: ahorra tiempo con planificación temprana

Hay un mantra en ingeniería: «diseña dos veces, construye una». Cazar y corregir problemas en un diseño en papel es mucho más barato que corregirlos en un producto construido: esa es toda la filosofía de la Etapa 2. Mover cajas y flechas en un diagrama duele mucho menos que rehacer una PCB o reescribir un módulo de firmware porque el plan original resultó defectuoso.

Usa esta etapa para alinear pronto a todo el equipo. La arquitectura es multidisciplinar: ingenieros de hardware, desarrolladores de firmware, ingenieros de cloud/backend, product managers. Todos deberían tener voz en la revisión, así que fomenta la discusión. Un ingeniero de cloud puede decir: «Si el dispositivo etiquetara cada lectura con un timestamp antes de enviarla, mi lado del servidor sería más simple»: una petición pequeña, si la conoces por adelantado. Un diseñador de hardware puede señalar: «Usamos dos sensores ahora, pero un tercero nos permitiría medir la calidad del aire: ¿dejamos espacio para él?». Hallazgos como estos llevan a pequeños ajustes de arquitectura, o al menos a previsiones para expansión futura, que nunca afloran cuando los equipos trabajan aislados. Limar los puntos de interfaz ahora es mejor que el momento «esto ya no podemos cambiarlo» de después.

La exhaustividad aquí construye confianza. Al final de la Etapa 2 deberías tener un plano claro: un diseño de alto nivel que muestra cómo piensas cumplir los requisitos de la Etapa 1. Como el plano de un edificio, todavía no elige colores de pintura ni pomos de puerta, pero las plantas, puertas, ventanas y la distribución de las habitaciones están fijadas. En términos IoT: sabes qué son los dispositivos, cómo se conectan, qué datos fluyen adónde y, aproximadamente, qué tecnología hace el trabajo.

Con ese plano en la mano, puedes pasar al diseño detallado y la implementación con confianza. Has creado un mapa para el viaje IoT, así que es mucho menos probable que te pierdas. En la Etapa 3 y siguientes —construir hardware, escribir código— te referirás a esta arquitectura constantemente. Y cuando lleguen los cambios (siempre llegan), actualiza el documento de arquitectura para que siga siendo una referencia fiable.

En resumen: la Etapa 2, Arquitectura del sistema, es donde preparas el proyecto para el éxito. Alinea al equipo, expone los riesgos pronto y proporciona un plan claro. Lo diseñaste —quizá dos veces—, así que ahora puedes construirlo una vez, y construirlo bien. Mantén el plano cerca; será tu estrella polar para el resto del viaje.