Category Archives: BW

SAPPHIRE and ASUG 2012 Orlando – Days 0 and 1

This week I am attending SAPPHIRE NOW and ASUG Annual two-in-one conference. There are many interesting developments going on in SAP in the areas of cloud, platforms, mobility, but my focus is broad BI/EIM/DM and this is what I am after at the conference. Co-location of SAP’s premier business conference and SAP users’ largest event gives a interesting – and sometimes polarized – view on the state of the business: you see cool HANA-powered mobile-steered 3-D demos on the show floor and you listen to the real customers’ far-from-perfect stories.

It’s been just two week since the end of my first SAP BusinessObjects BI 4.0 implementation project (my day life is a technology consultant), and the everyday life stories are closer to my heart than bright roadmaps. My first experience with SBO BI 4.0 was  polarized as well. On one hand the breadth of tools portfolio and user’s UI are way better than what SAP/BW could offer with its BEx applications. On the other hand, from the administration point I would expect much more from BI Platform’s CMC, as a single tool for administration, monitoring, and trouble-shooting. Yet all of these are a subject for a separate post. The point here is: with the realise  4.0 of SBO BI, I can easily say that it’s now at the stage where BW customers can and should start looking at the adoption of BusinessObjects BI tools as the front-end for BW data warehouse. Not completely there yet, but certainly incomparably better where it was three years ago. I ran into some discussions with fellow SAP Mentors over that statement. As I was complaining that we waited long 4 years for good BW/BO integration, my dear colleagues with pure BusinessObjects background, like Mico Yuk here, were complaining that SAP almost completely forgot about them and about innovations for the non-BW customers. What is your opinion?

The first ASUG education session I attended was by Jeff Duly on the topic of SBO Explorer, accelerated implementation by their BW shop. Besides few minor issues, the business response was overwhelmingly positive, just to confirm the statement that SAP’s decision to acquire mature BI tool set in 2007 was the right one (see also remarks above about the need to continue the integration and unification work).

The second ASUG session on my radar was the SAP HANA Ramp-up customer story. On the closer look, the story was rather about the benefits of BI implementation, as the customer moved from manual collection of data from four source systems and the development of reports in the MS Excel to the BI solution using SAP BusinessObjects’ WebI and Xcelsius as the front ends and SAP HANA database as the repository for the new data warehouse. What was extremely interesting in that session are lessons learned. I think they were extremely important to repeat them here:

  1. Data. SAP HANA database by itself helps with the processing speed, but without proper data quality, you will get garbage out just faster. I blogged about this a year ago in “Critical Success Factors for SAP HANA implementations
  2. Ramp-up means “bleeding edge”. Experienced professionals know the meaning behind someone’s sentence “We learned a lot during this implementation” 😉
  3. Realistic speed depends on complexity. In reality the performance of the query processing depends on many factors, major of which – when I/O bottleneck is eliminated – is the complexity of tables’ joins.
  4. UI rendering time. SAP HANA database dramatically improves performance in data retrieval, but it is still only one of few steps on the way between user’s request click and the final display. Accordingly to presenters, the times to transfer data from HANA to the end-user machine and then get it displayed could go up to 20 seconds – leaving the impression of “long processing” even when the query processing in HANA had taken only 2-3 seconds.
  5. Realistic time frame. They kicked off the project in May of 2011 with the plan of go-live in September 2011. But the acceleration of the data processing does not translate into the acceleration of project phases (although no doubt mean less frustration for everyone ;-), and the project went live 4 months later than expected.

The customer implemented the project with engagement of SAP Consulting and as I look around it is the case for almost every HANA implementation right now. If you are not a consulting arm in the one of the hardware vendors (HP, Hitachi, IBM etc) and if you are not one of the IT advisory companies (Deloitte, CapGemini etc) already working with the customer on the broad scale – it is difficult to get on the HANA implementation projects. It may be a cold shower for many smaller System Integrators (SIs). As HANA fewer spreads many of these SIs are establishing “HANA Centers of Expertise” and “HANA practices”, putting directors in place, making press announcements, but do not have projects… Here at the SAPPHIRE I met two of these “directors” already, who approached me asking how HANA implementation projects look like and what works and what not.

