Skip to Content

Per a special request from my man Corey Adams I’m reposting this from my personal site to SCN.

This post was inspired by a Video Report Card for SAP Analytics I was fortunate to be able to participate in with Jon Reed (the sponsor) and included John Appleby, Derek Loranca, and Clint Vosloo. No one paid me anything for that. 🙂

The last two years have seen a flurry of activity from the Analytics team at SAP. A lot of things that were promised were delivered. New tools like Visual Intelligence, Predictive Analysis? Check.  Xcelsius roadmap (including the new Design Studio)? Check. BI4 stability? Getting checkier by the day. Are their some concerns still left with these items? Sure, but we are certainly better off on these fronts than we were a year ago.

The bigger problem with the current state of the portfolio is a burgeoning list of Semantic Layers for the SAP Analytics tool set (see around 17:19 of the video). We have the Universe (the one that SAP paid €4.8 billion for in 2007 and temporarily referred to as the Common Semantic Layer in BI4 until they realized it wasn’t), we have the BW semantic layer, and we have the HANA semantic layer, and none of them talk to each other particularly well (or at least best practice is that they shouldn’t).*

Certainly there are some advantages to allow these three semantic layers to continuing growing in their own directions. Innovation that applies to only one data source can be sped up because it doesn’t have to worry about integrating with the others. Performance can be optimized because only one source system with its particular constraints must be considered. Unfortunately I don’t think that begins to outweigh the disadvantages for both customers and SAP itself.

The disadvantages for customers apply to both legacy SAP and classic BusinessObjects customers. The two key issues I see are the slowing of innovation across the portfolio and the extra work required to maintain multiple semantic layers. Even if SAP wanted to invest for all three data sources (HANA, BW, Universe) simultaneously, it just wouldn’t make sense. Investing every minor semantic layer change in each system to work with all of the reporting tools in the portfolio would be absolute murder, not to mention that any change to a reporting tool would need to be run back through three different sets of semantic layer developers to ensure integration. This creates a lot of points of failure at a time when stability has been recognized as a serious source of concern for customers.

If this three-headed monster continues, it also follows that the Total Cost of Ownership of any such system is going to balloon for customers. If the BusinessObjects platform has more things running under the covers that means more or at least bigger patches which means you’ll need more administration time, more testing time, and more end user communication and training. And that’s just if you employ one of these tools. If you’ve got more than one semantic layer running you’ll need to have experts in each, or one very thinly stretched expert (who will be constantly looking for another job). This also means more training for users, more confusion, and a real loss of goodwill from users who now have to understand connecting to multiple data sources in a  reporting tool rather than just understanding how the Universe works and going from there.

Multiple options exist. SAP could continue investing in all three, but that is problematic because of the reasons published above. Encouraging customers to run all of their HANA data through BW has some potential, but it seems that takes away a lot of the benefits of HANA without a lot of benefit from BW. They could invest heavily in HANA semantics and offer fantastic pricing, although that still won’t solve the enormous amounts of data that are not and will never be stored in-memory that still need accessed (not to mention the loss of goodwill from legacy BusinessObjects customers whose only solution is buying new software).

In the end the best solution is simple albeit not easy: make HANA and BW work properly through the Information Design Tool (IDT – the successor to the pre-BI4 Universe Designer). I know this wouldn’t be easy, but I’m not sure why we have to actively encourage people to avoid the using the IDT when connecting to BW or HANA data sources. Perfect the “common” semantic layer for any data source, and every reporting tool downstream would be able to innovate on features and not just play catch up on connectivity. It would have been better to do this before the release of BI4, spending the million man hours on perfecting the semantic layer with slight tweaks to the reporting tools. I realize that exploding pie charts with sound sell software, but software that is easy to use and cheap to maintain sells itself.

* It’s worth noting that we also have legacy .UNV files (from the old Universe Designer and new Universe Design Tool), Analysis Views (for OLAP), Crystal Reports Business Views (which are deprecated but have no migration option).

I’d also ask you to check out the comments on my original post. Some pretty smart people weighed in.

To report this post you need to login first.

14 Comments

