Skip to Content
Author's profile photo John Appleby

What is the best SAP hardware platform and why aren’t you on it?

One of the questions I get asked a lot in my role as Head of Technology is “what hardware platform should I be on for SAP?”. You might think that this is like any battle like Mac vs. PC or iPhone vs. Blackberry but the reality is there tends to be a straightforward answer for most customers. This blog looks to get you thinking about what hardware platform you ought to be on and how migrating might not be as hard as you thought.

It’s probably worth pointing out at this stage that I don’t have an allegiance and I’m not on the payroll of any vendor. I started my IT career in Mac OS, then Linux, then Windows Server and these days I spend most of my life on Windows 7 in Microsoft Powerpoint! I have recommended hardware platforms for many organizations running SAP, and have recommended just about every hardware platform that exists – for different reasons.

Misnomer #1: SAP is mission critical

If your SAP environment does real time sales order processing, linked into warehouse management and dispatch, where downtime of minutes costs direct money and where being down for hours means you will never recover those lost orders, you might consider SAP system availability be to enormously important to your business – and you would be right!

Most SAP instances, however, don’t fit into this category. CRM Sales, ERP Finance and HR shared services can all function without SAP for a few hours. It might be inconvenient but they will write things down on bits of paper and moan about computers. Even if you do have some mission critical aspects of SAP, not all of them will be!

When I push most CIOs and IT directors hard, they will admit that they could survive without SAP for a half day or more without significant business impact. Why then do we always talk about Highly Available environments and “Three Nines” – the ability to have <1h unplanned downtime a year.

The reality of the situation – which I have seen many times – is that the IT function don’t like the business complaining about downtime; so they try to assure much better SLAs than the business requires. And there is something in this argument because unreliable systems cause poor user adoption, which is the worst business case destroyer out there.

The question is though – if the business knew the cost of the difference between 1 day unplanned outage a year, rather than 1 hour – would they be willing to pay? Or would they just understand that the increased availability wasn’t worth it to them. The problem happens is when the business expects (either by setting of expectations or by customs and practice) a platinum service, and they get a silver service.

Misnomer #2: UNIX is better than Windows

This is a pretty common conception in the market which has persisted for some 20 years (note I’m not suggesting that the converse is true!). Let’s leave aside the religious fervour though, that underlies this sort of dispute and look at the facts. The fact is that a well configured, well maintained and well replaced UNIX environment is more stable than the same on Windows. No self-respecting technologist would argue otherwise and this is fine. If your business needs it and can afford the best environment, then that’s all good.

What’s more, Sun, IBM and HP UNIX systems provide the biggest and most scalable central instances. Forget about CPUs and cores, we just need to know about SAPS in the SAP world (for the purposes of this conversation). The big UNIX systems scale to some 200,000 SAPS – or enough for nearly 40,000 concurrent SD users. The big Windows systems scale to to 60,000 SAPS – or enough for 10,000 concurrent SD users. Note that these numbers are for a single instance – Windows can scale out rather than up, to much bigger systems, but 60,000 SAPS is enough for over 97% of the SAP deployments worldwide.

So once again if you need a system that big, or plan to – then you should go ahead and buy UNIX. The rest of us should consider the value proposition of the platform we are looking at. For example at Bluefin we have 29 SAP systems (and some additional associated systems) on 3 Dell pizza boxes running VMware, with some iSCSI shared storage on SAS drives. I’m told it would cost some £20,000 to replace.

Why did we choose VMware? Because we needed a low low cost of entry and support. We need more systems, not especially fast or scalable systems. But, we found that it was so good that we run our whole production environment on the same equipment – CRM, ERP, BW and EP. We don’t have unplanned downtime and we have a DR policy that we can enact in the timeline that the business requires.

If you are considering a hardware refresh then you should seriously consider what platform you really need. But – trying to convince yourself that you are a big and important company and therefore you should buy expensive equipment, is not a sensible proposition in this recessionary world.

Misnomer #3: The hardware platform really matters

If you believe me that UNIX is not always better than Windows then you may therefore be willing to consider that the hardware platform is not the most significant point in a SAP support environment.

In a real world example, I went to see a customer who had an outsourced arrangement for SAP with a third party on a UNIX platform. There were no SLAs, the equipment was 10 years old and out of support and the service was considered poor. Interestingly they had an excellent internal competency on Microsoft Windows and SQL Server for their non-SAP line of business applications, which had SLAs and are more business critical than SAP ERP.

