Enterprise HANA is also known as Standalone HANA. We know that HANA is fundamentally a database which can enable a number of solutions. In this version of the product, though, SAP HANA acts more like an appliance solution; we have to look at the entire set of components all at once. We need to look at the hardware, the SAP HANA database, the specific software components that we'll be required to implement, the modeling studio, the BI tools, and the administration of SAP HANA.

Although the standalone SAP HANA version is called an "appliance" solution, keep in mind that this is not one fully contained plug and play solution. SAP HANA is not plug and play in any scenario and certainly not in the standalone version. When we purchase Standalone SAP HANA, we get the following tools:

We can't just implement this set of technology because we still need hardware, a BI tool or the intention to access data via Microsoft Excel, and a data integration tool. There is no requirement that the source systems (the systems where the data comes from) for our SAP HANA databases be SAP environments, but the implications of our choice of source system will determine which data loading tool we can work with and our options for those tools. Next, we'll discuss both the technical and skill requirements for a company implementing the standalone version of SAP HANA. We'll conclude the section with a high-level overview of what a project plan should involve.

Technical requirements

The components we require for the standalone version of SAP HANA will be the same as those that SAP HANA for BW would require; but with this version, we have to build everything from scratch. The architecture in this case looks like that shown in the following diagram:

The architecture in the preceding diagram basically enables us to create new reporting and analytical solutions for our transaction data. However, it also allows us to take an additional data set from those transaction systems that are timelier, more detailed, and have more volume, and bring them into the SAP HANA database.

Note

MOBI is the mobile version of the SAP BO reporting tools. A few reporting tools such as WebI and Crystal Reports can be accessed from mobile devices as well.

BW on HANA is the first significant step toward achieving SAP's goal of being a major player in the database space and having its transaction systems running on a SAP HANA database in short order. Running SAP HANA for SAP NetWeaver BW allows us to leverage what SAP has dubbed as the Massive Parallel Processing (MPP) capabilities of SAP HANA to query and report against the massive BW cubes and get results in subseconds. SAP HANA is much faster than the regular relational databases such as Oracle or Microsoft SQL Server. This helps in better performance of the data warehouse, and therefore the reports will run much faster. This version of SAP HANA is really the starting point from where SAP is progressing toward its long-term goals of using SAP HANA as the underlying database for existing solutions. By including SAP HANA in our SAP NetWeaver BW environment, we are actually removing the Oracle or DB2 database that we've been using all these years. In this scenario, we don't have to design everything from scratch as we do with the standalone version of SAP HANA. Instead, we simply replace our existing database with SAP HANA.

Technical requirements

The following diagram shows the architecture for SAP NetWeaver BW powered by SAP HANA:

We don't see much difference between SAP HANA for SAP NetWeaver BW and Enterprise HANA. In this scenario, we see that SAP HANA is now directly attached to SAP NetWeaver BW. This tells us that SAP HANA is a database, not a separate instance. It is not required to build new ETL layers or design a data model from scratch. We can use our existing BW models and structures. Those are all good things, but there's one big catch—there are version requirements for this level of SAP HANA. Because we are using SAP HANA as a database for our SAP NetWeaver BW system, this BW system must be of a certain version and level. The SAP BusinessObjects BI system must also be of a certain version and level. At the time of writing this book, we must be on SAP NetWeaver BW 7.3 (Unicode) with SAP BusinessObjects 4.0 (if we are using the SAP BusinessObjects toolset). The first thing we need to determine when assessing how quickly, easily, and at what cost we can implement SAP HANA for BW, is whether we need a system upgrade first. The next thing we need to look at is our hardware for our existing SAP NetWeaver BW system. It must be compatible with our new SAP HANA database. As with the standalone version of SAP HANA, we'll need hardware that can handle the needs and power of the SAP HANA database.

SAP HANA runs on the SUSE Linux Enterprise Server (SLES). These are big rack-mount systems that take up to eight CPUs and 80 cores to work. We can also basically stack these on top of each other for our scale-out options. We can purchase this software on the Internet from the big vendors, but we may also be able to negotiate a deal with our regular hardware partner. There are showcase systems that are of 100 TB.

A lot of RAM is required and should be matched to the CPUs. 20 cores allow 256 GB RAM, resulting in a maximum of 1 TB of RAM for current CPUs.

The trick to the quick recovery of a SAP HANA system that goes down—for example, due to power loss—is the ability to quickly restore the data via the logs.

The requirement for data storage is four times that of RAM. On all of the certified single-node configurations, there is cheap SAS direct storage. We need this so we can power down the appliance and perform actions such as backups. For multinode configurations, some form of shared storage is required—either SAN or a local storage replicated using IBM's GPFS (General Parallel File System) type of solution.

So, when we're looking at the hardware side of implementation costs and planning, we need to determine whether or not our existing hardware will meet the preceding requirements. We'll also have to make sure our hardware is compatible with the server versions that SAP HANA requires, which means we might have to look at a new series of hardware. If that is the case, the good news is that we'll need much less hardware than our current solution requires because of the compression ratios. Our hardware vendor can help us decide how much of our existing hardware can be leveraged for this new solution. We'll also need to plan for racking and stacking the box, just like with the standalone version of SAP HANA. On average, this will take a couple of days when we factor in the knowledge transfer to our existing support team.

After we have established SAP HANA as our database, we'll likely want to change a few things about our SAP NetWeaver BW system. We should first get rid of all of the aggregates on our cubes. Why would we do this when aggregates have been a necessary evil all along? Aggregates on a traditional, non-SAP HANA BW system are about precalculating certain results so that we do not have to spend time on it during query and report processing to compile and calculate those results. Aggregates deal with bad performance, or at least slow performance, particularly when our BW cubes and data sets start to get very large. After we convert our SAP NetWeaver BW to a SAP HANA database, we'll no longer need those aggregates to precalculate and make accommodations for system performance. As far as SAP HANA is concerned, aggregates are completely unnecessary overhead and add no value whatsoever. Getting rid of aggregates will also improve our data loading because we won't have to roll everything up to aggregates anymore!

Finally, we may wonder what we need to do with our BW cubes after we implement SAP HANA. We don't have to do much, but we do need to convert our BW cubes to SAP HANA cubes. This simple process allows the cubes to be stretched across the SAP HANA database in the new columnar format, which also reduces some of the overall size of the cubes themselves.