Planificar la arquitectura informática: menos dependencias, decisiones más claras

La arquitectura describe responsabilidades, además de sistemas

La arquitectura determina dónde residen los datos, cómo se comunican las aplicaciones y qué ocurre si algo falla. Esas decisiones determinan si una función nueva es sencilla o requiere primero coordinar cinco proveedores y tres conjuntos de datos. Un diagrama lleno de productos de moda no responde esas preguntas.

Sencillo no significa un servidor ni la mínima tecnología a cualquier precio. Una copia de seguridad adicional o un segundo servidor de aplicación pueden estar justificados. La complejidad se vuelve problemática cuando su beneficio no está claro, nadie la mantiene o sus dependencias solo aparecen durante un incidente.

Empezar por tres flujos empresariales concretos

Trace procesos como atender una consulta, servir un pedido y emitir una factura a través de aplicaciones, identidad, almacenamiento e interfaces externas. Incluya adjuntos de correo, hojas de cálculo y trasvases manuales; un inventario de servidores por sí solo no refleja esas fuentes de retraso.

Concrete los requisitos. ¿Puede esperar una consulta diez minutos durante el mantenimiento? ¿Debe trabajar el personal durante una caída de internet? ¿Cuántos usuarios simultáneos se esperan y qué información puede llegar más tarde? Estas respuestas orientan mejor el alojamiento, la sincronización y la redundancia que una regla general de solo nube o solo oficina.

Cuándo un componente adicional justifica su coste operativo

Cada componente necesita un desencadenante medible y un responsable operativo. Una caché que ahorra solo unos milisegundos mientras sus entradas obsoletas generan soporte repetidamente merece reconsiderarse. Separar una importación que bloquea toda la aplicación durante el horario laboral puede tener un beneficio evidente.

• Caché: justificada por retrasos medidos en lecturas repetidas; defina validez, actualización y comportamiento ante fallos.
• Cola: evita que el trabajo lento en segundo plano bloquee solicitudes; gestione reintentos, orden y tareas fallidas.
• Servicio separado: permite publicaciones independientes o una capacidad sustancialmente distinta; asuma la responsabilidad de su interfaz, datos y supervisión.
• Segunda sede: responde a un requisito empresarial de sobrevivir a la pérdida de una sede; pruebe periódicamente replicación, conmutación y retorno.

Monolitos y microservicios no son niveles de calidad

Una aplicación modular puede tener límites de negocio sólidos y entregarse como un único despliegue. Un sistema distribuido puede seguir fuertemente acoplado. Los microservicios permiten desarrollo y escalado independientes, pero introducen requisitos de comunicación, consistencia y operación, como explica la comparación de arquitecturas de Microsoft.

Un equipo pequeño que publica conjuntamente puede beneficiarse de un monolito modular con interfaces claras entre clientes, pedidos y facturación. Después puede añadirse un servicio de procesamiento de imágenes separado cuando su carga crezca de forma independiente. Los contenedores pueden empaquetar cualquiera de los diseños; adoptarlos no exige dividir la aplicación en microservicios.

Ejemplo: portal de clientes, sistema de inventario y contabilidad

Dar a un portal nuevo acceso directo de escritura a las bases de inventario y contabilidad crea un atajo, pero acopla sus publicaciones a dos esquemas externos. Una actualización de cualquiera de los productos puede interrumpir inesperadamente el flujo del cliente.

Un diseño más claro identifica al sistema de inventario como responsable de los registros operativos de clientes, a contabilidad como responsable de los documentos contabilizados y al portal como responsable de los datos de acceso y las preferencias de visualización. Las interfaces acordadas transfieren la información necesaria. Muestre su momento de actualización cuando sea necesario, en vez de prometer datos en tiempo real que no están garantizados.

Esta separación también cuesta esfuerzo: versione interfaces, haga visibles los fallos de transferencia y gestione los reintentos sin ambigüedad. Para una herramienta interna pequeña puede bastar una interfaz de lectura más sencilla y documentada. Decida según los requisitos de cambio, las consecuencias del fallo y la capacidad del equipo.

Registrar las decisiones y comparar su coste operativo completo

Un registro de decisión arquitectónica (ADR) recoge una decisión, su contexto, alternativas y consecuencias. Debe poder sustituirse explícitamente por otro. El proceso ADR de AWS describe ese ciclo de vida; conservar el razonamiento importa más que la longitud del documento.

Un registro del portal podría indicar que la información del cliente permanece en el sistema de inventario porque su personal mantiene el registro autoritativo, mientras el portal muestra una vista de lectura sincronizada con una demora acordada. Revise esa elección cuando los clientes deban realizar por sí mismos cambios vinculantes.

Compare implementación, infraestructura, licencias, soporte, incorporación y salida para el mismo período y requisitos. Un alojamiento barato puede salir caro si cada ajuste requiere conocimientos escasos. Las plataformas gestionadas pueden reducir trabajo, pero introducen dependencias contractuales y de exportación.

Utilizar pruebas concretas en una revisión de arquitectura

Empiece con tres vistas: el recorrido del usuario entre sistemas, la responsabilidad sobre los datos importantes y el despliegue entre sedes o proveedores. Etiquete la finalidad y dirección de cada conexión. Marque las transiciones desconocidas como preguntas, en vez de esconder las lagunas de conocimiento detrás de un diagrama aparentemente completo.

Añada cambios e incidentes recientes pertinentes. ¿Qué dependencia sorprendió al equipo? ¿Dónde tuvieron que actuar varios equipos conjuntamente? ¿Qué causó trabajo manual recurrente? Derive unas pocas modificaciones justificadas, en vez de sustituir todo el entorno según preferencias tecnológicas personales.

Tres demostraciones hacen comprobable el diseño objetivo

Para la capacidad de cambio, trace una modificación empresarial típica a través de componentes, personas, pasos manuales y tiempo de aprobación. Para la recuperación, pruebe la alternativa o restauración prevista de un flujo importante en un entorno adecuado. Para la entrega, pida a una segunda persona realizar una tarea habitual utilizando solo la documentación.

Acuerde primero los criterios de éxito: un tiempo de respuesta, una ventana de recuperación o una publicación completada sin preguntar al desarrollador original. Los valores deben ajustarse al negocio. El objetivo es avanzar frente a limitaciones observadas, no obtener una puntuación universal de arquitectura.

Construir una hoja de ruta con desencadenantes

No es necesario construir inmediatamente todas las ampliaciones posibles. Empiece con una operación estable y vincule la inversión posterior a una condición medida. Separe una tarea en segundo plano cuando incumpla repetidamente el objetivo de respuesta; añada una segunda sede cuando el proceso necesite tolerar la pérdida de una ubicación, aunque haya poco tráfico.

Asigne a cada decisión un responsable y un desencadenante de revisión: cambios de horario, muchos más usuarios, una nueva categoría de datos, un contrato que caduca o incidentes repetidos. Estos desencadenantes justifican la inversión y conservan opciones mejor que un rediseño completo arbitrario cada pocos años.