What’s more they had already implemented some SAP systems internally on the Windows platform, meaning that they had Basis and DBA skills that were SAP trained. In this case, it made much more sense to recommend migrating the old UNIX equipment onto their internal Wintel farm, where they had excellent resources to maintain a homogeneous environment.

In another environment, we just migrated off Windows onto UNIX to keep all the systems in the landscape the same. Here, they had deep UNIX skills and wanted the availability that they believed UNIX afforded them.

In both cases, the key factors weren’t the hardware platform. They were simply TCO and people. In reality, the investment in human capital can far outway the investment in hardware platform. Systems which are well supported and maintained are more reliable!

Misnomer #4: Migrations are hard

Certainly it used to be the case that SAP Heterogeneous Migrations used to be hard. And let’s be clear – they’re not a technically easy task and SAP require people working on migration projects to be certified in that area. But, the major SIs all have teams with migration certified consultants and once you know the rules, a heterogeneous migration is not all that technically difficult.

However platform migraitons require a few things that make them perceived to be hard. First is a recent version of SAP – on the NetWeaver 7.0 platform – older versions of the migration tools are far inferior. Second is a properly maintained database – which isn’t that common in SAPland. Tables missing from the data dictionary are a problem, as are corrupt and missing indexes etc. Third is a set of prerequisites like r3load, r3szchk etc. being up to date. And fourth ihs a full unit, integration and regression test.

My feeling is that the lack of ability to get these things right early on during a project means that migration projects get a bad name and this perpetuates the myth. The early parts of the project take too long due to issue resolution, testing gets squashed and the project goes live with bugs.

It’s true though that migrations have a fairly substantial cost associated with them. However when put into the context of storage and server bills, the staff support costs of supporting multiple platforms and databases and thehardware support costs, it can easily provide ROI in a short period of time.

Add to that the benefits of doing a migration – for example being able to add in the Unicode Conversion for no extra technical effort, and the space savings of using DB compression (up to 70% less space on MSSQL), the cost justification can easily mount up.

Conclusion

I reiterate my first point, which is that I’m not  an advocate of one particular platform. However staying on one platform for SAP and having another platform for your other line of business applications seems to make poor sense these days. SAP customers shouldn’t be afraid to move platforms – especially in the context of modern migration tools and quality migration certified consultants.

