Josh Greenbaum posted this blog making a case for HW independence for SAP. http://insiderprofiles.wispubs.com/article.aspx?iArticleId=6265 . Josh needs no introduction, and I am a huge fan of the guy. But on this topic, I respectfully disagree with him.
I do agree with Josh in that the Apple analogy is not exactly applicable to keep HW and SW integrated for SAP. Jobs had to do it on the front end and hence that was a good option. SAP’s work is in the data center, and not facing the customer. So the customer experience like Apple is not applicable.
Hardware agnostic software was a great option when hardware was pricey, many years ago. Hardware does not command such a huge premium anymore. And consequently, software companies need to re-evaluate their strategy on what they will and will not do in their architecture. Being agnostic worked for last 30 years for SAP, but I seriously doubt if it will be the same even for the next 10. If pushed hard, I might go on a limb and predict that SAP will do something about HW in 3 years or so.
SAP was agnostic to databases and operating systems too – and now that they bought Sybase and have invented HANA – is it reasonable to expect them to be agnostic to Databases going forward? HANA works only on SUSE Linux, and not AIX or Windows or anything else. And Steve Lucas already pronounced that he will get SAP to number 2 position in database world by revenue by 2015 – which is 3 years away. Will that happen by SAP being DB agnostic? no – SAP will go against Oracle, IBM and MS at every opportunity. It is the smart thing to do.
Ok back to hardware – if you look at HANA, it is the hardware advances that made HANA possible today, more than software. I have seen jibes thrown along the lines of “throwing hardware at the issue” as if HW is a bad solution. HW innovations, as I mentioned before, usually keep SW innovations trying to keep up. If RAM did not become cheaper, and multicore processing did not happen – would HANA have happened?
Currently SAP supports multiple vendors for HANA hardware. For a 1.0 product , it is probably ok to do this since nothing do-or-die will run on HANA today. But as HANA matures, SAP will need to make HANA work extremely efficiently for OLTP loads, and maybe even “real” big data (the petabytes and upwards size). At this point – will SAP try to optimize HANA for seven different vendors? or will it choose one or two? or will it just introduce its own hardware that is more optimized than every one else’s ? I am betting on the latter. SAP might never completely get rid of partnerships with other HW vendors for other reasons – but if HANA is where SAP is betting the farm, then I see no way SAP is going to remain HW agnostic in mid to long term.
Also, SAP now wants to be a cloud player – maybe even a leader as time progresses. Will they buy a lot of HW from IBM and HP for that? or will they do their own HW? Since all cloud apps are eventually planned to run on HANA – this is an even stronger case for SAP to stop being HW agnostic.
I think Oracle is VERY smart in keeping HW and SW integrated. Just because SAP competes with ORCL is not a good reason to say stacks are bad. Oracle is a very good and successful company too. Going forward, I do expect to see a lot more similarity between ORCL and SAP in how they create solutions. To retain leadership, these companies will need to lead with both HW and SW.
And Vijay Says... 
It would be fun to see how HANA fits itself in the future wave of Hadoop (distributed processing). The future certainly is for bigdata which works on commodity hardware. Every tool vendor has their own products/database made available to work in bigdata/ unstructured data space. If HANA has to compete with these tool vendors, hardware agnostic approach is the one which will allow SAP to breath. By the way, not sure how HANA takes care of unstrctured data as of now.
LikeLike
We should hear some news about this in SAPPHIRE from Vishal Sikka – that is what I am hoping for.
LikeLike
@Ethan needs to take a look at the supported hardware platforms for HANA. Very specific chipsets are supported for specific computational capabilities.
LikeLike
Hi Vijay, as usual, a very thoughtful post.
I put my own thoughts on the subject at my blog.glocalings.com. Some of them are very similar to the ones that you have put in here.
I assume that SAP HANA or some of its future avatar is available truly as appliance – say a fridge or an iPhone, metaphor. It would follow its success would depend on number of applications available on it.
Enterprise IT being what it is, I can see both formats, Clouds and Stand-alone, call it on-premise if you wish, need SAP to take some form of ownership for the BOX- Plug and play appliance. I guess this is not easy, but at the moment, betting everything on SAP HANA as standalone database sounds a bit too risky for SAP. And from what I have heard, such as idea-space etc, I would think SAP is very well aware about those risks.
The changes, as you rightly pointed, out is in hardware. Technology companies are reacting to those changes. The ones with most effective reaction will stand to gain from this shift in hardware world.
By no means one can guarantee that the business application world will not dramatically change. We can be sure some smart guys are working very hard. It is both an opportunity and challenge for SAP (and others) because this one is big “who moved my cheese” moment for SAP.
LikeLike
If you are right, Vijay, SAP stands to lose a lot of credibility. It’s tough to deride vendor stacks for so loud and so long, then start selling stacks yourself, especially if a closed stack is your only option. What will be next? BusinessObjects will only report off of data in BW?
LikeLike
I don’t know if they will lose credibility, Jamie. As much as people seem to hate ORCL, have customers left them for being a closed architecture? As long as business problems are solved, I feel customers will not worry.
LikeLike
I didn’t say they would lose customers, just credibility. 🙂
Of course if you compare Oracle’s SW and HW results with SAP’s SW only results from last quarter, it’s easy to see why one would want to emulate Oracle.
LikeLike
SAP should support multiple platforms but should not be entirely “platform agnostic (HW or SW)” – that’s a support nightmare for customers, partners and SAP alike. As a customer, I’d want to know that it “just works” and I wouldn’t want to bear the cost of the integration/testing on new HW or OS combinations. That’s how the ERP platform works today, and that’s for good reason.
It would be advantageous, however, to offer a set of appliances (HW + SW) for something like HANA. Why do I use “plural”? Because not every customer will have the same precise requirements or expectation of high availability, performance, sizing, etc. – it’s essential that SAP take a fast food (or EC2) approach and offer small, medium, large, and supersize.
LikeLike
If I buy an appliance – say a fridge – do I really care who made the compressor, and who made the coolant? No – I just want to know the fridge will do everything that I expect it to, and that there is one number to call to fix things if something went wrong.
LikeLike
Exactly. The one a$$ to kick model matters to enterprise IT purchasers, given the risk and potential cost of stuff not working.
LikeLike
Vijay,
I respect your opinion, but I think Josh is right and I disagree with this blog. Or perhaps I just don’t follow the logic. I don’t see how merging hardware and software at a deep level is advantageous to Hana or how it is strategically advantageous to SAP.
You say that hardware innovations have made Hana possible, but the two innovations you list (cheap memory and multi-core) do not require the sort of deep integration of hardware and software that are described here.
As far as I can tell, the sort of hardware Hana requires is not particularly special. Hana exploits specific processor instruction sets and cache configurations, so it needs specific processor parts, but aside from that the hardware configurations are purely commodity with some exceptions (which will hopefully go away) in the scale-out cases. SAP could release a spec for supported hardware configurations and performance characteristics and then let the vendors loose. Currently, SAP is blessing certain configurations from certain vendors, but I would expect that to become a more open approach over time. At least I hope so.
Why do I hope so? Because, like Josh, I believe that going for a tightly coupled hardware/software strategy would be a strategic mistake. There are many reasons, but here are a few:
1. SAP has very little experience in hardware.
2. Hardware, as you point out, is cheap compared to software and has much lower margins, so the impact on margins would be negative.
3. I don’t see the technical advantage of deep integration over specs and certified configurations, in the case of HANA.
4. It will create a higher cost of ownership by forcing those who wish to use Hana to introduce heterogeneity into their hardware vendor and support relationships.
I worry, because I see SAP going in the same direction you do. If SAP releases versions of its Business Suite software that only run on Hana, and these versions diverge significantly in functionality from the non-Hana versions, then SAP will be going in the same direction as Oracle does when Oracle requires its applications to use the Oracle database. This would divide the customer base and create massive lock-in at the expense of future market share. In short, it would be a defensive and anti-innovative move.
Obviously SAP is struggling with its hardware strategy for Hana. Based on what I am hearing, customers are experiencing a fair amount of pain having to coordinate between SAP and a hardware vendor in order to buy Hana. My suggestion to SAP would be to avoid getting into hardware itself.
Instead, I would suggest doing the same thing that SAP has done with databases: sell Hana in two flavors, one with OEMed hardware, and one where the customer brings its own hardware. The first case is perfect for smaller customers that don’t have a major relationship in place with a hardware vendor, just as smaller customers buying SAP ERP will often use an included OEM database. The second case is perfect for larger customers that want to manage their own hardware relationships, just as they manage their own database vendor relationships through enterprise-wide licensing schemes.
Either way, I don’t see tight coupling between Hana and the hardware as the answer.
Cheers,
Ethan
LikeLike
Thanks for chiming in with your views, Ethan.
Supporting 7 different HW will be difficult for SAP – it will dilute their development efforts. They did the right thing by supporting only one OS, and 2 processers(both IA based). If SAP is serious about clouds and building big data centers – wouldn’t they want to do their own custom HW like Apple or Facebook? And if they do – why would they want to keep supporting all the other HW vendors? They could as well invest that money on some other innovation.
They might end up with the model we are suggesting where they do a bit of both – an OEM HW + all the other HW vendors. Guess we will see soon enough
LikeLike
Hmmm, I just don’t see it. SAP’s not currently tailoring Hana to any specific hardware platform as far as I can tell. You install the same software on all the hardware platforms. The tailoring is to the processor and the OS. It seems to me that the integration pain between SAP and hardware partners is logistical, not technical. Maybe I’m wrong about that, but I’d prefer to see some arguments for why it would be technically beneficial to target Hana to a single (commodity) hardware platform and I’m not seeing them. I can’t think of any myself.
LikeLike
And hence SAP should buy HP!
KK
LikeLike