Etiqueta: HANA

SAP BPC 10.0 NW powered by SAP HANA, protagonist del SAPPHIRE NOW

SAPPHIRE NOW es el evento más importante del mundo SAP, es organizado por SAP y ASUG (Americas’ SAP Users’ Group), tiene alrededor dos ediciones por año, en 2012 la primera se celebrará en Orlando la próxima semana y la siguiente en Madrid, a mediados de noviembre.


SAPPHIRE NOW es el evento más importante del mundo SAP, es organizado por SAP y ASUG (Americas’ SAP Users’ Group), tiene alrededor dos ediciones por año, en 2012 la primera se celebrará en Orlando la próxima semana y la siguiente en Madrid, a mediados de noviembre.

En estos eventos siempre hay algunos temas que acaparan la mayor atención y cobertura en los medios sociales (blogs y redes), en ediciones anteriores fueron SAP BusinessObjects BI 4.0 y SAP HANA, ahora todo apunta que serán las aplicaciones que se están desarrollando alrededor de SAP HANA, las estrellas del evento.

SAP BusinessObjects Planning and Consolidation for Netweaver 10.0 SP 06 (SBOP PC o SAP BPC NW), es el primer gran producto diseñado para utilizar toda la capacidad de procesamiento que tiene SAP HANA. 

SAP BPC 10 NW by SAP HANA, no se trata de un producto adicional, es el mismo que se utiliza sobre plataformas tradicionales, que al desplegarse sobre SAP HANA, permite un diseño más optimizado de modelos (aplicaciones que físicamente generan cubos de datos sobre SAP NW BW 7.3) que se benefician con el procesamiento paralelo en memoria o cálculos en bases de datos, que repercuten es transacciones más rápidas al grabar y leer la información. Un ejemplo de esta capacidad de procesamiento lo encontramos en el blog CFO Knowledge.

Nuestra apuesta es por SAP HANA y por productos como SAP BPC que de adaptan o desarrollan para utilizar el in-Memory Cmputing.  El objetivo no es la velocidad, la velocidad es el instrumento que facilitará el logro de nuevos objetivos, muchos de ellos, inimaginables hasta ahora.

Sin tapujos, Oracle vs SAP, por el liderazgo del in-Memory Computing

Hasta una semana, la hostilidad entre Oracle y SAP por lo que podríamos denominar la cuota de mercado de las bases de datos con procesamiento en memoria (in-memory Computing) parecía más ilusión de la prensa, pero por lo visto en los últimos días, la “guerra es abierta” y el “combate es cuerpo a cuerpo”.


Hasta una semana, la hostilidad entre Oracle y SAP por lo que podríamos denominar la cuota de mercado de las bases de datos con procesamiento en memoria (in-memory Computing) parecía más ilusión de la prensa, pero por lo visto en los últimos días, la “guerra es abierta” y el  “combate es cuerpo a cuerpo”.

Oracle no cesa en afirmar que SAP HANA no es producto que pueda afectar a su tradicional negocio de base de datos, pero cada vez que tiene que hablar de sus propuestas in-Memory, habla de SAP HANA, algo similar como lo que sucede con aquel entrenador de futbol que cuando debe hablar de su equipo, habla de otro equipo.

Hace una semana Oracle publicaba una presentación que ha desatado la furia en SAP, generando respuestas inmediatas hasta del Vicepresidente Ejecutivo de SAP, Steve Lucas, quién ha considerado el documento de referencia un ataque por la cantidad de errores e inexactitudes que contiene.

No conocemos la propuesta in-memory de Oracle, pero particularmente nos parece algo compleja, repartida entre Exadata (entendemos que es la base de datos in-memory genérica) y Exalytics (la propuesta in-memory para necesidades de Business Intelligence) que al parecer, vista la documentación, necesitaríamos “vincular”. 

Comparar Oracle Exalytics con SAP HANA, nos parece tan “lógico” como comparar naranjas con manzanas, las dos pueden ser muy buenas, pero responden a necesidades distintas.  Oracle la percibimos como una base de datos y SAP HANA como una plataforma sobre la que se están desarrollando una nueva generación de aplicaciones, inclusive SAP ERP.

Unos de los aspectos que más críticas a suscitado ha sido la comparativa de funcionalidades entre Oracle Exalytics y SAP HANA, una primera impresión podría conllevar a la conclusión que la propuesta de Oracle “tiene más” o “es mejor”, pero resulta que la mayoría de características que figuran en esta tabla, tales como los agregados o índices, no son incluidas en la tecnología de SAP porque son innecesarias y no contribuyen a una mejor eficiencia.  Como señala el post de Steve Lucas, es como comparar la tecnología de un carruaje tirado por caballos y un automóvil, el primero ya puede señalar que incluye el cubo y una pala para recoger los excrementos de los animales.

Otro aspecto que para SAP es incorrecto, es la referencia de precios, en el artículo del Vicepresidente de SAP, se señala que se cobra por la estimación de datos a procesar,  según esto se determina las necesidades memoria y unidades a utilizar (1 unidad = 64 GB) la cual valdría a 13 euros por unidad.  Si algo tienen en común estas tecnologías es que utilizan un hardware específico, pero mientras de Oracle es sólo Sun, SAP HANA está disponible con el hardware de Fujitsu, Dell, IBM y HP.

