In This video blog we look at five steps that helps you automate many of the tasks of moving SAP BW to HANA, including sizing, pre-checks, cleanup, ETL automated checks and HANA migration options. By Dr. Berg
Many organizations that are currently using SAP BW and BI on relational databases are struggeling with the first steps in planning and executing their BW to HANA migration efforts.
In this video blog we look at what is new in the 2nd edition of the SAP HANA book from SAP Press, and also dives into the new automated programs that can assist you in your migration project with practical advice and examples.
5 key steps on How to Execute your BW to SAP HANA Move
(select high resolution if you are using a big-screen and turn on sound).
Meanwhile, I am preparing a demo with 420+ million rows with 3 dashboards, WebI, Analysis, Crystal Report and more that I will be sharing on this blog later this week after Sapphire.. Stay tuned :-)
On Jan 10th, SAP Announced that SAP ERP can run on the in-Memory Platform called HANA. What does that mean to BW? Is data warehousing dead? Can we simply Report on ERP instead and skip data movement, DSOs, infoCubes, modeling and the extra hardware? In this blog we look at where we are now and what it may mean for the future. By Dr. Berg
ERP on SAP HANA
As of January 10, 2013, SAP said it supported the deployment of their ERP Business Suite on HANA. The solution requires enhancement pack 6 for SAP ERP version 6.0 and ABAP AS version 7.4 which was made available at the same time.
This raise many questions about the future of traditional On-Line Transaction processing (OLTP) and separate On-Line Analytical Processing (OLAP) such as data warehouses. Is there really a need to separate the reporting from the transaction processing?
The answer depends on the time horizon you are planning on. In the short run, there are simply too many valuable models in SAP Business Warehouse (BW), Advanced Planning and Optimization (APO), Business Planning and Consolidation (BPC) , Integrated Planning (IP) and all the other DW based tools to throw them all away. However, these tools also has several Achilles heels; they are not true real time and require separate infrastructure and data movements.
But, SAP Makes a Bold Statement...
Two days ago, SAP's Vishal Sikka wrote in his blog: “with the collapse of OLTP and OLAP in one platform there is a massive simplification on the way” . There is naturally a lot riding on this vision and a substantial amount of development must take place to organize the data in the OLTP system in a way that is designed for reporting.
I can see that some operational version of this can be done in the future through separate HANA reporting tables in the ERP system (much like what we used to have with EIS, SIS, LIS in the early days of ERP), or by creating views on the data using HANA studio, XS or other tools.
Dr. Berg Speculates
However, for the foreseeable future, I believe SAP BW provides an integrated platform for model driven analysis on data that needs to be preserved at the time of transaction, integrated with external data, and which contains the corporate ‘memory’ of what happened in the past. So, the vision of an integrated BI and ERP system on the same platform is just that; a vision. Technically, it is not possible to install BW and ERP on the same HANA system today.
On the other hand, for real-time operational reporting the ability to move your SAP ERP system to a HANA platform allows you to execute transactions faster, reduces the database size, simplifies the administration (really!) and provides new analytical capabilities inside the ERP system that simply was not possible before.
Some Early Examples of ERP on HANA Analytics
An example of these is the new abilities is found in the SAP Business One Application, version for the HANA Platform. In this ERP solution, SAP included embedded contextual dashboards in the transactional screens.
This include graphs for items such as most purchased products by customers, credit dashboards, real-time inventory trends, vendor analysis, cash flow forecasting, and much more. SAP has also announced that they plan to develop even more of these types of applications in future release (so this may be the future of operational real-time analytics).
There is a lot of people wanting to skip the model driven approach and go straigh to ERP for analytics and BI. For those it is important to be reminded that there is a reason why the models were build in the first place. It was to simplify reporting and provide a business view to cleansed, integrated and often transformed transactional data to provide meaning. This is not found in a transactional table. So we may get there as Vishal stated in his blog, but there still along way to go..
SAP BW is still an integral part of the data warehouse landscape for many years to come, and with HANA there is even more benefits to keep it around...
In this blog we look at the details of the new iPad and HTML-5 support in SAP Dashboards in service pack-5. We look at limitations, our experiences in ComeritLabs and what is planned for SP06, SDK and BI 4.1.
By Dr. Berg
SP-5 for iPad Mobility in Dashboards
As you may know SAP's dashbaord tool has received some updates in ServicePack-5 that was released a few weeks ago. Most importantly was the support for mobile dashboard elements for deployment using HTML-5 on non-flash compatible devices such as Apple's iPad.
There are currently a limited number of mobile dashboard elements supported, but they are the most commonly utilized elements. This means that many of your current dashboards can be converted to mobile with minimal effort. SP-5 also use a new mobile only preview mode. This shows dashboards as they will appear on the iPad before your deploy them. We found very helpful during our devlopment and design efforts. In addition to these items, all standard data connections work on mobile dashboards including BEx and Universe connections.
Figure 1: Supported Objects in SP-5 for Mobile
This week we took a client's flash based dashboard and re-hosted it using the new mobile solution in less than 8 hours, so it can be done fast...
So What is Missing Today?
Some important things to note about the current SP05 are the exclusion of some key elements such as the lack of a prompt selector. There are also no calendar controls and HTML text for labels isn’t supported. Connections in the Data manager are only currently available in the pre-query panel and only the “Nova” theme is supported on mobile devices. We also have no support for the prompt selector for hierarchies in SP05, nor is the 'reset' and the 'save senario' available.
Another major component that is not currently available in SP05 are spreadsheets tables, making tables harder to make. However, SAP supports the use of the URL button in mobile dashboards, so we are making progress. The trick is to use the features supported today and find workaround of those missing as of now.
When converting we found that the new “Mobile Compatibility” tab displays suggestions and warning for optimizing dashboard components for mobile deployment.
Figure 2: Warning messages when converting dashboards to Mobile
Warnings as in this picture, simply means that there are better ways of doing this. The dashboard still works. Error messages means that it will not work. We found this featrue to be very valuable.
We also liked the fact that mobile specific text fonts are marked with “iOS 5+” to show which fonts will work best on our dashboard.
Figure 3: Supported Fonts are Identified easily:
Our Mobile Dashboard and iPad Experience
We at ComeritLabs utilized these new mobile objects this week to create a set of mobile dashboards. We found that it is possible to convert existing dashboards relatively easily to the mobile platform. However, mobile deployment is not yet supported until SAP’s BI Mobile app is version 4.4 is released this month (4.3.11 is the current release).
While we found that our iPad dashboard's to execute fine, we noted that Internet Explorer have a few limitations due to the current HTML-5 support. This is important since future dashboards may be deployed simultaneously to both mobile and BI 4.x Launchpad environments. However, we expect all major browsers will have 100% support for all HTML-5 items in a very short time, and as of now that has not been any show-stopper for any dashbaords in our test. They simply works great on an iPad.
The Future in SP-6, DSK and BI 4.1
While there is no new mobile features planned for dashboards in SP-6, there is a lot of activity with incorporating an SDK in the mobile solution for dashboards.
Currently, SAP is working with Antivia, APOS, Centigon Solutions, and Graphomate in Germany on POCs for mobile enhancements using a SDK that may be incuded in the BusinessObjects 4.1 release (scheduled for the second quarter 2013). If this gets included, there will be significant step to sharing objects and it will open up a whole new set of mobile capabilities that can be added in a short timeframe.
I will keep updating this blog with more demos and screenshots as soon as I obtain a client's permission and SAP's new BI Mobile app is version 4.4 in a few days.
But the short story is that SAP is making mobile headways in a very short timeframe.
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)
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, Interfaces, 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 required 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.
There are very little in-terms of practical published material on HANA, except for some training books and some PowerPoint and blogs. However, this is about to change with the new HANA Introduction book from SAP Press.
by Dr. Berg
The HANA Proof-Of-Concept and Test
Working together with our editors at SAP Press, Penny and I decided to cover both the intro and overview of HANA, as well as including a how-to 'cook book' on HANA Studio, data loading and Information Composer. We even added a chapter on how the BOBJ tools integrate with HANA.
However, we don't want this book to be just a re-hash of what is already out there on the forums and blogs, so as part of the book, we are building a new system.
This is done by installing IBM's 3950 X5 platform and are installing BW and BOBJ as well to make sure we are getting the real benchmarks and got-cha's in our tests with ComeritLabs and IBM Labs.
Today the system arrived in boxes at the lab, and now the fun begins. I have three of my employees working with me and the lessons learned will be in my next series of blogs...
Background and Authors
First of all, I have to acknowledge that I am biased in this blog. Actually, I am one of the two co-authors. Together with my friend and former colleague, Penny Silva, we are writing the first text book on HANA with support from ComeritLabs and IBM Labs.
Penny is a well know speaker at SAP Conferences with a lot of experience in running SAP BI projects and BI practices. Today, she is part of the IBM global leadership team for SAP Data and Analytics, and at a previous firm, we worked together for several years. So there is no coincidence that we are collaborating.
The HANA Introduction Book Table of Content
Content - Introduction to in-memory analytics - Use cases for SAP HANA - Requirements for running SAP HANA - Implementation options - BWA vs. SAP HANA - Planning your installation - SAP HANA and SAP BusinessObjects - Information Composer and PowerUser capabilities - HANA Studio - Data population - Data replication and ETL with Sybase and SAP tools - Introduction to administering an SAP HANA system