You must be Logged on to comment or reply to a post.

  1. Ingo Hilgefort

    I am posting my comments here as on the original post there is a limit that did not allow me to post a comment of this size:

    Hello everyone,

    Perhaps lets clarify first of all a couple of items as I see a couple of items getting mixed up here:

    The blog post is about:

    – SAP NetWeaver BW

    – SAP HANA

    – SAP BusinessObjects Semantic Layer (Universes)

    lets then clarify what these items are:

    – SAP NetWeaver BW is datawarehouse management software running on a database

    – SAP HANA is a database

    – A Universe is  an abstraction layer of data sources (including SAP NetWeaver BW and SAP HANA)

    It was mentioned that those items don’t talk to each other, which is not correct here:

    – Universes can talk to SAP NetWeaver BW and to SAP HANA and to other data source and Universes are also able to combine all those sources into a multi-source Universe

    – SAP NetWeaver BW is able to use SAP HANA as a database

    – SAP NetWeaver BW can leverage HANA as a “side car” and treat SAP HANA as a separate data source

    – SAP BW is able to combine SAP BW and HANA models

    – SAP HANA is able to leverage SAP BW data models as well

    Some links for more information on those items mentioned above:

    Thomas Zurek explaining how BW can combine data models with BW

    http://scn.sap.com/people/thomas.zurek/blog/2011/11/01/how-bw-on-hana-combines-with-native-hana

    Updates in SAP NetWeaver BW 7.3 SP08 with details on how BW can leverage HANA and HANA can leverage BW

    http://www.saphana.com/community/blogs/blog/2012/10/08/whats-new-with-sap-netweaver-bw-73-sp-8

    Some HANA modeler videos on using BW models in HANA

    http://www.saphana.com/community/blogs/blog/2012/09/27/modeler-unplugged-episode-11–importing-bw-models-as-native-hana-models

    http://www.saphana.com/community/blogs/blog/2012/10/11/modeler-unplugged-episode-13–exploring-data-for-hana-models-imported-from-bw

    So that should clarify the fact that these item are talking to each other.

    There is also a very good reason why – in the case of SAP NetWeaver BW and SAP HANA – there is no need for an additional layer like a Universe, because there is already a layer that fulfills that need.

    In the BW case that is the BEx query layer

    In the HANA case those are the analytical models.

    .. and the SAP BusinessObjects BI Suite is capable of leveraging those assets.

    Now lets talk about the suggested investment areas:

    – Encouraging customers to run all of their HANA data through BW has some potential, but it seems that takes away a lot of the benefits of HANA without a lot of benefit from BW.

    Customer can already combine SAP NetWeaver BW and SAP HANA data models without having to bring in data to BW, as mentioned above already.

    – They could invest heavily in HANA semantics and offer fantastic pricing, although that still won’t solve the enormous amounts of data that are not and will never be stored in-memory that still need accessed (not to mention the loss of goodwill from legacy BusinessObjects customers whose only solution is buying new software).

    SAP HANA “semantics” already exist in form of SAP HANA models and SAP HANA content (for example with ERP / CRM on HANA with the Analytical Foundation).

    In the end the best solution is simple albeit not easy: make HANA and BW work properly through the Information Design Tool (IDT – the successor to the pre-BI4 Universe Designer)

    Here the assumption is made that everyone wants to use the IDT, which is not the case. Why should a BW based customer or a HANA based customer leverage an additional layer on top of those solutions, if everything already exists in those solutions. Forcing the customer to use it, is not an option. The ability to leverage IDT for BW and HANA already exists, but it is optional and not mandatory.

    in addition a few comments on comments made by Josh F:

    item 1: The items listed here such as a currency conversion or a hierarchy are not “semantic layer” items, but more a modeling question. A currency conversion can also be created in the universe by simply using the tables and a hierarchy can also be created by either using tables reflecting the hierarchy or by modeling it in the underlying source. The “semantic layer” of BW is the BEx query, but items that were mentioned here are more a modeling topic.

    item 2: here the Real Time Data Platform (RDP) is mentioned in the context of a semantic layer but the RDP solution is focused on data processing, data storage, and data movement. For sure SAP BusinessObjects plays a role and is already part of it – see the link for further details and also the question about non-HANA source is already answers as Sybase IQ and Sybase ASE are part of the overal RDP platform (see the link for details)

    item 3: SAP HANA is already able to fulfill that scenario today because if customers would like, they can bring in all the data into the HANA instance, there is no need to have an HANA instance sitting inside the SAP BusinessObjects BI platform. Any data can be moved into the SAP HANA instance and the SAP BusinessObjects BI layer is already able to leverage it today.

    Link to more details on RDP:

    http://www.saphana.com/community/blogs/blog/2012/12/05/the-path-forward–the-sap-real-time-data-platform-powered-by-sap-hana

    Overall there is the talk about three semantic layers here and we could probably keep increasing the number even more because a customer that runs for example BPC on a Microsoft landscape would most likely refer to all the assets in BPC as “semantics” as well.

    Can customers leverage the SAP BusinessObjects BI Semantic Layer in form of Universes today with SAP BW and SAP HANA and other data sources – yes.

    Can customers combine those data sources using the SAP BusinessObjects BI Semantic Layer – yes

    Do customers have to use the SAP BusinessObjects BI Semantic Layer as a mandatory component – NO – it is their choice.

    regards

    Ingo Hilgefort, SAP Canada

    (0) 
    1. James Oswald Post author

      Ingo,

      Thanks for your comment. I’m sure it is, strictly speaking, a technically accurate account of where we are today. In this post I was trying to be a little more forward looking and represents my opinion of where I’d like to see SAP invest in the future and what that would allow their customers to invest in.

      (0) 
      1. Ingo Hilgefort

        Hi Jamie,

        strictly technically speaking – I wanted to make sure that we are talking about technically accurate information here as you are making some statements that – from a technical point of view – I think needed to be correct and have more information provided, such as the part how BW, HANA, Sybase, and the semantic layer do work together.

        And it is not just about where we are today. Forcing a customer to use the Semantic layer when already all the information that is needed is available – such as in BW or in HANA models – can’t be a solution. Customers will always need a choice and why forcing something on them if it is not needed.

        regards

        Ingo Hilgefort, SAP

        (0) 
    1. James Oswald Post author

      Sue,

      I’m assuming you’re planning a flashy-blinky attack on these people if we don’t get some resolution soon. Thanks for having my back, mi amiga.

      (0) 
    2. Vijay Nachimuthu

      Susan – it was a gross oversight on our part letting our interns plagiarize on other people’s content. We have requested them not to infringe and will see to that it doesn’t occur. Had it brought to our attention via our contact page, we would have taken it down immediately rather than finding it thru this conversation.

      We don’t make a “dime-off” as we are not in the BI business. It was just an oversight by inexperienced by our staff. Thanks

      (0) 
  2. Corey Adams

    Great post Jamie and thank you for posting it in SCN, sorry it’s taken so long for me to join the party.

    I am hopeful that this topic will get an airing beyond the usual group of Universe supporters and Bex “Die Hards”, let’s hope that happens and we get a few new contributors and points of view because it really is an issue.   My only concern is that I may be hijacking your blog rather than writing my own, if that is the case, I’ll apologise and put it down to being a Newbie and raw passion for the subject. 

    So, for me, as a customer with BW, Hana and BI4, the number of semantic layers, tool crossover, and lack of a clear indication of SAPs strategy, is a major source of frustration.   I have a foot in each camp, this represents ample risk in investing my resources in any of the directions outlined both in the podcast and your blog.   Without clear direction of intent, it leaves me to assume which path is sound and extensible and we all know where that leads us right?  

    Secondly, as a little disclaimer and to highlight Jamie’s point on TCO – I am a legacy BOBJ’er and despite having invested heavily in Bex training, a heap of books and technical consultants to sit next to me and show me all things BW/Bex and Hana, I am far from an expert and can only base my comments on my own experience.   Having said that, this Novel of a reply is based on my experience and in an effort to go beyond “technically you can”, is by no means sugar coated.

    So, chick – chick – boom!  Let’s go!

    I agree whole heartedly that the number of semantic layers is an issue, I am hopeful that it is a short term issue and very soon, SAP will come forth with guidance on which of the semantic layers is the future and will be developed beyond simply “Technically you can”.   I hope that there will also be a seamless method of promoting content created with/for the remaining semantic layers to the tool that is the golden child.   This will allow us to develop our strategies to transition to the Nirvana we all share, whilst ensuring we keep our legacy investment serviceable.   As to which of the semantic layers I think will or should be the Golden Child, not yet, I’ll group my thoughts first.

    I believe the Bex “semantic layer” and all things to do with it are purely for the benefit of Legacy SAP customers, a method for those customers with significant pre-existing investments in BW architected content (content leveraging Info Providers, the Bex query and Bex Analyser tools) to use the new BOBJ tools without massive redevelopment.   I get this and it makes sense, in fact had to be done, in order to ensure there is a progression plan for the existing content, what I don’t understand is why it is pushed as being “the” semantic layer if you are using BW.   It is true to say “Technically speaking” you don’t need a Universe to access BW content, but not to infer that it is an equitable solution.   Due to limitations with the application and the intricacies of the BW architecture, there are many limitations, restrictions and implications of its use, and after yesterday’s announcement, I don’t buy that it is the future of BI with SAP.   A way I would suggest is better to express it is, “the Bex Query is the semantic layer when using a Bex Analyser Report, it can also can be used as a source for Webi, exposing some of the Webi functionality”.

    There are many considerations for each of the methodologies, and many things that frustratingly get missed out of conversations about strategy.  I have a lot to say on the topic and I could go through all of the semantic layers, outlining the pros and cons from my perspective, but fear I would definitely be high jacking Jamie’s blog in that case.

    What I will say is; when talking strategy, too many times I hear “technically”, this applies to semantic layers and tools.   It is awesome to know what is “technically” possible, but “technically” is morphing into a dismissive “I don’t want to talk about that” statement, or even a semantic layer all of it’s own, saving me the complexity of the detailed pros and cons I need when architecting a solution that will stand the test of time. 

    Whilst it is good to have flexibility and choice, SAPs customers (me especially) are looking for a clear strategy, best practice, and concise recommendations.   But I don’t call what I have now “Flexibility”, as it stands now, if I want to use all the tools, I have to use all the semantic layers.   That is not choice, that is waste!   Refer to Jamie’s comment on TCO.

    Also, this comment, sorry to single it out, but I think it touches on the foundation of our collective problem…..

    There is also a very good reason why – in the case of SAP NetWeaver BW and SAP HANA – there is no need for an additional layer like a Universe, because there is already a layer that fulfills that need…..In the BW case that is the BEx query layer….In the HANA case those are the analytical models.”

    For the legacy Business Objects crowd, there is very much a requirement for a Universe, the question is, do we need the other layers?   See, whilst Bex, at a stretch, can be referred to as a semantic layer, and perhaps Hana Information Models can too, what they are not is a Universe.   What the legacy BOBJ folk know and love is the Universe, its contexts, its aggregation awareness, and ultimately its malleability, fast turnaround and low TCO.

    What our users love is, no matter what the end tool, the data source experience is fairly consistent, same folder structure, same process of building the query, same demarcation point for IS/BI.

    As good as Hana is, Hana does not have these things, and Bex certainly does not, and putting all 3 together in under the guise of providing flexibility, doesn’t quite cut it either.

    So, what do I want?   What will solve my issues? 

    A single common semantic layer that is smart enough to determine the language, strengths and weaknesses of my underlying data source, one that all my BI tools can leverage.   I do not care if my individual tools can access different data sources or different semantic layers (that is great for those who need it), what I do care about is a single, best practise recommended path.

    Is that hard?

    Well maybe, but I tend to think, if you let all BW customers access the tables under BW (with the BI4 tools only), and have Analysis Office and all the other tools work through the Universe, isn’t it done?

    And, I sense it coming, so to head it off a the pass, yes, “Technically” BW customers can access the tables directly, if on Hana, but, detail, if you are on the “Hana for Applications and Accelerators” license or just stand alone BW, you cannot.

    Footnote: Reading this back, it may be viewed that these comments are levelled at an individual.   To be clear, they most definitely are not, this is an SAP problem that needs SAP attention.

    (0) 
    1. James Oswald Post author

      Corey, I appreciate the novel of a comment. The bottom line to me is that as a customer, even if I only have one of these data sources, it’s hard to believe that SAP can be truly investing in innovation in every combination of 3 semantic-ish layers and 8 reporting tools, so I’d think it would make sense to whittle that down to 1 semantic layer (with direct access to BEx and HANA still supported but not recommended and not continually invested in) and eventually 3 or 4 reporting tools, each of which could, in theory, get 6 times the annual investment they are receiving now.

      (0) 
    2. Ingo Hilgefort

      Hi Cory,

      let me give you a few responses here and lets start with a few clarifications:

      – Universes can talk to BW and HANA

      – Universes are choice – not a mandatory step

      – The strategic direction for SAP BW based customers has bee communicated very clearly is the direct connectivity to the BEx query layer

      – Universes are recommended in case a customer would like to create a multi-source universe, otherwise the recommendation is to use the direct connectivity to the BEx query

      … and not “technically” but strategically the BEx query is the layer for BW customers.

      For a classic BOBJ deployment with – lets take an example a Teradata warehouse – yes the Universe is the choice.

      For a HANA or BW based customer, those are the analytical modes in HANA or the BEx query in BW.

      The Universe is an option – but not a mandatory step.

      .. and btw – pointing a Universe to the tables in BW clearly is not the solution – very technically speaking now and it has nothing to do with BW on HANA or BW with HANA as a side car.

      The Universe is an optional layer and the strategy for BW customers is the BEx query – that has been communicated for a very long time already.

      regards

      Ingo Hilgefort

      (0) 
      1. Corey Adams

        Hey Ingo,

        Thanks for your response.

        Sorry Jamie, here comes the highjack bit.

        1a. I know universe can talk to BW, through the Multisource unx, which uses the DF engine, which uses the JCO connector, which queries 1 table at a time, which is recommended normally as a last resort (but with BW is the only relational option) because of poor performance, over use of the BI DF server and just simply not nice!  Again, detail, technically you can, but is it a good option?

        1b. Universes over Hana are one of the most forward thinking and excellent suggestions to come out of SAP BI in ages, more info …. Link 1

        2.  True, although not manditory, are they recommended?   What we are asking for here is a recommended best approach, not a mandated one.

        3 and 4.  Using the Bex query is akin to using a Stored Procedure under Crystal, point to point, and although great for a quick fix or POC, not sustainable as a strategy from a TCO perspective.   Also, quite simply, in a lot of cases, it just simply does not work!

        So rather than respond to every point, here is a couple of links that highlight the inconsistency in the message from SAP.

        1. Creating a universe on SAP Hana: Best Practises – buff.ly/TzVshv

        buff.ly/TzVkOU

        buff.ly/UrsjE6

        (0) 
        1. Ingo Hilgefort

          Hi Corey,

          here some answers :

          on 1a)     The performance of the Relational Universe compared to the BEx query (assuming same volume and objects) will be very similar and the usage of the Relational Universe option has nothing really to do with the performance unless we talk DSO layer where the relational Universe can be a better option compared to the BEx query.

          on 1b) on HANA we also offer the same concept – there is the option to use a Universe or not to use the Universe and instead use the direct connectivity for Web Intelligence or Crystal Reports or Analysis. The Universe is an option.

          on 2) For the BW based customers the recommendation is to use the direct BICS connectivity, as stated before.

          on 3 /4 ) not sure what you are referring to here but the direct BICS connectivity works very well with Crystal Reports for Enterprise and Web Intelligence and Dashboards and Analysis.

          For BW customers the recommended approach is the BEx Query and the Universe plays a role in case the customer wants to join multiple data sources in a Universe (and not in the DWH layer).

          .. and accessing the tables in the underlying database of a BW system (beyond licensing and legal implications) will not provide the technical information and the link you shared is talking about HANA – not BW and not BW on HANA.

          The message is very clear :

          For BW customers the recommended approach is the direct connectivity towards the BEx query layer.

          Ingo

          (0) 
          1. Corey Adams

            Thanks again Ingo,

            Very interested in exploring the logic, but fear that this is a little off topic for Jamie’s blog.   Perhaps we can cover this in a sepparate blog post.

            Cheers

            Corey

            (0) 
          2. Mark Prosser

            Ingo,

            Sorry to drag up an old post but I’ve just got back on to SCN and am playing catch up (real life getting in the way!)

            As a long time universe designer (v4 Windows 95!) I must say that the semantic layer is BusinessObjects’ biggest competitive advantage. I’ve had my doubts about data federation (almost a cheap/lazy option for those who cannot afford/be bothered to build a data warehouse). What sounds like an impressive option going forwards is to have a data warehouse sat on SAP HANA with a traditional (.unv) universe over it to get the full benefits of both the semantic layer and the performance that HANA offers.

            However, there are aspects of the IDT that appeal to me – I have always like the C*gn*s approach of publishing parts of the universe to different people rather than multiple universes. To be able to create that sort of thing over a single source (traditional DW) would be useful – almost a logical evolution of the UDT. It may have already been done, I’ve not seen it in BI4 yet!

            Has any consideration been given to SAP Rapid Marts? Extracting data from BW sources into a traditional DW sat on a SAP HANA platform may appeal, especially when bringing in data from other sources on to the HANA platform.

            Just a few comments/ideas for your consideration.

            Regards,

            Mark

            (0) 

Leave a Reply