My initial idea was to write an update for each day after the session – but after the first day, that plan did not work out. So here I am finishing this post in India., while fighting jetlag. Day 2 of SAPPHIRENOW was a lot more chaotic for me than Day 1 for sure. The day started with Jim Snabe’s key note, including Lars Dalgaard’s presentation on cloud at the end.
Right off the bat – Lars brings a kind of energy to SAP that is usually only seen with Bill McDermott on stage. Lars came across as confident, positive and strong in my opinion. I was also mighty pleased to hear that SAP and SuccesFactors implemented all of each others cloud solutions internally in few months. I had a chance to meet Lars with my blogger buddies. He is an amazing guy with a laser like focus on details. Jon Reed did an outstanding job in that meeting, and came in well prepared with a comprehensive list of questions for Lars.
Here are some highlights of what we learned
1. Lars had a chance to kill Business By Design if he wanted to. But since he thinks the only missing part for the product to be succesful is a good go to market strategy, he decided to not kill it.
2. There is an opportunty for SI partners in cloud space, and he is looking forward to working with them.
3. He thinks HANA is the best thing that could have happened to cloud portfolio, and he will be using HANA extensively in his products.
4. Engineers from SAP and SFSF are being integrated now
As expected, Jim did a solid job on his keynote.It started with a video on SAP history. Funny part for me was Josh Greenbaum saying R/3 was an open platform or something such, and the guy sitting next to me watching the keynote choked on his coffee. So things started on a light note for me.
While BByD will continue to exist as a suite, parts of it will also be offered as smaller point solutions – like for Finance. I am on the fence on this strategy. SAP is a late entrant to the cloud market, and needs a strong differentiating message for its cloud portfolio. I think they could do one of two things – or even both.
1. Create horizontal solutions which cover large number of customers – for example, Collections and disputes management in cloud, with integration to BByD or On-premises FI-AR.
2. Vertical solutions for SAP’s industry solutions that cover the business partner network – like say dealers for automotive, or insurance agents for insurance companies.
I am looking forward to see how SAP differntiates in cloud going forward.
Jim also envisions the world will move in a few years to putting all the data in main memory. I beg to differ on this as well – I seriously doubt disk will get replaced soon. Later,I was happy to see Hasso’s vision is that of hot storage on main memory, and cold storage on disk . Of course, Jim could be totally right – and I am looking forward to seeing how this will unfold in the market with customers. I did a gut check with a few that were in the convention center – and none of them seemed to think all data will ever sit in main memory.
After the keynote, in a private blogger meeting – Jim discussed the future of HANA. BW on HANA is the next big thing on his mind to get traction in the market. I readily agree – since it is low risk and high reward for customers. Also – most BW systems are small, and SAP already has proven that HANA works with 100 TB, when the largest BW instance in the world is only 80 TB.
However, there is a big issue in making this work – and that is the sales enablement. BW has 17000 or so installations worldwide. If SAP has to hit 10% of the market in 2012 that Jim thinks they can hit – they need to close more than 10 deals every working day for the rest of the year. As I have mentioned many times before, the partner ecosystem has been largely shut out of HANA so far for many reasons. It is getting better now, but not to the extent that between SAP and Partners, 10 deals will be closed every day.
However, when we met with Bill McDermott – he did not define the challenge as 10% of existing market. His minimum goal is to double the revenue they got last year out of HANA and Mobility. That I think is an achievable target, and will not need 10% of the BW instal base to be converted. Bill did clearly mention that it is a bare minimum goal, and that he fully expects to beat that target.
Another difficulty with expediting the HANA sales process, according to SAP executives like Lucas, Enslin and Snabe, is the availability of hardware in quick time to do POCs. If SAP can put HANA on the cloud and ensure data security, this is a problem that will go away quickly. Customers can migrate HANA from cloud to a physical box, as HW gets delivered. Hacking the installer to put it on cloud is very easy – so hopefully this stops being an issue.
Jim did mention something that picked my interest a lot. His vision is an 8 day migration of a BW HANA system. Apparently SAP is working with some SI partners on migration factories where a customer can ship BW systems to be upgraded and sent back. I am not convinced this is workable in the field.
1. Most customers run a 3 system landscape for BW, and each will need to be upgraded.
2. Shipping them to India is not going to be easy due to security concerns on data
3. Very few of the 17000 are on 7.3 version which is needed for BW on HANA. It is not realistic to have an 8 day upgrade to both 7.3 and HANA.
4. Migration directly depends on quantity and quality of data in the system. If the system has huge data, and customer only has a short weekend window to migrate the data in production- it will be a challenge. Either they will have to archive a lot of old data, or they will stop migrating and just stand up a new system with just high value reporting.
But Jim’s vision is the right one to have despite all of this. If HANA is to become a volume play for SAP, they need to find a way to accelerate sales and implementations tremendously.
Another interesting couple of tid bits while we are on the topic of BW on HANA
1. John Appleby found out from one of his meetings that 3.x objects do not need to be converted for BW on HANA. They will work ok, but will not have the ability to take advantage of HANA. I did not know this till John told me on Tuesday. SAP could do better with communications.
2. How will BW (and eventually Business Suite) enhancements work in HANA? The enhancements are today done in ABAP server, and typically uses a row by row processing technique to process data, as opposed to set processing. So essentially they cannot make use of HANA’s power, and will become a bottleneck in performance. I asked this question to Hasso and Vishal on Wednesday afternoon, and they did not have a clear answer. Rewriting them manually into some kind of stored procedure is not easily accomplished due to volume of enhancements in a typical ABAP system. I am waiting for SAP to give us an answer to that.
We also spent considerable time with Sanjay Poonen, who heads D&T, Mobility and Apps. Sanjay is big on mobility ever since he took over that portfolio, and is very optimistic about SAP’s chances. He took our feedback to heart last time and was instrumental in getting developer access sorted out to a great extent. Afaria on cloud is a tremendous value proposition for SAP if the price point is really low. On Apps side, they do need to woo many more developers to make it work. But with open technology partnerships announced for Sencha etc – SAP has a shot at making money on mobility.
In my mind – for SAP to succeed in cloud and mobility, they have to immediately address one thing. That one thing – often ignored – is APIs. SAP needs to be good at APIs if it has to attract non-SAP developers to work on mobile and cloud solutions. And it is an easy target for the existing couple of millions of developers in SAP ecosystem. It is low hanging fruit in my opinion, and ripe for plucking. If I might go on a limb and make a suggestion to SAP – that would be to let Craig Cmehill form a team and evangelize that with the developer community. He is already a rock star with a big fan following, and will be readily able to hit the ground running. Of course, some one at SAP needs to check with Craig first to see what he thinks of this 🙂
Day 2 was also a big party night – starting with Global Comms reception. After spending a few hours there, and catching up with several mentor buddies , I skipped over to the IBM party a few doors away. I was amazed to see how many customers were interested in Mobility and HANA and wanted to start projects on it. And then we walked back to Hilton at the convention center late at night, led by Mike Prosceno. There is an unconfirmed rumor that we passed the peabody hotel twice in the process !
11 thoughts on “SAPPHIRENOW 2012 Orlando – Day 2 – Cloud, HANA and Mobility”
On your comment on APIs, agreed but not just mobility and cloud but in HANA as well. Exposing some aspects of the technology only promotes innovation. For e.g., exposing some of the monitoring APIs in HANA would result in some pretty cool end to end monitoring dashboards and 3rd party integration. Cloud, by design, will have APIs because of it’s integration requirements with on premise devices. On mobility, I agree, if they can open up some APIs on the Sybase platform (as an example) that would great. For e.g., I was thinking of building a MBO code generation for Adobe Flex (action script) at somepoint but that is not possible because Sybase hasn’t exposed it event though MBOs are generated using XML definitions and structures.
Thanks KK – I did not mean mobile and cloud exclusively, but as first priorities given current focus.
I don’t have additional thoughts; I can’t think of anyone other than Craig leading API efforts. Good call.
Good summary. Two points come to mind
1) You say enhancements are going to be an issue. But even standard SAP code (for e.g the Pricing BAPI) has the same issue. Granted customers will have to spend additional dollars to rewrite enhancements but that’s the nature of upgrade business when something like this happens. Are you saying customers should consider the cost of rewriting enhancements in HANA projects? If yes, I agree. Or, am I missing a point?
2) Regarding BW on HANA, seems to be a logical choice for new customers. For upgrades, would it make sense to do side car to start with and then holistically think about moving to HANA stack after the business suite on HANA is out. A lot is this depends on how new is the BW hardware and on what DB customers run their BW systems. Some of them may want standalone HANA for low risk but still benefit from the HANA innovations. What’s your thoughts?
1. My point specifically is that there is no framework today in sap enhancements to push abap enhancements in abap to Hana layer. I hope this gets changed with NGAP
Nice job on blogging 4 days later. Few thoughts:
1) BW on HANA – as you know – needs BW 7.3. In order to upgrade BW system to 7.3, 3.x objects would require conversion and 7 security implemented. Are you/John saying BW can be upgraded to 7.3 without converting 3.x objects?
2) 3.x or 7.x objects – don’t matter – wouldn’t IMO take advantage of HANA anyway if one just migrates BW from disk-based DB system to HANA. When you migrate, you’re just migrating everything 1 to 1, cubes, DSOs, PSA, Master data etc. Of course, data will now reside in memory instead of disk. To that extent, yes, BW on HANA would be different. I read this somewhere either from SAP documentation or webinar. In order to take advantage of HANA, one will have to start replacing cubes and other objects with views. Conversion of views is a manual process, not a part of migration.
3) Don’t believe any one demonstrated a working 100TB system. All I saw was just a data center holding 100TB HANA. How much data was in that system and how many users were using it? This is not a criticism but 100TB requires more time to mature; don’t believe we’re there yet. If someone disagrees, that IMO would be a great news for SAP-HANA. Oracle should really be concerned. Of course, there’re other issues with SAP-HANA as we discussed via tweets but they’re just unknowns for time-being. If not SAP, someone else will crack it sometime in near future. All someone needs is time to resolve complex processing requirements in OLTP environments, concurrent users, HA (that demo was very poor job from SAP), DR etc. HA, DR etc probably are not show stoppers. Politically this may not be right thing to say; but unfortunately this would take time to mature, not 10s of years but few years IMO.
4) 80TB system should really be 8-20TB on HANA – of course depending on who you believe. Don’t know this reduction takes place immediately after migration or customers would need to do something? So regardless of whether 100TB system is practical or not, I believe SAP-HANA may already be able to support the largest SAP-BW customer.
5) Finally on 10% – whether SAP hits 10% of BW customers or just doubles revenue from last year on HANA and mobility doesn’t bother me as SAP consultant. However if their goal is just doubling the revenue from last year, I would really be concerned as share holder. HANA was GA only from June; BW on HANA from Nov. Mobility was still evolving in July 2011. SAP could only set goal of doubling the revenue on HANA and mobility from last year!!!! :((. They were either evolving or available only part of the year in 2011.
10% as you said is not practical either if SAP meant the number of customers. If they meant 10% of total size of all BW systems, then this goal is probably accomplishable.
Finally thank you for taking time to write this blog.
ad 1) To be precise: BW 7.3 can run 3.x data flows. It is not mandatory to convert them. They even work in most situations with the new HANA-optimized infocubes and DSOs. You need to move to the authorization objects introduced with BW 7.0 more than 6 years ago. There is a conversion tool that converts 3.x to 7.0 authorizations. The output is not the same as if manually crafted but it works. So I don’t see obstacles on that end.
ad 2) BW leverages HANA specific features to a large extent. I even dare to say that for more sophisticated analytic queries you will find it hard to beat the BW generated access (even when manually coded) as BW generates a series of (partially inter-dependent) views that constitute the sequence of OLAP calculations. It can then combine the partial results to form the result.
Infocubes and DSOs are not replaced by views but there are HANA-optimzed versions for each of them. There are conversion tools that convert a classic infocube to a HANA-optimized one and a classic DSO to a HANA-optimized DSO. For example, a 500M facts customer infocube was converted in a few minutes. It’s now big deal and fully automatic.
The statement that everything gets faster because it simply sits in memory is misleading. Then it would have been sufficient to put a standard RDBMS on a machine with lots of RAM rather than creating a new DBMS like HANA. Also: if BW had not been adjusted to HANA it would not see the dramatic performance improvements that you actually see with BW-on-HANA, especially the load performances.
I hope that clarifies some of your speculation.
Thanks Thomas – great explanation
Thanks for providing additional details.
1) Not sure why I thought the conversion of 3.x to 7.x data flows was mandatory. I reviewed my notes from EIM207 session and it is consistent with your response.
2) I knew BW queries wouldn’t be faster just because everything sits in memory; however I didn’t know HANA-optimized ones for DSO and cubes would really improve the performance significantly. I’ve seen/heard comments that migrating (BWA based) BW systems to HANA based one wouldn’t show significant performance improvement. Would you agree with this statement – that migrating BWA based BW system to HANA would show some improvement but not significant – in general?
As always, your response is to the point with no ambiguity and meets Bill M’s one of criteria for success: Simple (speed and personalization are other two).
Thank you once again,
Hi Vijay and Bala,
You are welcome. I really appreciate when you raise these things. I had been really surprised when finding out about the misinformation around the 3.x objects while talking to John. This is certainly somerhing we need to improve.
It is an unfortunate by product of several people at SAP trying to talk about Hana , irrespective of their own knowledge about it .