In this blog we look at some ideas how how to get started writing a business case for HANA.
By Dr. Berg
Four Anchors for your HANA Business case
The first step in planning for HANA is to write a business case. This can be approached from several angles. There are clearly benefits in-terms of performance of the system, but to quantify the value of this in terms of money spent and Return on Investment (ROI) is often a futile exercise. A better approach is to write the business case from one of four value propositions:
- Total Cost of Ownership (TCO)
- IT Strategy
- Reducing Time and Effort of Delivery
- Improved Information Access For End-users
While tempting to argue all of these items in a business case, it is important to stay focused and provide a clear, cohesive and clear vision of why the investment in the HANA implementation is needed. There should also be clearly defined reasons and tangible results. So, be careful of taking a 'shot-gun' approach to the business case and hope something strikes a chord with the senior management.
Total Cost of Ownership (TOC)
It is important to acknowledge that there is a significant initial investment requirement for HANA, when compared to a traditional database and server strategy. However, when compared with the costs of maintaining, upgrading, patching and paying license fees for database, application servers, database servers, supporting connectivity and security in many platforms, as
well as comparing the costs of the daily monitoring of the multiple systems, the investment in HANA becomes more reasonable.
For example, the average Database Administrator (DBA) in the USA, is paid $78,239, according to the department of labor statistics, while the average DBA in Europe is paid around $64,000. In HANA there are no need for DBA's, resulting is operational savings. Also, the average BW developer in a company is paid approximately $65,000 to $85,000 per year, while some consultants charge as much as $225 per hour. These developers are building InfoCubes, Aggregates, BWA indexes, process chains and doing performance tuning efforts. Some of the InfoCube build, aggregate build and performance tuning work may not be needed with a HANA system.
The system also requires less development. For SAP BW, many of the InfoCubes may not needed in a HANA system. While, other objects such as developing aggregates (summary tables for reporting) are needed in neither ECC, nor BW. External indexing engines such as BWA are also not required. All of points to simplified system landscapes, reduce the number of integration points, and overall significantly reduced TCO of both the ECC system as well as the BW systems in an organization.
The fundamental value proposition of HANA lies in the technology landscape and that the need for increased performance. If we look at the evolution of hardware components relative to prices since 1990, we find that CPU prices have dropped and performance has increased so much that one can get over 6,000 times more processing power for the same amount of money.
Memory costs has dropped by a factor of 1 to 2,614, and addressable memory has increased by 248
, while network speed available has increased by up to 1,000 times. However, magnetic spinning disks have increased by only 124 times.
Actually, disks are 105 times slower compared to main memory access. This is the reason why the transition to in-memory platforms are inevitable. Transferring electrons to magnetic disks and moving physical hardware reader 'arms' are simply too slow. It has not kept up with the improvements of other hardware components.
If we remove the magnetic drives as the primary method for data access, we do not need a relational database. After all, relational databases were made to optimize and manage the access to organized file systems on hard drives. The business case for HANA can therefore be made on the landscape transformation required to enable the next generation of IT platforms.
Few would argue that the transition away from punch cards was not beneficial, but some companies kept using them for many years after better technology was available, resulting in slow performance, high support costs and limited choice in what is possible to accomplish. The same is true for HANA.
Organizations, can be early adopters and get early benefits, or be late adopters and try to live within the limitations of their older systems. The issue is that hard drives are at the end of their useful lives as providing 'instant' accessible data for large scale systems. Trying to make it work through re-design and performance tuning can be very costly. A better business case can be made for HANA based on technology trends and the long-term IT strategy.
Reducing Time and Effort of Delivery
Once a HANA system is implemented, it may have significant benefits of reducing development lead times.
For example, 20-40% of an ECC implementation may be used on developing Reports, Inter
faces, Conversions, Extensions and Forms (RICEF). For reports HANA simplifies the delivery by reducing the need to create reports that have to be performance tuned or optimized by ABAP code reviews. HANA is already performance enhanced. ECC Interface development is also faster, since we can connect directly to the system and retrieve data 'live' through database links instead of having to create asynchronous loads and file creations during nightly batch windows to reduce ECC system load/stress.
For BW, there are even more development benefits. For example, write-optimized Data Store Objects (DSOs) can serve as the staging layer and reportable DSOs can significantly reduce the need for InfoCubes. The BEx flag assures that the DSO can link to masterdata such as hierarchies, customers, vendors and materials. While, data transformation can occur during data loads into the BW system, or during data loads from one DSO to another.
Many will find these business reasons so compelling that their business case is written solely around these benefits as the core reason for their HANA implementation. Trying to quantify the benefits, BW systems customers may see as high as 15-30% less development time required, and ECC customers may see 10-15% reductions in development times depending on the complexity of their implementations. However, for some customers the benefits may even be higher.
Improved Information Access for End-users
One of the core reasons for implementing HANA is the improved access to data and information. Tools such as SAP BusinessObjects Dashboards have allowed companies to build operational dashboards in ECC and Business Intelligence (BI) dashboards in SAP BW. However the roll out of these to large user communities is rare. This is simply because the relational databases are unable to handle extreme high data volumes that are require
d to be summarized and consumed by thousands of users in a graphical format. HANA addresses this by freeing companies up to develop ECC and BW dashboards that improve data visibility beyond list reports and Excel interfaces.
HANA also provide companies with a platform that allows an increased use of ad-hoc query tools from PowerUsers and Authors. For example, in SAP BusinessObjects WebIntelligence users can create their own reports. Currently, some companies are reluctant to provide this capability to thousands of users without scheduling and pre-running the reports for performance reasons. Instead, it is common to see controlled availability of this powerful tool, thereby reducing the benefits BI Self-Service on a large scale.
HANA addresses this by making the database inherently faster and capable of handling high system stress with sub-second response times. This benefit can be defined under 'Option-Theory'. This theory states that the earlier a person is made aware of a change, the longer he has to react to the change. Since the time to react has increased, more alternatives and options can be explored, and better decisions can be made. Therefore HANA has an intrinsic value by simply providing more information to more people earlier and give them more time to react.
Many will write their business case for HANA simply based on data availability and performance alone and make a strong case why it should be implemented in their organizations.