Comprenda System Architecture en sistemas complejos: requisitos, arquitectura funcional, lógica y física, interfaces, viewpoints, trade-offs, baselines e integración.
¡Descúbrelo!
System Architecture es la estructura conceptual que organiza las funciones, elementos, relaciones, interfaces, restricciones y decisiones fundamentales de un sistema. En sistemas complejos, permite transformar necesidades de stakeholders y requisitos en una organización técnica coherente antes de que cada disciplina detalle de forma aislada componentes, software, equipos, redes o instalaciones.
La arquitectura no es simplemente un diagrama de bloques. Una arquitectura útil debe explicar qué responsabilidades existen en el sistema, dónde se implementarán, cómo se relacionan los elementos, qué interfaces son críticas, qué atributos de calidad deben preservarse y qué decisiones estructurales condicionan el desarrollo posterior.
ISO/IEC/IEEE 42010:2022 establece requisitos para las descripciones de arquitectura y organiza conceptos como stakeholders, concerns, viewpoints, views y model kinds. La norma no define una arquitectura “correcta” ni prescribe un método de diseño; proporciona una estructura para describir arquitecturas de forma consistente y trazable.
La arquitectura es diferente de la descripción de arquitectura
La arquitectura existe como organización fundamental del sistema aunque no esté completamente documentada. La descripción de arquitectura es el conjunto de representaciones utilizado para expresar esa organización a diferentes stakeholders.
Esta distinción es importante porque ningún dibujo aislado representa todo el sistema. Un plano físico puede mostrar equipos y espacios, pero no explicar comportamiento. Un diagrama lógico puede mostrar funciones y flujos, pero no la ubicación física. Una matriz puede registrar interfaces, pero no los estados operativos.
La descripción de arquitectura debe combinar views coherentes para responder a concerns diferentes sin crear versiones competidoras de la misma realidad.
Por qué los sistemas complejos necesitan una arquitectura explícita
Cuanto mayor sea el número de subsistemas, disciplinas y proveedores, mayor será el riesgo de que cada parte optimice localmente su propia solución. Un proveedor puede maximizar el desempeño de su equipo y, al mismo tiempo, aumentar el consumo de energía, la complejidad operativa o la dependencia de red del sistema completo.
Una arquitectura explícita crea una referencia común para evaluar estas decisiones. Permite preguntar si un cambio preserva redundancia, segregación, interoperabilidad, seguridad, mantenibilidad y otros atributos sistémicos.
En proyectos sin esta referencia, las decisiones tienden a tomarse por documento o disciplina. El impacto transversal aparece únicamente durante integración, commissioning u operación.
La arquitectura nace de las necesidades y los requisitos
La arquitectura no debe comenzar por un catálogo de equipos. Comienza por el problema que el sistema debe resolver y por los requisitos que condicionan la solución.
Systems Engineering establece esta secuencia al conectar necesidades de stakeholders, requisitos, arquitectura, integración y validación. La arquitectura ocupa el punto en el que funciones y restricciones empiezan a organizarse en una solución coherente.
Un requisito de disponibilidad, por ejemplo, puede generar decisiones sobre redundancia de alimentación, servidores, red, comunicaciones, almacenamiento y operación. El requisito es único; la arquitectura distribuye su realización entre varios elementos.
Concern, stakeholder y viewpoint
ISO/IEC/IEEE 42010 utiliza el concepto de concern para representar intereses o preocupaciones relevantes de stakeholders con respecto al sistema. Desempeño, seguridad, costo, disponibilidad, mantenimiento, integración y operación son ejemplos de concerns.
Un viewpoint define convenciones para construir una view que responda a determinados concerns. Esto evita intentar colocar toda la información en un único dibujo.
| Stakeholder | Concern típico | View útil |
| Operación | Modos operativos y contingencias | Comportamiento y estados |
| Mantenimiento | Accesibilidad, sustitución y diagnóstico | Descomposición física e interfaces |
| TI | Comunicación, autenticación y capacidad | Arquitectura lógica y de red |
| Seguridad | Fronteras, confianza y exposición | Flujos y zonas de seguridad |
| Ingeniería | Funciones, asignación y dependencias | Arquitectura funcional y física |
| Gestión | Riesgos, decisiones y trade-offs | View ejecutiva de arquitectura |
La calidad de la arquitectura depende de seleccionar views que apoyen decisiones reales, no de producir la mayor cantidad posible de diagramas.
Arquitectura funcional
La arquitectura funcional organiza lo que el sistema debe hacer sin asumir prematuramente dónde se implementará cada función. Descompone funciones de alto nivel en funciones menores e identifica relaciones, flujos y dependencias.
Esta separación entre función y solución física amplía el espacio de alternativas. Una función de autenticación, por ejemplo, puede ejecutarse localmente, centralizarse, distribuirse entre dispositivos o integrarse con un servicio corporativo. La arquitectura funcional ayuda a discutir la necesidad antes de elegir un producto.
Una descomposición típica avanza desde necesidades hacia requisitos, funciones del sistema, arquitectura lógica, elementos físicos, interfaces y, finalmente, integración y validación.
Una buena descomposición funcional también ayuda a identificar funciones ausentes, redundancias innecesarias y responsabilidades mal definidas entre subsistemas.
Arquitectura lógica
La arquitectura lógica organiza elementos abstractos que realizan funciones independientemente de una implementación física específica. Servicios, módulos de procesamiento, repositorios de datos, dominios de seguridad y componentes lógicos pueden existir en este nivel.
Es especialmente útil en sistemas que incluyen software, redes, automatización e integración. El objetivo es definir responsabilidades e interacciones antes de seleccionar servidores, appliances, dispositivos o topologías definitivas.
La arquitectura lógica funciona como puente entre el comportamiento funcional y la materialización física.
Arquitectura física
La arquitectura física representa equipos, dispositivos, instalaciones, componentes, redes, cables, tableros, servidores y otros recursos concretos que implementan la solución.
Debe mantener trazabilidad con requisitos y funciones. Un componente no debería existir simplemente porque “siempre se ha especificado”; su presencia debe justificarse por una función, atributo o restricción.
La arquitectura física también evidencia límites de suministro, ubicación, disponibilidad de espacio, alimentación, disipación térmica, accesibilidad de mantenimiento y otras restricciones que pueden modificar la solución lógica.
Las arquitecturas múltiples deben permanecer coherentes
Un sistema puede tener arquitectura funcional, lógica, física, de seguridad, de datos, de red y de implantación. Estas representaciones no deben tratarse como diseños independientes.
Cuando una función crítica se asigna a dos servidores redundantes, la arquitectura de red debe soportar esa redundancia; la alimentación debe ser compatible; el almacenamiento debe preservar consistencia; y operación debe saber cómo ocurre el failover.
La coherencia entre views es uno de los principales desafíos de Systems Architecture. MBSE — Model-Based Systems Engineering puede ayudar porque mantiene elementos y relaciones en una estructura común.
System of Interest y fronteras
Antes de definir la arquitectura, es necesario establecer el sistema de interés y sus fronteras. ¿Qué está dentro del sistema? ¿Qué es externo? ¿Qué servicios externos se asumen? ¿Qué responsabilidades pertenecen a otros contratos u organizaciones?
Las fronteras mal definidas generan requisitos huérfanos. Un sistema puede depender de Active Directory, la red corporativa, energía acondicionada, climatización, APIs externas o procedimientos operativos que no están bajo el control del proveedor principal.
La arquitectura debe representar estas dependencias explícitamente, incluso cuando el elemento externo esté fuera del alcance de suministro.
Context diagram: ver el sistema en su entorno
Una view de contexto muestra el sistema de interés y las entidades externas relevantes: usuarios, operadores, otros sistemas, redes, servicios, entorno físico y organizaciones.
El objetivo no es detallar componentes internos, sino comprender los intercambios en la frontera. ¿Qué datos entran y salen? ¿Quién suministra energía? ¿Qué sistema autentica a los usuarios? ¿Qué alarma debe compartirse? ¿Qué información se envía al centro de operaciones?
Esta view suele revelar interfaces que no aparecen cuando el equipo comienza directamente por el diseño interno.
Cuando el proyecto involucra varias disciplinas y contratos, las mayores exposiciones suelen aparecer en las interfaces. Una arquitectura independiente ayuda a definir fronteras, owners, requisitos y criterios de integración antes de que esas brechas se conviertan en cambios de alcance o retrabajo.
Las interfaces son una parte central de la arquitectura
Las interfaces definen cómo los elementos intercambian información, energía, señales, materiales, fuerzas, comandos o responsabilidades. En sistemas complejos, las fallas de interfaz suelen ser más frecuentes que las fallas de componentes individuales.
Una interfaz debe tener origen, destino, características, requisitos, ownership, estado de definición, responsabilidad de implementación y método de verificación. En contratos separados, también debe aclarar quién suministra cada lado de la interfaz y quién coordina las pruebas integradas.
La arquitectura debe evitar tratar una interfaz como una simple línea entre dos bloques. La línea representa una relación que debe especificarse.
Matriz de interfaces
Cuando existen decenas o cientos de interfaces, una matriz complementa los diagramas. Las filas y columnas representan elementos y las intersecciones indican intercambios o dependencias.
Este formato ayuda a detectar interfaces no documentadas, elementos excesivamente acoplados y concentraciones de dependencias alrededor de componentes específicos.
Una matriz también permite priorizar la gestión de interfaces por criticidad, etapa de definición y riesgo de integración.
Interface Control Document
Las interfaces críticas pueden requerir Interface Control Documents (ICDs) o especificaciones equivalentes. Un ICD describe parámetros, protocolos, pinout, formatos, tiempos, responsabilidades, versiones y criterios de prueba.
El ICD debe estar vinculado a la arquitectura y a la configuración. Una interfaz aprobada no puede cambiar informalmente porque un proveedor actualizó firmware o sustituyó un equipo.
Los cambios de interfaz requieren análisis de impacto sistémico porque con frecuencia afectan a varios elementos downstream.
Asignación de funciones y requisitos
La arquitectura materializa decisiones de asignación: qué elemento será responsable de cada función y requisito. Esta asignación debe ser explícita.
Un requisito de tiempo de respuesta puede depender simultáneamente de un sensor, la red, la plataforma de procesamiento, la base de datos y la interfaz de usuario. La arquitectura distribuye la responsabilidad de desempeño entre esos elementos.
Gestión de Requisitos en Ingeniería proporciona la trazabilidad necesaria para demostrar esta asignación y evitar requisitos sin owner.
Los atributos de calidad moldean la arquitectura
Muchas decisiones arquitecturales no nacen de funciones, sino de atributos de calidad: disponibilidad, confiabilidad, desempeño, seguridad, escalabilidad, mantenibilidad, interoperabilidad y resiliencia.
Dos sistemas pueden cumplir las mismas funciones y, aun así, tener arquitecturas completamente diferentes debido a estos atributos.
Por ello, los requisitos no funcionales deben cuantificarse cuando sea posible. “Alta disponibilidad” es una expresión vaga; disponibilidad objetivo, recuperación, tolerancia a fallas y modos degradados orientan decisiones reales.
Redundancia y eliminación de single points of failure
La redundancia no consiste simplemente en duplicar equipos. Deben evaluarse las dependencias comunes.
Dos servidores pueden ser redundantes y compartir el mismo switch, PDU, base de datos o enlace. La arquitectura debe identificar common-cause failures que eliminan el beneficio esperado.
Un análisis del service path ayuda a mapear todos los elementos necesarios para una función crítica y verificar si permanecen puntos únicos de falla.
Segregación e independencia
Los sistemas críticos suelen exigir segregación entre redes, fuentes de alimentación, dominios, zonas o funciones. La arquitectura debe mostrar dónde se requiere independencia y cómo se preservará.
La segregación física y lógica producen efectos diferentes. Las VLANs pueden separar tráfico lógicamente, mientras que requisitos de seguridad o disponibilidad pueden exigir equipos y rutas físicas independientes.
La decisión debe derivarse del riesgo y de los requisitos, no de la preferencia del proveedor.
Acoplamiento y cohesión
Las arquitecturas robustas buscan limitar dependencias innecesarias entre elementos. Un alto acoplamiento aumenta el impacto de cambios y el riesgo de propagación de fallas.
Al mismo tiempo, separar excesivamente las funciones puede aumentar la complejidad de las interfaces. La arquitectura debe encontrar un equilibrio entre modularidad y simplicidad.
Este trade-off aparece en software, redes, automatización y sistemas físicos. No existe una regla universal; la decisión depende del desempeño, mantenimiento, expansión y criticidad.
Modularidad y sustitución
La modularidad permite evolucionar partes del sistema con impacto controlado. Para ello, las interfaces deben ser estables y las responsabilidades estar claramente definidas.
En contratación, la modularidad puede reducir dependencia de proveedores y facilitar sustituciones futuras. Sin embargo, soluciones excesivamente genéricas pueden perder desempeño o aumentar costos.
La arquitectura debe registrar por qué se eligió un determinado nivel de modularidad y qué interfaces se consideran estables.
Arquitectura e interoperabilidad
La interoperabilidad exige más que compatibilidad física. Los sistemas deben compartir protocolos, formatos, semántica, sincronización, autenticación y comportamiento esperado.
Los protocolos abiertos ayudan, pero no garantizan integración. Dos equipos pueden soportar el mismo estándar e implementar perfiles o extensiones diferentes.
La arquitectura debe definir requisitos de interoperabilidad y planificar la verificación en condiciones representativas.
Arquitectura de datos
En sistemas digitales, los datos son elementos arquitecturales. Deben definirse origen, ownership, formato, retención, sincronización, calidad, acceso, integridad y ciclo de vida.
Múltiples sistemas pueden almacenar versiones del mismo dato. Sin arquitectura de datos, surgen divergencias de registro, identificación y estado.
El concepto de source of truth debe definirse por dominio: qué sistema es autoritativo para usuarios, activos, eventos, configuraciones o resultados.
Arquitectura de seguridad
La seguridad debe integrarse desde la arquitectura. Zonas de confianza, superficies de ataque, identidades, privilegios, flujos y dependencias externas deben considerarse antes de la implantación.
Añadir un firewall o autenticación al final no corrige una arquitectura que, por diseño, depende de relaciones inseguras.
En sistemas convergentes, ciberseguridad y seguridad física pueden compartir infraestructura y deben analizarse de forma coordinada.
Arquitectura y desempeño
El desempeño depende del recorrido completo: adquisición, comunicación, procesamiento, almacenamiento y presentación. Optimizar un componente aislado no resuelve cuellos de botella sistémicos.
La arquitectura debe identificar budgets y restricciones. La latencia total puede distribuirse entre etapas; la capacidad puede reservarse por subsistema; y el crecimiento esperado debe considerarse en el dimensionamiento.
Los modelos paramétricos y la simulación pueden apoyar este análisis antes de comprar equipos.
Trade studies y decisiones arquitecturales
La arquitectura implica elegir entre alternativas. ¿Centralizado o distribuido? ¿Redundancia activa o standby? ¿Cloud, edge u on-premises? ¿Un único backbone o redes segregadas?
Estas decisiones deben documentarse con criterios, premisas y consecuencias. Una Matriz de Decisión en Proyectos de Ingeniería y métodos multicriterio pueden apoyar comparaciones cuando existen criterios en conflicto.
El resultado del análisis debe incorporarse al registro de decisiones de arquitectura para preservar el rationale ante cambios futuros.
Architecture Decision Record
Los Architecture Decision Records (ADRs), o registros equivalentes, documentan contexto, decisión, alternativas consideradas y consecuencias.
Son útiles porque muchas elecciones parecen obvias durante el diseño y pierden contexto meses después. Cuando alguien propone sustituir una tecnología, el ADR muestra qué restricciones motivaron la solución vigente.
En contratos de ingeniería, este historial también ayuda a justificar cambios y evita revisar repetidamente decisiones ya fundamentadas.
Baseline de arquitectura
En determinados gates del proyecto, la arquitectura debe congelarse como baseline para permitir un desarrollo detallado coherente. Esto no impide cambios; establece una referencia controlada.
La baseline debe asociarse a las versiones aplicables de requisitos, interfaces y decisiones. Los cambios posteriores deben pasar por análisis de impacto.
Sin baseline, cada disciplina puede detallar una configuración diferente y descubrir la divergencia únicamente durante integración.
Arquitectura y Design Review
Design Review debe evaluar coherencia arquitectural, no limitarse a verificar la conclusión documental.
La revisión debe preguntar si los requisitos fueron asignados, si las interfaces están definidas, si los atributos críticos fueron tratados, si existen single points of failure, si los cambios fueron incorporados y si la arquitectura permite verificar el sistema.
Una revisión eficaz combina views técnicas con trazabilidad y registros de decisión.
Arquitectura preliminar y madurez progresiva
La arquitectura no necesita nacer completamente detallada. En fases iniciales, el objetivo es estructurar funciones, fronteras y alternativas. A medida que los requisitos maduran, los elementos físicos y las interfaces ganan definición.
Esta madurez progresiva evita un detalle prematuro. Elegir un modelo de equipo antes de comprender la arquitectura puede restringir alternativas innecesariamente.
El nivel de detalle debe ser compatible con el gate de decisión del proyecto.
Arquitectura en proyectos multidisciplinares
En infraestructura tecnológica, la arquitectura puede conectar sistemas eléctricos, telecomunicaciones, automatización, seguridad electrónica, software, obra civil y operación.
Un data center para seguridad electrónica, por ejemplo, involucra energía, climatización, racks, servidores, storage, red, VMS, autenticación, backup y procedimientos. Cada disciplina posee su propio diseño, pero el sistema debe funcionar como un conjunto.
La arquitectura sistémica ayuda a mantener esta visión transversal por encima de las disciplinas individuales.
Arquitectura y contratación por Work Packages
Cuando un proyecto se divide en Work Packages, cada paquete debe recibir requisitos e interfaces derivados de la arquitectura.
El Scope of Work debe traducir responsabilidades arquitecturales en obligaciones contractuales: quién suministra, quién integra, quién prueba y quién entrega evidencias.
Si la arquitectura no está clara antes de contratar, las brechas se transfieren al contrato y aparecen después como cambios o disputas durante la implantación.
En contratos fragmentados, ningún proveedor individual preserva naturalmente la visión completa del sistema. Mantener una arquitectura de referencia del Owner permite revisar cambios, proteger atributos críticos y coordinar la integración entre paquetes.
Arquitectura y Owner’s Engineering
En proyectos con varios proveedores, ningún contratista individual posee de forma natural la responsabilidad por la visión completa del Owner. Cada uno controla su solución y sus interfaces contractuales.
Owner’s Engineering puede mantener la arquitectura de referencia, coordinar requisitos, revisar cambios y proteger atributos sistémicos durante procurement y ejecución.
Esta función es especialmente importante cuando la integración entre contratos determina el desempeño final.
Arquitectura en MBSE
En MBSE, la arquitectura deja de ser un conjunto de dibujos independientes y pasa a representarse mediante elementos y relaciones estructuradas.
Las views pueden generarse para diferentes concerns sin duplicar información. Los requisitos se vinculan a elementos; las interfaces son objetos; las decisiones y verificaciones pueden rastrearse.
Esto aumenta la capacidad de análisis de impacto y reduce divergencias entre representaciones.
Arquitectura y V-Model
El V-Model relaciona la descomposición del sistema con la integración y verificación en niveles correspondientes. La arquitectura es la estructura que permite definir esos niveles.
Los requisitos de sistema se descomponen y asignan a subsistemas y componentes. En la subida del V, los elementos se integran y verifican contra las especificaciones correspondientes.
Sin una arquitectura clara, el equipo no sabe qué integraciones deben ocurrir ni en qué nivel debe demostrarse cada requisito.
Cómo documentar una arquitectura de sistemas
Una descripción de arquitectura debe ser adecuada a los stakeholders y concerns. Dependiendo del proyecto, puede incluir contexto, requisitos arquitecturalmente significativos, views funcionales, lógicas y físicas, interfaces, datos, seguridad, decisiones, riesgos, trade studies y criterios de verificación.
El conjunto debe evitar duplicidades. Cada información debe tener una fuente autoritativa y relaciones claras con los demás artefactos.
El nivel de formalidad debe acompañar la complejidad, criticidad y requisitos contractuales.
Errores frecuentes
Un error es llamar “arquitectura” a una topología de equipos sin explicar funciones, dependencias y decisiones. Otro es crear diagramas diferentes para cada reunión y permitir que se vuelvan incoherentes.
También son frecuentes las interfaces sin owner, requisitos no asignados, redundancia aparente con dependencias comunes, selección prematura de productos y ausencia de rationale de las decisiones.
Una arquitectura débil no elimina la complejidad; simplemente la oculta hasta fases más costosas.
Indicadores de madurez arquitectural
La madurez puede evaluarse mediante cobertura de requisitos asignados, definición de interfaces, decisiones registradas, resolución de riesgos arquitecturales, consistencia entre views y capacidad de verificar atributos críticos.
Una arquitectura madura no significa una arquitectura inmutable. Significa que los cambios están controlados y su impacto puede comprenderse.
La calidad de la documentación también importa: otro equipo debería poder comprender la organización del sistema y reproducir el razonamiento principal sin depender exclusivamente de las personas que participaron en la concepción.
Consideraciones finales
System Architecture organiza el sistema antes de que el desarrollo detallado fragmente la solución. Traduce requisitos en funciones, elementos, relaciones e interfaces, preserva atributos de calidad y establece una base para integración, verificación y evolución.
Su mayor valor aparece en proyectos en los que múltiples subsistemas deben funcionar como un conjunto. En estas situaciones, una arquitectura explícita reduce brechas entre disciplinas, mejora decisiones técnicas y permite evaluar el impacto de los cambios antes de que lleguen a implantación.
Una buena arquitectura no es el diagrama más sofisticado. Es aquella que hace que decisiones, dependencias y responsabilidades sean comprensibles y verificables para los stakeholders que deben diseñar, contratar, integrar, operar y mantener el sistema.
Referencias técnicas
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; IEC; IEEE. ISO/IEC/IEEE 42010:2022 — Software, systems and enterprise — Architecture description. Geneva: ISO, 2022. Disponible en: https://www.iso.org/standard/74393.html
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; IEC; IEEE. ISO/IEC/IEEE 15288:2023 — Systems and software engineering — System life cycle processes. Geneva: ISO, 2023. Disponible en: https://www.iso.org/standard/81702.html
[3] NASA. NASA Systems Engineering Handbook. NASA/SP-2016-6105 Rev2. Washington, DC: NASA, 2016. Disponible en: https://www.nasa.gov/reference/systems-engineering-handbook/
[4] NASA. NASA-HDBK-1009A — NASA Systems Modeling Handbook for Systems Engineering. Washington, DC: NASA, 2025. Disponible en: https://standards.nasa.gov/standard/NASA/NASA-HDBK-1009
Preguntas frecuentes
¿Qué es System Architecture?
Es la organización de funciones, elementos, relaciones, interfaces, restricciones y decisiones fundamentales que estructuran un sistema y orientan su desarrollo e integración.
¿La arquitectura de sistemas es solamente un diagrama de bloques?
No. Los diagramas son views. La arquitectura incluye decisiones, relaciones, asignación de requisitos, interfaces, atributos de calidad y principios que deben permanecer coherentes entre diferentes representaciones.
¿Cuál es la diferencia entre arquitectura funcional, lógica y física?
La arquitectura funcional describe lo que hace el sistema; la lógica organiza responsabilidades y servicios abstractos; la física define equipos, software, redes y otros elementos concretos que implementan la solución.
¿Por qué las interfaces son tan importantes en arquitectura?
Porque muchos problemas de sistemas complejos aparecen en las fronteras entre subsistemas. Las interfaces deben especificar intercambios, responsabilidades, requisitos y criterios de verificación.
¿Cómo se relaciona ISO 42010 con la arquitectura de sistemas?
ISO/IEC/IEEE 42010:2022 establece requisitos para descripciones de arquitectura y conceptos como stakeholders, concerns, viewpoints, views y model kinds.
¿Cuál es la relación entre System Architecture y MBSE?
MBSE representa la arquitectura mediante elementos y relaciones estructuradas, mantiene trazabilidad con requisitos, interfaces y verificaciones y permite generar diferentes views a partir del mismo modelo.
Materiales técnicos complementarios
Contenidos principales sobre el tema
- Systems Engineering: requisitos, arquitectura, interfaces, integración y validación
- MBSE — Model-Based Systems Engineering aplicado a sistemas complejos
- Gestión de Requisitos en Ingeniería
Contenidos técnicos relacionados
Soluciones relacionadas
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
- Gestión de Contratos, Alcance y Entregables
