Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

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.

11 Comments
Labels in this area