\u00bfQu\u00e9 significan los nuevos planes de SAP para los usuarios que siempre han confiado en las bases de datos de SAP? \u00bfC\u00f3mo deben alinear su propia estrategia inform\u00e1tica con la de SAP?<\/p>\n
Cada vez son m\u00e1s las voces que quieren convencer a los usuarios de que MaxDB es un modelo descatalogado. Curiosamente, cuando se aconseja cambiar de DB, a menudo no se menciona Hana, sino que se recomienda ASE como el objetivo de migraci\u00f3n supuestamente obvio.<\/p>\n
Pero el hecho es: ASE no es una alternativa real a MaxDB, y MaxDB seguir\u00e1 siendo un DBMS fiable y utilizable durante a\u00f1os.<\/p>\n
Cuando se cre\u00f3 R\/3, a finales de los a\u00f1os 80, la estrategia de SAP en materia de bases de datos segu\u00eda siendo clara y sencilla. En aquel momento, SAP no era expl\u00edcitamente un fabricante de bases de datos, sino que, como proveedor de ERP, confiaba en los sistemas de gesti\u00f3n de bases de datos SQL ya establecidos.<\/p>\n
Al principio s\u00f3lo se trataba de Oracle e Informix, y m\u00e1s tarde tambi\u00e9n de IBM DB2 y Microsoft SQL Server.<\/p>\n
El hecho de que Oracle ya se hubiera introducido en el mercado con Financials a finales de los a\u00f1os 80, compitiendo as\u00ed con SAP en el \u00e1mbito de las aplicaciones, se descart\u00f3 en un principio como una \"coopetici\u00f3n\" habitual en el mercado.<\/p>\n
Sin embargo, con el paso de los a\u00f1os, SAP se convirti\u00f3 en el mayor distribuidor de valor a\u00f1adido de Oracle, y transfer\u00eda anualmente al competidor una cantidad millonaria considerable. Un dilema que llev\u00f3 a SAP a cambiar su estrategia de abstinencia de bases de datos.<\/p>\n
Con ADABAS D de Software AG, SAP introdujo otra base de datos en la empresa a principios de 1992. Tras la certificaci\u00f3n R\/3 en 1994, se posicion\u00f3 inicialmente como una alternativa de bajo coste a Oracle & Co.<\/p>\n
Despu\u00e9s de que SAP adquiriera los derechos del producto y gran parte del equipo de desarrollo de Software AG en 1997, SAP dej\u00f3 de ser un mero revendedor de sistemas de gesti\u00f3n de bases de datos de terceros.<\/p>\n
El primer DBMS propiedad de SAP se ofreci\u00f3 a partir de entonces con el nombre de SAP DB.<\/p>\n
El objetivo obvio de SAP era avivar la competencia en el entorno de las bases de datos y romper el dominio de Oracle sobre la base de clientes de SAP con su propio producto.<\/p>\n
Despu\u00e9s de que las cifras de ventas no repuntaran notablemente, SAP lanz\u00f3 la versi\u00f3n 7.3 de SAP DB bajo una licencia de c\u00f3digo abierto en 2000.<\/p>\n
En 2003 se inici\u00f3 una cooperaci\u00f3n comercial con MySQL AB. En el marco de la misma, el DBMS -a partir de la versi\u00f3n 7.5- se ofreci\u00f3 como \"MaxDB by MySQL\". Sin embargo, el soporte y el desarrollo continuaron en manos de SAP.<\/p>\n
Esta cooperaci\u00f3n lleg\u00f3 a su fin en 2007, y a partir de la versi\u00f3n 7.6 SAP MaxDB dej\u00f3 de ofrecerse como producto de c\u00f3digo abierto. Sin embargo, SAP decidi\u00f3 entonces ofrecer una alternativa para que MaxDB siguiera siendo utilizable fuera de las aplicaciones SAP: como \"Community Edition\" gratuita bajo una licencia comunitaria.<\/p>\n
MaxDB sigue estando disponible hoy en d\u00eda en forma de Community Edition gratuita, por lo que tambi\u00e9n puede utilizarse fuera del mundo SAP.<\/p>\n
Dado que SAP no quer\u00eda ser percibido como un fabricante de BD durante mucho tiempo, MaxDB existi\u00f3 en gran medida en la oscuridad. Sin embargo, esto apenas ha afectado a su \u00e9xito.<\/p>\n
A pesar de la falta de impulso por parte de los departamentos de marketing y ventas de SAP, la base de datos se ha extendido definitivamente. Especialmente en las PYME de habla alemana, MaxDB goza de una aceptaci\u00f3n ininterrumpida.<\/p>\n
Razones importantes para ello son el favorable coste total de propiedad (TCO) y un funcionamiento silencioso y fiable. Los clientes de SAP utilizan al menos 27.000 servidores MaxDB.<\/p>\n
Por cierto, esta cifra es varias veces superior a las instalaciones de SAP ASE en la base de clientes. MaxDB tambi\u00e9n se ha generalizado dentro de SAP, con m\u00e1s de 2.500 instalaciones. Seg\u00fan informaci\u00f3n privilegiada, alrededor de la mitad de los sistemas de producci\u00f3n internos de SAP se basan en este DBMS.<\/p>\n
SAP tambi\u00e9n desarroll\u00f3 nuevas tecnolog\u00edas sobre la base del n\u00facleo MaxDB. A finales de los a\u00f1os noventa, se desarroll\u00f3 SAP liveCache como una extensi\u00f3n basada en objetos del n\u00facleo MaxDB para la gesti\u00f3n en memoria de objetos complejos (es decir, \u00e1rboles y redes), dedicada a la soluci\u00f3n log\u00edstica SAP SCM\/APO.<\/p>\n
En la actualidad, todav\u00eda hay m\u00e1s de 5.000 instalaciones de SAP liveCache en el contexto de la gesti\u00f3n de la cadena de suministro y la planificaci\u00f3n y optimizaci\u00f3n avanzadas.<\/p>\n
MaxDB tambi\u00e9n sigue desempe\u00f1ando un papel especial en relaci\u00f3n con SAP Content Server: sin MaxDB, no hay externalizaci\u00f3n de contenidos sin formato a una base de datos.<\/p>\n
No se dispone de cifras oficiales sobre este escenario de despliegue, pero cabe suponer varios miles o incluso m\u00e1s de diez mil instalaciones. Puede que SAP MaxDB no lleve una existencia en el candelero, pero esto no ha perjudicado la popularidad de los usuarios.<\/p>\n
En los \u00faltimos a\u00f1os, la base instalada de SAP MaxDB incluso ha crecido significativamente: m\u00e1s del 50 por ciento solo desde principios de 2013. Una de las razones de ello se refleja tambi\u00e9n en el reciente estudio \"Relational OLTP-Midmarket DBMS\" realizado por los analistas de \"Research in Action\": MaxDB goza de un nivel de satisfacci\u00f3n del cliente constantemente alto.<\/p>\n
A finales de la primera d\u00e9cada de 2000, SAP emprendi\u00f3 una adquisici\u00f3n multimillonaria de relevancia estrat\u00e9gica: el 30 de julio de 2010 se hizo con el fabricante californiano de bases de datos Sybase.<\/p>\n
El objetivo declarado de SAP era \"llegar a miles de millones de usuarios\" a trav\u00e9s de ella.<\/p>\n
Aunque las soluciones de movilidad y el acceso a clientes m\u00f3viles fueron los principales motivos de la adquisici\u00f3n, SAP tambi\u00e9n incorpor\u00f3 a la empresa los productos de bases de datos originales de Sybase.<\/p>\n
Entre ellas se inclu\u00edan el DBMS OLTP Sybase Adaptive Server Enterprise (ASE) y la base de datos de almac\u00e9n de datos Sybase IQ, que presum\u00eda de un alto rendimiento OLAP gracias a su organizaci\u00f3n de almacenamiento orientada a columnas.<\/p>\n
Pero la adquisici\u00f3n de la tecnolog\u00eda DBMS fue m\u00e1s bien un \"by-catch\" y no un elemento constitutivo de la estrategia -a\u00fan no anunciada oficialmente en aquel momento- de querer estar a la vanguardia del mercado de bases de datos.<\/p>\n
A\u00fan no est\u00e1 claro qu\u00e9 pretend\u00eda hacer exactamente SAP con los productos DBMS adquiridos. En cualquier caso, nunca fue un objetivo declarado sustituir MaxDB por Sybase ASE.<\/p>\n
A mediados de la primera d\u00e9cada del nuevo milenio, Hasso Plattner ya hab\u00eda conseguido que se aprobara la realizaci\u00f3n de su visi\u00f3n de una base de datos en memoria de alto rendimiento y orientada a columnas.<\/p>\n
As\u00ed, SAP ya hab\u00eda comprado en secreto en 2005 el fabricante californiano de software Transact in Memory y, con \u00e9l, la base de datos OLTP en memoria P*TIME.<\/p>\n
En 2009, SAP se dispuso a crear una nueva base de datos SAP, como una mezcla tecnol\u00f3gica del DBMS de almacenamiento en filas P*Time, el motor de b\u00fasqueda basado en almacenamiento en columnas TREX desarrollado a\u00f1os antes y MaxDB como capa de persistencia.<\/p>\n
Inicialmente, esta nueva base de datos SAP se denominaba \u00fanicamente New Database o New DB. Cuando se entreg\u00f3 por primera vez en noviembre de 2010, se denomin\u00f3 temporalmente High Performance Analytical Appliance.<\/p>\n
M\u00e1s tarde s\u00f3lo se hizo referencia a ella por la forma abreviada de este nombre: SAP Hana 1.0.<\/p>\n
Desde la presentaci\u00f3n de Hana, a m\u00e1s tardar, ha quedado claro: SAP est\u00e1 tomando la ofensiva como fabricante de bases de datos y ha declarado la guerra a Oracle, el principal competidor en este campo.<\/p>\n
El objetivo declarado es liberar las aplicaciones SAP de los RDBMS tradicionales, ya sean propios o de la competencia. Por este motivo, SAP est\u00e1 invirtiendo principalmente en la moderna plataforma Hana y apenas en el desarrollo ulterior de sus bases de datos relacionales cl\u00e1sicas.<\/p>\n
La consecuencia de esta inequ\u00edvoca estrategia de Hana es clara: a largo plazo, no hay perspectiva para ninguna de las bases de datos SAP m\u00e1s antiguas, ni para MaxDB ni para los legados de Sybase ASE e IQ.<\/p>\n
El futuro de la base de datos de SAP es Hana. Quienes quieran seguir obteniendo sus aplicaciones empresariales de SAP no podr\u00e1n evitar Hana.<\/p>\n
Con el anuncio de S\/4 Hana, la suite empresarial de nueva generaci\u00f3n, SAP SE ha subrayado una vez m\u00e1s su pretensi\u00f3n de hacer valer la soberan\u00eda de las bases de datos en su territorio.<\/p>\n
Queda por saber qu\u00e9 presi\u00f3n est\u00e1 ejerciendo ahora la orientaci\u00f3n de SAP hacia Hana en las empresas que actualmente utilizan MaxDB. Por el momento, ninguna en particular.<\/p>\n
No fue hasta principios de 2015 cuando SAP prorrog\u00f3 el \"Mainstream Maintenance\" cinco a\u00f1os m\u00e1s, hasta finales de 2025, garantizando as\u00ed el mantenimiento durante al menos otros diez a\u00f1os.<\/p>\n
M\u00e1s a menudo, se afirma que se ha interrumpido el desarrollo de MaxDB.<\/p>\n
Esto es obviamente err\u00f3neo. Por ejemplo, Database Studio, la herramienta de gesti\u00f3n aut\u00f3noma de MaxDB, ha sido ampliada recientemente por SAP para incluir una herramienta de an\u00e1lisis gr\u00e1fico.<\/p>\n
Otra forma sencilla de aumentar el rendimiento de una instancia de MaxDB es utilizar discos de estado s\u00f3lido basados en memoria flash.<\/p>\n
El cambio de HDD a SSD no es, por supuesto, una evoluci\u00f3n del DBMS en sentido estricto, pero ahora es posible porque SAP ha certificado recientemente el hardware correspondiente.<\/p>\n
A menudo o\u00edmos que una migraci\u00f3n de MaxDB a ASE tiene sentido. Al fin y al cabo, cada \"Hana Runtime Edition for Applications and SAP BW (REAB)\" ya incluye una licencia para MaxDB y para ASE, por lo que la migraci\u00f3n ser\u00eda posible sin costes de licencia, al igual que el funcionamiento en paralelo de ambos DBMS.<\/p>\n
Sin embargo, a la vista de la clara orientaci\u00f3n de SAP hacia Hana, dicha migraci\u00f3n no es una medida de prolongaci\u00f3n de la vida \u00fatil: Es probable que el ciclo de vida de ASE termine al mismo tiempo que el de MaxDB.<\/p>\n
Los defensores de la ASE suelen citar la compresi\u00f3n de datos como principal argumento a favor de la migraci\u00f3n. Pero sigue siendo v\u00e1lido el adagio estadounidense: \"No hay almuerzo gratis\".<\/p>\n
El ahorro de espacio en disco tiene un alto precio, ya que ASE requiere mucha m\u00e1s potencia de c\u00e1lculo. La ventaja de compresi\u00f3n de ASE se paga en \u00faltima instancia con inversiones en potencia de CPU.<\/p>\n
Desde el punto de vista de un defensor de MaxDB, el concepto de copia de seguridad de ASE es una de sus mayores debilidades.<\/p>\n
ASE no puede vaciar el registro durante una copia de seguridad completa. Esto significa: si la copia de seguridad dura demasiado, los registros se desbordan y el sistema se paraliza.<\/p>\n
En cambio, la funci\u00f3n de copia de seguridad en l\u00ednea de MaxDB no conoce tales restricciones. La recomendaci\u00f3n de que las copias de seguridad de ASE se realicen en momentos de baja carga simplemente suena ingenua e ignora las realidades operativas.<\/p>\n
As\u00ed que resulta que ASE suele estar sobrevalorado, mientras que las capacidades de MaxDB siguen estando notoriamente infravaloradas.<\/p>\n
La migraci\u00f3n de MaxDB a ASE s\u00f3lo puede suponer una ganancia de funcionalidad en algunos casos excepcionales expuestos, por ejemplo, cuando la mayor compresi\u00f3n es un factor decisivo.<\/p>\n
Por otro lado, los costes de licencia y mantenimiento son m\u00e1s elevados (si la licencia no se adquiere a precio de coste como parte de una Hana Runtime Edition), el esfuerzo de formaci\u00f3n necesario y los riesgos considerables.<\/p>\n
Los usuarios que utilizan MaxDB no s\u00f3lo con ERP sino tambi\u00e9n en forma de liveCache o como parte de Content Server no podr\u00edan migrar completamente a ASE de todos modos.<\/p>\n
Mientras SAP no migre sus sistemas internos basados en MaxDB a Hana en un frente amplio, los usuarios de MaxDB pueden dormir tranquilos. Los que utilizan MaxDB hoy en d\u00eda deber\u00edan seguir con \u00e9l hasta que consideren que ha llegado el momento de pasarse a Hana.<\/p>\n
Sin embargo, una doble migraci\u00f3n ser\u00eda completamente absurda. Tomar los desv\u00edos v\u00eda ASE para el objetivo de Hana sigue sin tener sentido.<\/p>\n