My first advise for them was: re-think what you want to do, analyse the broadening spectrum of HANA applications, and then try to focus. The thing is that SAP HANA world is huge and expanding and you cannot be in all places at all times. Especially if you are a small SI or a boutique firm.

My second advise was: SAP HANA itself is just an element of the broader SAP’s database portfolio. If you want to focus on the SAP database business, you need to make sure that besides HANA you can speak Sybase as well. If you want to focus on the SAP business applications powered by HANA (like Rapid Deployment Solutions – RDS), you need to speak the broad portfolio of SAP applications in the LoB or Industry area, which may not be powered by HANA today. If you want to focus on analytics, you need to speak broad portfolio of SAP BusinessObjects – BI and EIM – as well, and know how to build solution in SBO, which runs on HANA database, but as well on MS SQL Server, Sybase IQ, HP Vertica etc.

Going back to those who want to focus on the HANA as the database business with SAP, it is important that you separate hype from reality and understand the April 10th announcement of “SAP Real-Time Data Platform”.


Filed under BusinessObjects, BW, HANA, Rant, SAP, Sybase

BW 7.3 Orange (powered by SAP HANA) is just the beginning

In the podcast “Debating the Value of SAP HANA” mentioned in my previous post, we ran into the discussion if SAP NetWeaver BW 7.3 SP5 powered by SAP HANA (project “BW Orange”, or simply “BW-on-HANA”) is the killer app or not for SAP in-memory technology. My answer was “Yes”, but here I would like to go into the grades of shade beyond this binary question.

There are very few customers out there, who would not complain about some aspects of the performance of SAP/BW. I had been presenting sessions on BW performance at different conferences since 2008, and they always resonated with the audience. BW-on-HANA, which comes with the major promise of performance boost for both front-end (querying/planning) and data warehousing parts, will resonate with almost every BW customer. I see it in my day job as a consultant.

It is a no-brainer that reading all data at the speed of RAM, instead of disks, will resolve lots of I/O-heavy processing. You may share my memories of frustration, waiting for long-running BW operations – queries, DTPs, extractions, where the only proof that the work session is still alive was to go to transaction DB02, find your running SQL and then see slowly but steadily increasing numbers under “blocks read”. This should be a song of the past with BW running with HANA system. The advantages of in-memory data retrieval are obvious, and there should be no discussion about this aspect of BW Orange.

But I/O bottleneck is not the only reason for slow performance. Accordingly to SAP’s own statistics presented during SAP TechEd’10 USA in ERP about 20% of the processing is happening in the database layer, and the rest 80% is in application (ABAP) layer. Obviously in this case super fast database can resolve only 20% of performance issues. Althought the ratio 20/80 will be different for BW, as more heavy BW joins or massive inserts are done, the problem remains the same. Through the years BW (like most of the other ABAP-based systems) was built to run lots of the intensive processing in the application layer. Analytics (OLAP and Planning) Engine) being the prominent example. DSO activations, SID calculations, user exits are some more examples from the data warehousing part of BW.

Therefore BW Orange release introducing some applications optimizations, which are specific to SAP HANA and cannot be reused by BW running on any other database system. You may have heard about those by now:

  1. HANA-optimized InfoCubes, i.e. different technical design of underlying database tables, and different querying technology,
  2. HANA-optimized DSOs and the new activation process executed in the db layer,
  3. New Planning Applications Kit, which allows execution of BW-IP standard functions within HANA db.

As you see the list of optimizations is not going through all BW components. Additionally, optimizations are not 100% applicable, i.e. in some cases tables layouts remain the same as on regular databases and processing is executed in ABAP layer, like in case when DSO is  supplied by RDA real-time data acquisition (see OSS Note 1665322 – Conversion for SAP HANA-optimized DataStore objects). In some other cases “Remodeling might be required to leverage Hana optimization when starting from an existing scenarios” (OSS Note 1637199 – Using the planning applications KIT).

The human brain and hands are not yet completely eliminated, and we all are just at the beginning of the extremely interesting journey.

1 Comment

Filed under BW, HANA, Rant, SAP