¿Qué es la arquitectura SAP?
La arquitectura SAP define la estructura técnica y organizativa de los sistemas SAP en una empresa. Incluye desde la disposición física de servidores hasta la organización lógica de mandantes, pasando por las capas de software, las estrategias de alta disponibilidad y los modelos de integración entre sistemas.
Comprender la arquitectura SAP es fundamental para cualquier profesional técnico que trabaje con estos sistemas, ya que determina cómo se despliegan, operan, mantienen y escalan las soluciones SAP en entornos productivos.
Capas del sistema SAP
Los sistemas SAP se estructuran en tres capas principales que permiten separar responsabilidades y escalar componentes de forma independiente:
La capa de presentación es la interfaz con la que interactúan los usuarios finales. Incluye SAP GUI, navegadores web para aplicaciones Fiori, y otras interfaces de usuario. Esta capa no contiene lógica de negocio, solo presenta información y captura entradas del usuario.
La capa de aplicación es el núcleo del sistema SAP. Aquí residen los servidores de aplicación (application servers) que ejecutan la lógica de negocio ABAP, procesan transacciones, gestionan la memoria y coordinan el acceso a datos. En instalaciones de alta disponibilidad suele haber múltiples servidores de aplicación para distribuir carga.
La capa de base de datos almacena todos los datos del sistema SAP. Puede ser SAP HANA, Oracle, SQL Server, DB2 u otras bases de datos soportadas. Esta capa es crítica para el rendimiento y la disponibilidad del sistema completo.
Landscape SAP típico
Un landscape SAP empresarial se organiza habitualmente en tres entornos separados, cada uno con un propósito específico:
El entorno de Desarrollo (DEV) es donde los consultores funcionales y técnicos crean y prueban nuevas funcionalidades, desarrollos ABAP y configuraciones. Es el único entorno donde se permite la modificación directa del sistema.
El entorno de Calidad o Testing (QAS) replica las condiciones de producción y se utiliza para validar desarrollos, probar integraciones y realizar pruebas de usuario antes de pasar cambios a producción. Debe ser lo más similar posible al entorno productivo.
El entorno de Producción (PRD) es el sistema real que utilizan los usuarios finales para operar el negocio. Todos los cambios deben pasar obligatoriamente por DEV y QAS antes de llegar aquí. La estabilidad y disponibilidad de este entorno son críticas.
Sistemas y mandantes
SAP utiliza el concepto de mandante (client) para separar lógicamente datos dentro de un mismo sistema técnico. Cada mandante es una unidad organizativa independiente con sus propios datos maestros, transacciones y usuarios, aunque comparten la misma base de código ABAP.
En un landscape típico, cada sistema (DEV, QAS, PRD) contiene varios mandantes. Por ejemplo, en desarrollo puede haber un mandante para desarrollos en curso y otro para pruebas unitarias. En producción, diferentes mandantes pueden representar distintas empresas del grupo o divisiones de negocio.
Alta disponibilidad
En entornos productivos críticos, la arquitectura SAP debe garantizar disponibilidad continua del sistema. Esto se logra mediante varias estrategias técnicas:
Múltiples servidores de aplicación distribuyen la carga de trabajo y proporcionan redundancia. Si un servidor falla, los demás continúan atendiendo usuarios. El enqueue server, que gestiona los bloqueos de registros, puede configurarse en modo replicado para evitar puntos únicos de fallo.
En la capa de base de datos se implementan soluciones de clustering y replicación. SAP HANA System Replication permite mantener copias sincronizadas de la base de datos en diferentes nodos. Para bases de datos tradicionales se utilizan tecnologías específicas como Oracle RAC o SQL Server Always On.
La infraestructura de red, almacenamiento y virtualización también debe diseñarse sin puntos únicos de fallo, utilizando componentes redundantes y balanceadores de carga.
Escalabilidad y dimensionamiento
El dimensionamiento correcto de un sistema SAP es crítico para su rendimiento. Debe calcularse en función del número de usuarios, volumen de transacciones, tamaño de la base de datos y requisitos de procesamiento batch.
SAP proporciona herramientas de dimensionamiento (Quick Sizer) que ayudan a estimar los recursos necesarios. Sin embargo, el dimensionamiento real debe ajustarse basándose en mediciones de carga real y patrones de uso específicos de cada empresa.
La escalabilidad vertical (añadir más CPU y memoria a servidores existentes) tiene límites técnicos. La escalabilidad horizontal (añadir más servidores de aplicación) permite crecer de forma prácticamente ilimitada, aunque requiere balancear correctamente la carga entre servidores.
Arquitectura on-premise vs cloud
Tradicionalmente SAP se desplegaba on-premise, con servidores físicos o virtualizados en los centros de datos de la empresa. Este modelo ofrece control total pero requiere inversión en hardware, instalaciones y personal especializado.
El modelo cloud ha ganado relevancia con SAP S/4HANA Cloud. Puede ser cloud privado (infraestructura dedicada en proveedores como AWS, Azure, Google Cloud), cloud público (instancias compartidas gestionadas por SAP) o modelos híbridos.
La elección entre on-premise y cloud depende de factores como requisitos de integración con sistemas legados, políticas de seguridad y cumplimiento normativo, capacidades internas del equipo técnico y estrategia corporativa de IT.
Temas relacionados
- Arquitectura SAP: conceptos básicos
- Arquitectura SAP ECC
- Arquitectura SAP S/4HANA
- Capas del sistema SAP (presentación, aplicación, BD)
- Landscape SAP (DEV / QAS / PRD)
- Sistemas y mandantes
- Alta disponibilidad en SAP
- Escalabilidad y dimensionamiento
- Arquitectura on-premise vs cloud
- Integración entre sistemas SAP