junio 29, 2012

¿SAP HANA remplaza a BW? (Una ayuda: no.)

by Steve Lucas

Bueno, la verdad es que no me sorprende el debate en Twitter acerca de si SAP HANA podría remplazar a BW. Escribí este blog post en respuesta a unos 50 tweets que vi el viernes acerca de este tema. Quiero agradecer a Vijay Vijayasankar de IBM por sus contribuciones. Mi intención es cubrir en este post cuatro escenarios que, espero, les sirvan de guía. Esos escenarios son:



  1. Tengo SAP ECC y BW, ¿qué hago?
  2. Tengo SAP ECC y quizá necesito BW, ¿qué hago?
  3. Tengo SAP ECC, pero me dijeron que SAP BusinessObjects Rapid Marts es mejor, ¿qué hago?
  4. Tengo SAP ECC y me ofrecieron un data warehouse diseñado desde cero, ¿qué hago?
Lo más fácil para empezar a responder estas preguntas es definir, en primer lugar, qué es BW. La razón: es bastante obvio que no todos definen 'BW' de la misma forma. Algunos ni siquiera lo llaman BW, sino SAP BIW o BI. Para definir BW, voy a citar la fuente de toda verdad, Wikipedia: "SAP NetWeaver Business Warehouse (SAP NetWeaver BW) es el nombre de una solución de Business Intelligence, análisis, reportes y Data Warehousing producida por SAP AG. Originalmente se llamó SAP BIW (Business Information Warehouse), y después el producto pasó a ser abreviado como 'SAP BW'. Ahora se lo conoce como 'SAP BI' a nivel del usuario final. Por otro lado, 'BW' todavía se usa para describir sus componentes subyacentes, Data Warehouse Area y Accelerator. Este nombre todavía es usado por compañías que arman su negocio sobre sistemas operacionales SAP."


La entrada de Wikipedia dice también que "la solución BW de SAP tiene un data warehouse de uso muy extendido, así como un gran número de contenidos empresariales pre-definidos (piezas) en forma de InfoCubes, InfoObjects, roles de autorización y consultas. Esto permite aprovechar la experiencia de SAP y reducir los ciclos de implementación. El contenido empresarial se puede modificar para satisfacer los requerimientos de una organización; sin embargo, para eso hace falta un proceso más extenso de personalización de los elementos pre-definidos."

Por último, la entrada afirma que BW tiene varios componentes, que incluyen los siguientes, entre otros:

  • Una capa optimizada para Extracción, Transformación y Carga (ETL, por 'Extraction, Transformation and Load') para mover datos de un lado a otro.
  • Un área de Data Warehouse que almacena datos usando un diseño de esquema en estrella.
  • Un componente de reportes para consumir información del data warehouse.
  • Planeamiento y análisis para simular operaciones tales como cálculos de presupuesto.
No pretendo citar toda la Wikipedia, pero como quiero escribir un blog post sobre si HANA remplaza o no a BW, y es difícil encontrar dos personas en el planeta que definan BW de la misma manera, un poco de base no le viene mal a nadie.

Ahora que vimos la definición oficial de BW, ésta es mi definición: Es un sistema. Un sistema consiste en un warehouse, con un esquema pre-definido de negocio, que incluye contenido y herramientas relacionadas para mejorar el análisis de datos almacenados en SAP Business Suite. Así de simple. El sistema entero, o al menos una parte, ya se ha deployado para más de 13.000 clientes. Corre miles de apps de terceros certificadas por SAP, y tiene un desempeño confiable (nótese que no dije 'rápido'). Y BW es gratis. Pero NO es una base de datos. Funciona SOBRE una base de datos, y hay que tener en cuenta la distinción. Para albergar BW hoy hace falta gastar plata en una base de datos lenta, basada en disco, y seguramente pagar una solución de hardware para acelerarla, como por ejemplo Business Warehouse Accelerator (BWA).

Es más, durante los últimos quince años, por cada módulo de la Business Suite (en realidad no todos, pero casi), hemos estado agregando lógica que convierta los nombres de tablas de cuatro caracteres SAP ECC para que tengan sentido empresarial ('business meaning') a través del contenido de BW. Así que la cuestión a considerar al leer este post es: ¿debemos reconstruir contenido que SAP estuvo armando durante quince años para nosotros, sólo porque se lo percibe como 'difícil'?

En cuanto a mi definición de SAP HANA: es una base de datos (pero no se puede citar esto aislado del resto de mi explicación más abajo...).

Es verdad que HANA es un tipo especial de base de datos en memoria que tiene un desempeño asombroso cuando se lo une a sistemas COMO BW, pero en su nivel más básico, es una base de datos. HANA no remplaza a BW. Es un producto pensado para mejorar a BW. Hablando de velocidad, vale la pena mencionar que veo como uno de los mayores desafíos el bajo rendimiento de los reportes en BW; con HANA como base de datos de BW, los reportes (entre muchas otras cosas) funcionan con mucho mejor rendimiento. Si pueden usar SAP BusinessObjects (BOBJ) como frontend para BW, la mejora es aun mayor.

