SAP ha evolucionado durante décadas desde sistemas empresariales ejecutados en grandes computadoras centrales hasta modernas plataformas ERP basadas en bases de datos en memoria, servicios web, APIs y cloud computing.
Sin embargo, para comprender realmente esta evolución no basta con memorizar nombres como R/2, R/3, ECC o S/4HANA.
Lo verdaderamente interesante está en su arquitectura.
Cada generación de SAP modificó la manera en que se distribuyen tres componentes fundamentales:
Presentación → Lógica de negocio → Datos
En este artículo analizaremos las principales generaciones de SAP, su arquitectura y las ventajas y desventajas que introdujo cada una.
1. SAP R/1
SAP R/1 pertenece a las primeras generaciones de las soluciones empresariales de SAP.
Su característica fundamental era una arquitectura altamente centralizada.
Arquitectura conceptual
┌─────────────────────────────┐
│ MAINFRAME │
│ │
│ Presentación │
│ Lógica de negocio │
│ Datos │
│ │
└─────────────────────────────┘En términos simplificados, los diferentes componentes estaban fuertemente concentrados dentro de una misma plataforma.
Ventajas
- Arquitectura relativamente sencilla.
- Administración centralizada.
- Adecuada para la tecnología disponible en aquella época.
- Procesamiento centralizado de información empresarial.
Desventajas
- Escalabilidad limitada.
- Gran dependencia del sistema central.
- Costos elevados de infraestructura.
- Poca flexibilidad para distribuir procesamiento.
- Arquitectura muy diferente de los sistemas distribuidos actuales.
SAP necesitaba una arquitectura capaz de manejar organizaciones cada vez más grandes.
Así comenzó la siguiente etapa.
2. SAP R/2
SAP R/2 estuvo estrechamente asociado con ambientes mainframe y fue ampliamente utilizado por grandes organizaciones.
Su arquitectura continuaba siendo fuertemente centralizada comparada con las generaciones posteriores.
Arquitectura simplificada
┌──────────────────────────────┐
│ MAINFRAME │
│ │
│ Aplicaciones SAP │
│ │
│ Procesamiento empresarial │
│ │
│ Base de datos │
└──────────────────────────────┘
│
│
┌──────┴──────┐
│ Terminales │
└─────────────┘El procesamiento principal permanecía en grandes sistemas centrales.
Ventajas
- Gran estabilidad.
- Adecuado para grandes organizaciones.
- Procesamiento centralizado.
- Buen control sobre los recursos.
- Capacidad para manejar importantes volúmenes de operaciones empresariales para su época.
Desventajas
- Infraestructura costosa.
- Dependencia del mainframe.
- Menor flexibilidad.
- Escalabilidad costosa.
- Administración especializada.
- Difícil adaptación al nuevo mundo de servidores distribuidos.
El crecimiento de UNIX, las bases de datos relacionales, las redes empresariales y las computadoras personales preparó el terreno para un cambio radical.
3. SAP R/3: el gran cambio arquitectónico
Con SAP R/3 aparece uno de los cambios más importantes de la historia tecnológica de SAP:
La arquitectura de tres capas
USUARIOS
│
▼
┌─────────────────────────────┐
│ PRESENTATION LAYER │
│ │
│ SAP GUI │
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ APPLICATION LAYER │
│ │
│ SAP Application Server │
│ │
│ Dialog Work Processes │
│ Background Processes │
│ Update Processes │
│ Spool Processes │
│ Enqueue │
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ DATABASE LAYER │
│ │
│ Oracle / DB2 / SQL Server │
│ etc. │
└─────────────────────────────┘
SAP documenta R/3 como una arquitectura cliente/servidor de tres capas donde los datos se almacenan en la base de datos, el procesamiento ocurre en la capa de aplicación y SAP GUI proporciona la interfaz de presentación. (userapps.support.sap.com)
¿Por qué R/3 fue tan importante?
Porque permitió separar responsabilidades.
Presentation Layer
Es la capa utilizada por los usuarios.
El ejemplo clásico es:
SAP GUI
La computadora del usuario no necesita ejecutar toda la lógica empresarial.
Application Layer
Aquí se ejecuta gran parte de la lógica de negocio.
Los SAP Application Servers contienen componentes como los diferentes Work Processes.
Por ejemplo:
DIA → Dialog
BTC → Background
UPD → Update
SPO → SpoolEsta capa puede distribuirse entre diferentes servidores.
Database Layer
Contiene los datos empresariales.
Una característica importante de las generaciones anteriores a S/4HANA fue la posibilidad de trabajar con diferentes sistemas de bases de datos compatibles.
Ventajas de SAP R/3
- Arquitectura distribuida.
- Excelente escalabilidad para su época.
- Separación entre presentación, aplicación y datos.
- Posibilidad de agregar application servers.
- Mayor disponibilidad.
- Mejor distribución de carga.
- Independencia relativa del hardware.
- Soporte para diferentes plataformas y bases de datos.
Desventajas
- Arquitectura considerablemente más compleja.
- Más componentes que administrar.
- Dependencia de la red.
- Necesidad de administradores especializados.
- Mayor complejidad de troubleshooting.
- Escalar implica administrar más infraestructura.
Para un administrador SAP Basis, esta arquitectura es fundamental porque explica muchas de las herramientas tradicionales de administración.
4. SAP ERP / ECC
Con el tiempo SAP R/3 evolucionó hasta convertirse en lo que muchos administradores conocemos como:
SAP ERP Central Component (ECC)
Especialmente conocida es la generación:
SAP ECC 6.0
Aunque funcionalmente representó una enorme evolución del ERP, arquitectónicamente continúa teniendo muchos conceptos fundamentales de la arquitectura distribuida SAP.
Arquitectura simplificada de SAP ECC
USUARIOS
│
┌───────┴────────┐
│ │
SAP GUI Navegador
│ │
└───────┬────────┘
▼
┌───────────────────┐
│ SAP NetWeaver │
│ │
│ AS ABAP / Java │
│ │
│ Application │
│ Servers │
└─────────┬─────────┘
│
▼
┌───────────────────┐
│ DATABASE │
│ │
│ Oracle │
│ DB2 │
│ SQL Server │
│ SAP HANA* │
│ etc. │
└───────────────────┘
SAP NetWeaver proporcionó una plataforma tecnológica mucho más amplia alrededor de las aplicaciones empresariales.
Ventajas de SAP ECC
1. Plataforma extremadamente madura
ECC fue utilizado durante años por algunas de las organizaciones más grandes del mundo.
2. Amplia funcionalidad empresarial
Incluye áreas como:
- FI – Financial Accounting
- CO – Controlling
- MM – Materials Management
- SD – Sales and Distribution
- PP – Production Planning
- PM – Plant Maintenance
- HCM – Human Capital Management
3. Gran capacidad de personalización
Las organizaciones pueden desarrollar:
- Programas ABAP.
- Z Transactions.
- User Exits.
- BAdIs.
- Interfaces.
- RFCs.
4. Arquitectura ampliamente conocida
Existe una enorme cantidad de conocimiento técnico acumulado alrededor de ECC.
Desventajas de SAP ECC
La flexibilidad también creó problemas.
Después de muchos años, una instalación ECC puede contener:
SAP Standard
+
Custom ABAP
+
Z Transactions
+
Interfaces
+
RFC
+
Batch Jobs
+
Middleware
+
Custom TablesEl resultado puede ser un sistema extremadamente complejo.
Esto provoca:
- Upgrades complicados.
- Dependencias difíciles de identificar.
- Grandes esfuerzos de mantenimiento.
- Customizaciones obsoletas.
- Integraciones difíciles de modificar.
Y especialmente:
grandes volúmenes de datos y modelos de datos complejos.
SAP necesitaba simplificar nuevamente la arquitectura.
5. SAP HANA cambia las reglas
Antes de hablar de S/4HANA debemos entender SAP HANA.
HANA no es simplemente “otra base de datos”.
SAP HANA es una plataforma de datos cuyo componente central es una base de datos relacional in-memory. (help.sap.com)
Su arquitectura permite realizar una mayor cantidad de procesamiento directamente cerca de los datos.
Arquitectura tradicional
Application Server
│
│ grandes cantidades
│ de datos
▼
Database
Arquitectura optimizada HANA
Application
│
▼
┌──────────────────────────┐
│ SAP HANA │
│ │
│ Datos en memoria │
│ Procesamiento paralelo │
│ SQL │
│ SQLScript │
│ Cálculos │
│ Analytics │
└──────────────────────────┘Aquí aparece un concepto fundamental:
Code Pushdown
En lugar de mover grandes cantidades de información desde la base de datos hacia el application server para procesarlas, determinadas operaciones pueden ejecutarse directamente en HANA.
SAP describe precisamente este concepto como mover lógica intensiva en datos desde la plataforma ABAP hacia SAP HANA. (help.sap.com)
6. SAP S/4HANA
S/4HANA representa la generación moderna del ERP de SAP.
Una diferencia arquitectónica fundamental es:
SAP HANA deja de ser una opción y se convierte en la plataforma de base de datos sobre la que está optimizado el sistema.
SAP ABAP Platform es la base tecnológica de S/4HANA y está específicamente optimizada para aprovechar SAP HANA. (help.sap.com)
Arquitectura conceptual
USUARIOS
│
┌─────────┴─────────┐
│ │
SAP Fiori SAP GUI
│ │
└─────────┬─────────┘
▼
┌───────────────────┐
│ SAP Gateway │
│ OData / APIs │
└─────────┬─────────┘
▼
┌───────────────────┐
│ ABAP Platform │
│ │
│ Business Logic │
│ CDS │
│ ABAP │
│ Application │
│ Services │
└─────────┬─────────┘
│
CODE PUSHDOWN
│
▼
┌─────────────────────────┐
│ SAP HANA │
│ │
│ In-Memory Database │
│ Column Store │
│ SQL / SQLScript │
│ Parallel Processing │
│ Analytics │
└─────────────────────────┘
¿Qué cambia realmente con S/4HANA?
Uno de los cambios fundamentales es que la base de datos deja de ser simplemente un lugar donde almacenar información.
Se convierte en una parte activa del procesamiento.
Tecnologías como:
CDS Views
permiten crear modelos de datos optimizados para HANA.
SAP explica que los objetos CDS definidos en AS ABAP pueden convertirse en sentencias HANA SQL mediante la interfaz de base de datos. (help.sap.com)
Ventajas de SAP S/4HANA
1. Alto rendimiento
El procesamiento in-memory permite ejecutar determinadas operaciones sobre grandes cantidades de información con gran rapidez.
2. Modelo de datos simplificado
S/4HANA busca eliminar muchas redundancias históricas y simplificar estructuras de datos.
3. Analytics en tiempo real
Las capacidades analíticas pueden trabajar directamente sobre información operacional.
4. SAP Fiori
La experiencia de usuario moderna se apoya fuertemente en:
Browser
│
SAP Fiori
│
SAPUI5
│
OData
│
ABAP
│
CDS
│
SAP HANASAP describe su modelo de aplicaciones Fiori optimizadas para HANA utilizando CDS, OData, servicios ABAP y SAPUI5. (help.sap.com)
5. Arquitectura preparada para integraciones modernas
APIs, OData y servicios permiten construir arquitecturas mucho más orientadas a integración.
Desventajas de SAP S/4HANA
No todo son ventajas.
1. SAP HANA es obligatorio
Ya no existe la misma libertad histórica para seleccionar entre diferentes motores de bases de datos.
2. Migraciones complejas
Una migración desde ECC puede requerir revisar:
- Custom ABAP.
- Interfaces.
- Add-ons.
- Business Functions.
- Datos históricos.
- Procesos empresariales.
- Integraciones.
- Código obsoleto.
3. Nuevos conocimientos técnicos
Los equipos tradicionales de SAP necesitan aprender tecnologías como:
- SAP HANA.
- CDS.
- Fiori.
- OData.
- SAPUI5.
- APIs.
- RAP.
- ABAP Cloud.
4. Cambio de paradigma
No siempre es suficiente migrar el código antiguo.
En algunos casos es necesario rediseñar la aplicación para aprovechar realmente HANA.
7. SAP S/4HANA Cloud
La siguiente evolución consiste en mover parte de la responsabilidad de infraestructura hacia servicios cloud.
Aquí debemos distinguir principalmente entre diferentes modelos de implementación, entre ellos:
SAP S/4HANA Cloud Public Edition
y
SAP S/4HANA Cloud Private Edition.
Una arquitectura empresarial moderna puede verse conceptualmente así:
USUARIOS
│
▼
SAP Fiori
│
▼
┌─────────────────┐
│ S/4HANA │
│ │
│ ABAP Platform │
│ Business Logic │
└────────┬────────┘
│
▼
SAP HANA
│
│
APIs / Events / Services
│
▼
┌─────────────────┐
│ SAP BTP │
│ │
│ Integration │
│ Extensions │
│ Applications │
│ Services │
└────────┬────────┘
│
┌─────────┼──────────┐
▼ ▼ ▼
SaaS Cloud Legacy
Systems Apps Systems
SAP documenta que ABAP Platform conecta los componentes de S/4HANA con SAP HANA dentro de la arquitectura de S/4HANA Cloud Private Edition. (help.sap.com)
Ventajas del modelo Cloud
- Menor responsabilidad sobre infraestructura física.
- Mayor orientación hacia servicios.
- Integración con plataformas cloud.
- Actualizaciones más frecuentes.
- Mayor estandarización.
- Arquitecturas modernas mediante APIs.
- Escalabilidad.
- Integración con SAP BTP.
Desventajas
- Menor control de determinadas capas de infraestructura.
- Restricciones mayores para ciertas customizaciones.
- Necesidad de adaptar procesos existentes.
- Dependencia de conectividad.
- Mayor necesidad de gobierno de integraciones y APIs.
- Cambio importante para equipos Basis tradicionales.
La evolución arquitectónica de SAP
Podemos resumir varias décadas de evolución de esta manera:
SAP R/1
│
│ Arquitectura centralizada
▼
SAP R/2
│
│ Mainframe
▼
SAP R/3
│
│ Cliente/Servidor
│ Arquitectura 3 capas
▼
SAP ERP / ECC
│
│ NetWeaver
│ ABAP
│ Arquitectura distribuida
▼
SAP HANA
│
│ In-Memory
│ Code Pushdown
▼
SAP S/4HANA
│
│ ABAP Platform
│ HANA
│ CDS
│ Fiori
│ OData
▼
SAP S/4HANA Cloud
│
│ APIs
│ Cloud
│ BTP
│ Extensiones
▼
Arquitectura SAP modernaComparación rápida
| Generación | Arquitectura predominante | Base de datos | Interfaz característica | Escalabilidad |
|---|---|---|---|---|
| R/1 | Centralizada | Centralizada | Terminal | Limitada |
| R/2 | Mainframe | Mainframe | Terminal | Vertical |
| R/3 | 3 capas | Varias opciones | SAP GUI | Alta |
| ECC | 3 capas / NetWeaver | Varias opciones | SAP GUI / Web | Alta |
| S/4HANA | ABAP + HANA | SAP HANA | Fiori / SAP GUI | Muy alta |
| S/4HANA Cloud | Cloud + servicios | SAP HANA | Fiori / Web | Cloud |
ECC vs S/4HANA: diferencia arquitectónica
Esta es probablemente la comparación más importante para un administrador SAP actual.
SAP ECC
SAP GUI
│
▼
Application Server
│
│ Procesamiento ABAP
│
▼
Database
Oracle / DB2 / SQL Server / HANA...La aplicación realiza una parte importante del procesamiento y la base de datos tradicionalmente funciona principalmente como sistema de persistencia y procesamiento SQL.
SAP S/4HANA
Fiori / SAP GUI
│
▼
ABAP Platform
│
CDS / ABAP / RAP
│
▼
CODE PUSHDOWN
│
▼
┌──────────────────┐
│ SAP HANA │
│ │
│ Data │
│ Calculations │
│ Analytics │
│ Processing │
└──────────────────┘
La idea fundamental es:
llevar el procesamiento hacia donde están los datos, en lugar de mover constantemente los datos hacia donde está el procesamiento.
¿Qué significa esta evolución para un administrador SAP Basis?
Aquí encontramos uno de los cambios profesionales más interesantes.
El administrador tradicional podía concentrarse principalmente en:
Operating System
│
Database
│
SAP Instance
│
Application Server
│
SAP GUIEl administrador SAP moderno necesita comprender un ecosistema mucho mayor:
Linux
│
SAP HANA
│
ABAP Platform
│
S/4HANA
│
Fiori
│
Web Dispatcher
│
OData / APIs
│
SAP BTP
│
Cloud Services
│
External SystemsPor esta razón, el rol de SAP Basis Administrator también está evolucionando hacia perfiles relacionados con SAP Technical Architecture, SAP HANA, Cloud, Integration y Platform Administration.
Conclusión
La historia de SAP también puede entenderse como la historia de la evolución de las arquitecturas empresariales.
Pasamos de:
sistemas centralizados
a:
arquitecturas cliente/servidor
posteriormente:
arquitecturas distribuidas de tres capas
y finalmente:
bases de datos in-memory, aplicaciones web, APIs, servicios y cloud computing.
Pero existe un principio que se mantiene.
SAP necesita procesar:
usuarios + aplicaciones + lógica empresarial + datos.
Lo que ha cambiado radicalmente es dónde se ejecuta cada componente y cómo se comunican entre ellos.
Para cualquier administrador SAP, comprender esta evolución es mucho más importante que simplemente conocer los nombres de las versiones.
Porque cuando entendemos la arquitectura podemos comprender mejor:
cómo funciona SAP, dónde puede fallar y dónde debemos comenzar a buscar cuando ocurre un problema.