Assigned Tags

      11 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Alberto Castillo
      Alberto Castillo
      The same happens sometimes when selecting what DB will be used in new implementations. Companies which have qualified personnel in one X brand RDBMS then say "this is SAP then we need to go with the biggest most expensive Y brand RDBMS on earth", just to keep an ERP system with 100 concurrent users.

      Author's profile photo John Appleby
      John Appleby
      Blog Post Author
      Too true. I reckon I could run 100 ERP users on my new laptop running MaxDB. Shame SAP don't make the SD benchmark available for sad people who would try to test that sort of thing!

      John

      Author's profile photo Martin English
      Martin English
      bet I could get it to 105 users, with enough tuning 🙂

      Which immediately leads into the real danger of this kind of thinking ....  If we start thinking realistically on behalf of the company, not only do we end up with less hardware and software to play with, you start thinking that the answer IS just get another stick of RAM, another drive &tc, rather than spending 6 weeks digging into the guts of SAP, the OS, the DBMS and so on.

      I mean that's 6 weeks of valuable learning you would have missed out on.... Who cares that you could have done something useful with that time 🙂

      Author's profile photo John Appleby
      John Appleby
      Blog Post Author
      Interesting - I'm going to sort of agree and disagree with that. It's true that when you buy £3000 pizza boxes to run SAP on, you are more likely to spend £500 on RAM than do some tuning.

      We've found that when you have 29 SAP systems on 3 such systems, the dynamic changes again. Saving 1Gb RAM is applied over 29 systems, so finidng generic ways to tune systems is really important in terms of the overall TCO. We find best practice on one system then apply to all 29 (for example the database compression I've been blogging about).

      You're right though in that there is less time to spend on tuning one system individually. Less is more, includes less of our time for more performance...

      Author's profile photo Martin English
      Martin English
      ... so the real answer is always "It Depends"  !!

      This is because there are so many factors that affect the customers choice; from their existing platforms, the corporate ego, the place of IT within the business, even the importance of SAP within the business - for example, compare the small companies where the IT department is only part of someones job; they tend run small simple SAP landscapes, and are more likely to solve performance issues by throwing hardweare at it. 

      At the other end of the scale are the examples you give, where you (generally) get a better ROI by automated monitoring and standardised tuning processes.

      I have even seen it come down to the customer's philosphy about operational v capital expenditure, where they are willing to spend $10,000 labor costs to avoid spending $5000 on capital expenditure !!!

      Now give me your watch, so I can tell you what time it is.

      Author's profile photo John Appleby
      John Appleby
      Blog Post Author
      Hiya,

      Again I agree to some extent because it really does depend. Unfortunately it also depends very heavily (especially with the big SIs) who their favoured vendor is and who will give them the biggest kick back! And many other factors which aren't very customer focussed. This is what I want to get people to think about moving away from.

      I've seen SIs (who will remain nameless) recommend 10x more expensive hardware than was required for the project, with availability requirements that were simply ludicrous.

      What I'm trying to encourage people to think of with this blog is that SAP hardware can be put into the IT strategy of any business - small and large.

      We are for instance a small copmany (150 consultants) and running 30 SAP instances would be a massive overhead if we weren't smart about how we provisioned them. We provision our SAP servers on the same farm as all our other equipment and use the same monitoring equipment.

      I think also that the global recession has helped organizations realise that $5,000 is $5,000, be it Capex or Opex. Which can be no bad thing!

      Regards,

      John

      Author's profile photo Former Member
      Former Member
      Hi John

      Good points well made.

      It goes to show that clients should always challenge what they have and where they want to go - standing still can cause more problems in than a client may actually consider.

      Author's profile photo John Appleby
      John Appleby
      Blog Post Author
      Cheers Mark,

      It's interesting - my experience has shown that it generally seems to require a "significant event" for people to change SAP hardware platform.

      I'd like to change some of that thinking because I tend to think it's all about the cost/risk/benefit triangle.

      And mostly in these hard times, it's about cost...

      John :=)

      Author's profile photo Martin English
      Martin English
      Its not just the client who should challenge the SI or the in-house IT; they should also be challenging the client, with questions and ideas about how implementing different could save time and money, whether its new SAP technology and tools, existing SAP technology and tools that haven't been implemented 'here', or even stuff that (at first glance) appears unrelated to the customer's system or business.

      However, the client can have some problems dealing with this.  One is a highlighted by one part of a major customer of mine; they are in the steel business not the IT business, so if they get data they need, they're OK (I've sometimes suggested that their attitude is "The blast furnace gets relined every 30 years, we'll upgrade SAP when that's done").

      Of course, things aren't that simple - the real issue is that SAP is only one part of their IT.  That particular customer has some of the most sophisticated control systems in the world - they really just have too many opportunities to spend on technology to assist the business, and the SAP systems lag behind.

      It's an example of where you need to know more than just the technology, where you have to realise that there's behind your large SAP implementation, there may be an even bigger business.

      Author's profile photo Former Member
      Former Member
      [quote]
      So once again if you need a system that big, or plan to - then you should go ahead and buy UNIX. The rest of us should consider the value proposition of the platform we are looking at.
      [/quote]

      You seem to compare UNIX on RISC with Windows on Intel, but this ignores many perfectly relevant options.  If you want UNIX, you can run that on Intel as well, for example, Solaris on Intel, or Linux on Intel.

      There is no need to choose only between 'big systems' or Windows.

      Additionally, with respect to the statement:

      [quote]
      The big Windows systems scale to to 60,000 SAPS - or enough for 10,000 concurrent SD users. Note that these numbers are for a single instance - Windows can scale out rather than up, to much bigger systems, but 60,000 SAPS is enough for over 97% of the SAP deployments worldwide.
      [/quote]

      The SAPS rating is based on hardware, not operating system.  So, 60,000 SAPS (it's really more like 57,000 SAPS) applies to any operating system running on the same hardware (including Linux and Solaris on Intel).  And note that this hardware is not the Dell pizza boxes you refer to running, it's an IBM x3850 X5, which, configured according to the benchmark (4 sockets/32 cores/256GB RAM) will cost you close to $100,000.  Very near to the cost of a UNIX/RISC server.

      So that sort of blows the whole argument, that it's either "big UNIX hardware that is very expensive", or "60,000 SAPS of Windows, which is cheap", doesn't it?

      Author's profile photo John Appleby
      John Appleby
      Blog Post Author
      Hiya,

      The SAPS rating is a combination of hardware, OS, DB and tuning, which is why there is some variance on the same tin. But of course the same hardware is broadly similar across software variants and it is just as valid to run another OS on Intel tin.

      There are so many variants and choices, and the purpose of this blog is to get people thinking about what is best for them. The section should have been called "platform a is better than platform b" but I wanted to provoke thought.

      Hope this blog gave you some food for thought.

      Regards,

      John