TODO mi argumento se reduce a lo siguiente: BW es MUCHO mejor sobre HANA, y si a esto se le suma que BW es gratis, hay un montón de contenido ya hecho para BW; ADEMÁS se obtienen soluciones certificadas instantáneamente sobre BW. ¿No alcanza esto como para al menos CONSIDERAR estos beneficios si todavía no tienen BW? Recuerden, NO hay ningún plan para dar de baja BW. Si alguien les dijo eso, está completamente equivocado. Soy un defensor de BW más HANA, no un partidario de BW vs. HANA.

Entiendo que hay otras opciones en lugar de BW. Algunos clientes tienen necesidades específicas y van a encontrar en BusinessObjects Rapid Mart una manera rápida de mover datos, usando Data Services, hacia un 'store' mucho más manejable que BW. Pero también van a tener que hacer (o personalizar, según el Rapid Mart) las extracciones, transformaciones, reportes, etc. que van a necesitar para ser productivos. Sé que SAP está armando nuevos contenidos nativos para HANA, tales como el Operational Reporting RDS. Así que uno podría preguntarse si SAP está 'cambiando de dirección' en cuanto a dónde se crea y dónde reside el contenido. (De nuevo, la respuesta es no, no hemos cambiado de dirección para nada.)

Entiendo que algunos van a decir 'diseñen su propio warehouse de cero', pero esto tiene los mismos problemas. Es el clásico 'hacer vs. comprar', y el escenario de BW con HANA o cualquier otra base de datos no es la excepción.

Voy a cubrir los cuatro escenarios que prometí, así que aquí están:

Escenario #1: Tengo SAP ECC y BW, ¿qué hago?

La respuesta corta: Toda compañía debería sin duda aprovechar HANA como base de datos para los deployments de BW que ya tengan.

Antes mencioné que la velocidad de reporte es un gran problema en BW sin HANA. Pero en realidad el problema estriba en el rendimiento de principio a fin: en la carga, los reportes, y la gestión de landscape y cambios. Gracias a la carga en paralelo podemos reducir drásticamente el tiempo de carga de datos a SAP HANA para BW. Esto es esencial para compañías que tienen jobs nocturnos muy largos (¡consigan HANA y pasen tiempo con sus familias, en lugar de perder tiempo con este tipo de cargas!).

La velocidad de ETL y Reportes es sólo uno de los aspectos de HANA como base de datos para BW. Otro aspecto igualmente importante (o quizá más) es la simplificación. Un BW más ligero es más eficiente a la hora de agregarle funcionalidad, así como también para administrarlo en un ambiente de producción. La Arquitectura Escalable en Capas ('Layered Scalable Architecture') de BW está evolucionando para darle el mejor uso al poder de HANA como base de datos. La funcionalidad que solía estar en la capa ABAP de BW con el tiempo se va moviendo hacia la capa de HANA para hacer que el modelo entero y el trabajo de procesamiento sean mucho más eficientes. Un ejemplo de esto es la activación DSO, que tiene lugar en una fracción del tiempo que tardaba en un sistema BW no basado en HANA. 

Muchos clientes de BW utilizan a menudo SAP Business Warehouse Accelerator para acelerar sus lentos RDBMS basados en disco. SAP HANA provee un landscape mucho más simple, que reduce TCO y complejidad. Por ejemplo, reduce drásticamente la cantidad de hardware necesario: para acelerar 5TB de datos en BW, harían falta 21 blades en BWA, mientras que con HANA basta un solo servidor, con el beneficio adicional de que no hace falta ninguna otra base de terceros, dado que HANA es la única base de datos persistente. ¡No hay que pensarlo dos veces!

La gestión de cambios es relativamente más fácil gracias a la posibilidad de armar más capas lógicas, en lugar de tener capas físicas. No hace falta reindexar los resultados (tarea que puede tardar horas) antes de que los cambios tengan efecto.

Más allá de todos los argumentos que ya he dado en este blog, veamos resultados reales. La mayoría de los clientes que ya han invertido considerablemente en BW siempre han tenido como objetivo aprovechar lo que ya invirtieron en un data warehouse de misión crítica y descubrir su potencial completo. Creo que esa oportunidad ha llegado gracias a la unión de BW y HANA.

La gran mayoría de nuestros más de 50 clientes BW/HANA del programa SAP Ramp-Up han obtenido resultados impactantes y un rápido retorno de inversión. Invertir hoy en HANA como base de datos para BW les ha preparado el camino para expandir el valor de HANA como un pilar para hacer análisis en tiempo real y como plataforma de aplicaciones innovadoras. Esto significa que HANA para BW es hoy el principio de la plataforma que van a usar en el futuro. Esa misma plataforma HANA habilitará nuevos casos de uso avanzado para análisis y aplicaciones de planeamiento, tales como apoyo a la decisión, análisis predictivo, minería de texto y búsqueda.

Además, se trata de una simple migración de sus bases de datos y SAP tiene recetas para brindarles ayuda al hacerlo.