Nuestra apuesta para procesamiento in-memory es SAP HANA.  Al igual que otras opiniones, tenemos la sensación que las propuestas de Oracle han sido diseñadas apresuradamente sobre su modelo tradicional de bases de datos y no descartamos que en el futuro inmediato presenten un nuevo producto.

Referencia: (documento de Oracle)

RDS también para SAP HANA

Los denominados “Rapid-Deployment Solution” (RDS) son una alternativa para cubrir ciertas necesidades de los procesos de negocio de las organizaciones y en algunos casos son específicos para determinados sectores. Son desarrollos que requieren muy poca personalización, reduciéndose su tiempo de implementación entre cuatro y seis semanas.


Los denominados “Rapid-Deployment Solution” (RDS) son una alternativa para cubrir ciertas necesidades de los procesos de negocio de las organizaciones  y en algunos casos son específicos para determinados sectores.  Son desarrollos que requieren muy poca personalización, reduciéndose su tiempo de implementación entre cuatro y seis semanas.

Hace unos días comentábamos los modelos (aplicaciones) que se están desarrollando alrededor de SAP BPC bajo la filosofía RDS, ahora se trata de SAP HANA que también avanza en esta línea.  El uso de RDS no está muy extendido, quizás por desconocimiento o por cuestiones culturales, pero hay muchos procesos que tienen una estructura similar en todas las organizaciones, si se parte de algo que ya existe y en el que se han aplicado las ”best practices” se podría ahorrar tiempos y costes de implementación.

Referencia: (pdf)

SAP HANA a prueba para BI

SAP ha publicado los resultados de una prueba del rendimiento de SAP HANA para necesidades de Business Intelligence. Para lo cual definió un escenario de ventas con cinco años de transacciones que equivalían a 100 TB de información (aplicando una compresión de 20X, en base de datos ocupó 3,78 TB).


SAP ha publicado los resultados de una prueba del rendimiento de SAP HANA para necesidades de Business Intelligence.  Para lo cual definió un escenario de ventas con cinco años de transacciones que equivalían a 100 TB de información (aplicando una compresión de 20X, en base de datos ocupó 3,78 TB).

Para este entorno de pruebas se configuró unas características de hardware detalladas en informe adjunto y se definieron una serie de consultas SQL que equivalen a las consultas que se generan en un entorno de BI.

La conclusión más relevante es que el acceso a los cien mil millones de filas (100.000.000.000) consumieron entre uno y dos segundos para el caso de los informes con opciones de drill-down (profundizar o detallar la información) y hasta un promedio de 3,8 segundos para las consultas de tipo analíticas, las cuales implican mayor complejidad al incluir combinación de tablas y comparaciones de períodos.  Estos tiempos de acceso es lo que algunos llaman “Real-time BI”.

Referencias: (informe)

Pensamiento Big Data

Cuando se habla de Big Data (para nosotros, la gestión de grandes volúmenes de información) se recurre a la mención de las “V” (uves), algunos señalan entre tres y cuatro, y otros con, “más perspectiva”, hasta cinco.


Cuando se habla de Big Data (para nosotros, la gestión de grandes volúmenes de información) se recurre a la mención de las “V” (uves), algunos señalan entre tres y cuatro, y otros con, “más perspectiva”, hasta cinco. 

De todas estas palabras, que se han identificado o inventado para explicar en qué consiste Big Data, nos quedamos, en primer lugar, con dos de ellas, Volumen y Variedad que describen la naturaleza de los datos, Velocidad que sintetiza la forma en que deberían ser procesados y por último, Valor, que es la sensación que debe aportar el resultado a los usuarios.

Sobre la naturaleza de los datos (p.e. estructurados y no estructurados) poco podremos hacer.  Influir sobre  la forma de procesamiento para que realmente sea veloz, dependerá, en gran medida, de la tecnología elegida.  Quizás, sobre el factor que más influencia podrían tener los usuarios, sería la obtención de valor, entendiendo la “obtención de valor”, en este contexto, como la obtención de una nueva información, desconocida hasta entonces, que podría ser útil para tomar decisiones, aprovechar oportunidades o evitar riesgos que no se aprecian con los sistemas de información tradicionales.

¿Cómo Obtener Valor?

En una entrevista a Timo Elliott encontramos unas pautas a tener en cuenta, para lo que nosotros denominamos “Pensamiento Big Data”:

  • Conocer los procesos de negocio de la organización.
  • Conocer cómo se consume la información dentro de la organización.
  • Conocer los punto de decisión más críticos y encaminar las discusiones utilizando un razonamiento “Qué pasaría si (“What if”)
  • Utilizar herramientas de visualización que faciliten la compresión de los resultados (“what could be”).

A nuestro parecer, la clave del “Pensamiento Big Data” es plantearse preguntas tales como “¿Y si pudiéramos predecir de antemano si las entregas eran propensas a llegar tarde?” de este modo, podríamos estructurar y encaminar las necesidades de una organización y las expectativas de una autentica obtención de Valor, la “uve” más importante del Big Data.