Escenario #2: Tengo SAP ECC y quizá necesito BW, ¿qué hago?

La respuesta corta: depende.

Depende de una variedad de factores y consideraciones, según la gestión global de sus datos, y su estrategia fundacional de datos y análisis para el crecimiento. Por ejemplo, alguien que tiene necesidades de planeamiento puede aprovechar soluciones basadas en BW. Puede además considerar BPC sobre HANA o S&OP sobre HANA como posibles soluciones (esto podría requerir BW).

Para muchas compañías que ya hicieron una inversión considerable en SAP ECC y están buscando un enfoque 'enterprise' para su data warehouse que les permita consolidar datos corporativos y tener una fuente de datos centralizada confiable para el análisis, con una única versión de la verdad, SAP BW es la solución. Si alguien les dice que puede armarles un warehouse personalizado, similar a BW, que reproduzca todas las ventajas de BW, sin sus desventajas, me gustaría conocer a esa persona.

Si los sistemas de transacción de SAP son su fuente principal de información para reportes, entonces tiene mucho sentido usar BW como data warehouse para aprovechar su contenido empresarial y su arquitectura escalable en capas. Además, no hay ningún problema en tener BW sobre HANA Y TAMBIÉN un sistema HANA standalone, y que ambos formen parte del landscape al mismo tiempo, si hay casos de uso que así lo requieran. Tener ambos podría ayudarle a decidir si BW le conviene, en ese caso qué parte debería aprovechar.

Dicho esto, a veces una compañía tiene un problema muy específico, que se podría resolver mejor con un warehouse personalizado o bien con SAP BusinessObjects Rapid Mart.

Escenario #3: Tengo SAP ECC, pero me dijeron que SAP BusinessObjects Rapid Marts es mejor, ¿qué hago?

Respuesta corta: de nuevo, depende.

Es claro que los SAP Rapid Marts no sustituyen a un data warehouse; por eso no se llaman 'Rapid Warehouses'. Pero sí ofrecen valor para compañías que estén buscando un enfoque rápido y 'plug and play', si necesitan con frecuencia un datamart liviano con capacidades de análisis para un caso de uso departamental. En otras palabras, hay que considerar a Rapid Marts como un acelerador que puede ser el preludio a un proyecto más amplio de data warehousing.

Para aquellos que no estén familiarizados con el producto, los Rapid Marts incluyen jobs de captura de datos, así como mapeo y fuente de datos, y contenido paquetizado destinado a reportes para implementaciones BI aceleradas. Apuntan a las áreas clave de SAP ECC (p.ej. finanzas, recursos humanos, sector de producción, etc.) y son muy buenos para necesidades departamentales en una empresa grande, o en compañías pequeñas con escasos recursos IT pero con la necesidad inmediata de obtener información inteligente acerca de una aplicación ECC.

Escenario #4: Tengo SAP ECC y me ofrecieron un data warehouse diseñado desde cero, ¿qué hago?

Respuesta corta: los diseños son baratos; los deployments, no.

Si cree que eso no va a salirle caro, piénselo bien. Como enuncié anteriormente, SAP ha dedicado los últimos quince años a construir y perfeccionar mapeos de su suite a BW.

Por ejemplo, veamos las siguientes características: gestión integrada del ciclo de vida con SAP ECC, completa integridad transaccional de registros con ECC, modelos de datos pre-racionalizados y objetivos de datos para ECC.

Tratar de reproducir todo esto para su landscape SAP desde cero implicaría, en esencia, reinventar la rueda y no aprovechar nada del valor que ya está disponible en BW. En este escenario, una consideración importante es el diseño consagrado de SAP BW, junto con su contenido paquetizado y pre-entregado (que reduce el tiempo de implementación). Por estas razones, BW ha sido el camino que tomó la mayoría de nuestros clientes (más de 13.000) al elegir BW como su data warehouse.  

Me doy cuenta de que esto despierta el debate acerca de diseño vs. deployment, pero como dije antes: el diseño siempre se puede resolver con pocos recursos.

RESUMEN

Entonces, volviendo a la pregunta original: ¿HANA remplaza a BW? Creo que la respuesta es: no. Pero decir que "si no has deployado BW, no deberías" sería completamente irresponsable. HANA es definitivamente muchas cosas (una base de datos para BW, una appliance de alto rendimiento para análisis, una plataforma para nuevas aplicaciones), pero ofrecer un equivalente al sistema entero conocido como 'BW', punto por punto, sería un proyecto enorme para cualquier compañía.

No me cabe duda de que la mayoría de ustedes, que hoy tienen sistemas BW, van a estar de acuerdo y otros van a estar en desacuerdo conmigo (seguro, y espero un montón de citas del debate Inmon/Kimball). Agitar la conversación es ciertamente uno de mis objetivos. Sé que sólo cubrí algunos escenarios, y espero que las respuestas a este blog sugieran más escenarios específicos para la 'Parte 2' de este post.

Para una discusión inteligente de BW sobre HANA, visiten los blog posts del sitio 'Experience SAP HANA'.


No hay comentarios:

Publicar un comentario