SAP HANA Technical Intro

HANA The Why
Henry Cook,
January 2016
SAP HANA Global Centre of Excellence

https://www.youtube.com/watch?v=VCEr9Y8ZrVQ&feature=youtu.be
Special Note:
This slide deck is provided for those wishing to gain a copy of the slides to the Why HANA
presentation published on YouTube and as a Blog.
The best way to consume this presentation is to first watch it being presented, then to use
these slides as reminders, or as supporting material for your own meetings
The video can be reached through the following two links. The first is a blog which provides
context, an introduction, and a link to the video. The second link goes directly to the video.
https://blogs.saphana.com/2016/03/11/hana-the-why/
Once downloaded, the first part of this SlideShare (Slides 1-46) can be viewed or used just as
they appear in the video itself.
The second part of the SlideShare (Slides 48-92) provides speaker notes for all the slides. This
can be used to revise or clarify particular topics within the presentation
We hope that you find this useful in progressing along your own HANA journey!
2016 SAP SE or an SAP affiliate company. All rights reserved.
Public
A logical evolution each being necessary to provide significant new

business capability and escape the constraints of the past
ERP
R/3
R/2
1979
1992
2004
2015
Mainframe
Client Server
Web SOA
IoT APIs Mobile
Public
Accelerating business innovation through radical simplification

SAP 7-8 years ago
Impeded by complexity,
large, complex suite of applications
15 month release cycles,
Surrounded by increasingly nimble competitors,
Dependent upon others for data management,
Incurring large development costs
Key Question: How to get ahead and stay ahead of the market ?
Strategic response: Massive Simplification of what we do
This simplification is what we now know as HANA
Our Mission
help organizations
become best-run
businesses
Our Vision
help the world run better
and improve peoples
liveslives
Our Passions
teamwork, integrity,
accountability,
professionalism and trust
Public
Traditional ERP system architecture
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
Public
Transformation through Simplification

New Function,
Revenue and
profit
Investment
Resources
saved and
diverted
Cost
Effort / Services
/ Admin
Innovation
Software
Effort / Services / Admin
Simplification
Software
Hardware
Hardware
Public
HANA Simplification shows up as:
Productivity
Users
Developers
Agility
Faster response, time to market
Easier change
TCO
Radical simplification of IT landscape
Public
How do traditional systems impede benefits?

Redundant Pre-aggregated data
60-95% of our data objects, and thus
effort (design, tuning, maintenance), are
due to these supporting data
Data
Data
Data
Hard to combine multiple techniques

Have to spend time in application integration
Mins / Hrs / Days
Qn.
Ans.
Predictive
Text
Ans
Slow response times: Destroys flow and

productivity. Forbids heavy math
Hard to combine data sources: Time &

cost of using data stores
SQL
Data
Data
Qn.
Data
Data
Data
Public
The Motivating Idea
In-Memory Data Management:

An Inflection Point for Enterprise
Applications.
Hasso Plattner Alexander Zeier
ISBN 978-3-642-19362-0
The In-Memory Revolution: How SAP

HANA Enables Business of the Future
21 Apr 2015
by Hasso Plattner, Bernd Leukert
Public
History 2007 The Business Goals of HANA

Qn: 14 years after R/3, what would an ERP (Enterprise) system look like if we start
from scratch? [Hasso Plattner Institute, Potsdam]
All Active Data In-Memory
Leverage Massively Parallel Computers

(Scale with Cores vs. CPU Speed)
Use Design Thinking

Methodology
Radically Simplified Data Model
OLTP and OLAP Back Together
Instant BI
(on Transactional Data)
No More Batch Programs
Live Conversation
(Instead of Briefing Books)
Response < 1 Sec

(For all activities, Even
complex Algorithms)
Virtual DW for Multiple Data

Sources and Types
No Aggregates or
Materialized Cubes
(Dynamic Views)
Views on Views
(Up to 16 Levels)
Aggressive Use of Math
Mobile, Wherever Appropriate

Source: SAP Suite on HANA announcement: January 10, 2013
Public
10
HANA Techniques: How to Build a New Kind of Enterprise System
MULTI-CORE /
PARALLELIZATION
NO DISK
OPERATION
DYNAMIC
MULTI-THREADING
INSERT ONLY
VIRTUAL
AGGREGATES
LIGHTWEIGHT
COMPRESSION
REDUCTION IN
LAYERS
ANY ATTRIBUTE AS
AN INDEX
CALL
+ T +
ANALYTICS
ON HISTORICAL DATA
ACTIVE AND PASSIVE

DATA STORE
TRANSACTIONAL
COLUMN STORE
SQL INTERFACE ON
COLUMNS AND ROWS
OBJECT TO RELATIONAL
MAPPING
GROUP KEYS
BEYOND SQL
PARTITIONING
MAP REDUCE
ON THE FLY
EXTENSIBILITY
MINIMAL
PROJECTIONS
3D
SPATIAL
TEXT
ANALYTICS
SINGLE AND MULTITENANCY
LIBRARIES FOR
STATS & BIZ
REAL-TIME
REPLICATION
Global development, 2007: Seoul, Shanghai, Ho Chi Minh, Bangalore, Tel Aviv, Berlin, Walldorf, Paris, Toronto, Vancouver, Dublin CA, Palo Alto
Public
11
https://www.youtube.com/watch?v=jB8rnZ-0dKw
12
HANA is designed to be more than just a Database

Other Applications
MDX
SAP BusinessObjects
SQL
SQL
BICS
Preconfigured Appliance (or VM or Cloud)
In-Memory software + hardware

(HP, IBM, Fujitsu, Cisco, Dell, NEC, Huawei, VCE)
In-Memory Computing Engine Software
SAP HANA
Data Modeling and Data Management
Modeling
Studio
Real-time Data Replication via Sybase Replication Server
Data Services for ETL capabilities from SAP Business Suite, SAP BW and 3rd Party
Systems
In-Memory Computing Engine
Data Federation: Remote RDBMS, Hadoop
Calculation and
Planning Engine
Row & Column

Storage
RealTime Replication,
Federation
SAP Business
Suite
Data Services
ETL / ELT
SAP NetWeaver
BW
3rd Party
Components
Row Store
Column Store
Calc Engine
Graph Engine
Application Server (XS server)
Predictive Analytics Library
R Interface
SQL Script / Calc Engine Language
Text Engine
Planning Engine
Spatial
Business Function Library
Persistance (logging, recovery) , ACID

transaction integrity
Public
13
There has been a revolution in hardware

20 Years Ago
Now
Memory
1GB
X 6,000
CPU
4 x 50 Mhz
X 1,800
Memory
Memory
6 TB
48 TB
CPU
Cores
120 x 3 GHz
480 (8 x 4 x 15)
Transistors (CPU)
Transistors (CPU)
~ 1 million
2.6 Billion
Near Future
Note: Figures are for single servers

Public
14
HANA, works in a fundamentally different way to other systems,

this initially looks complex, but is actually easy to understand.
Server Blade
Panic
Server Blade
DRAM Memory
DRAM Memory
100+ns
CPU Chip
Cache
80+ns
60+ns
CPU Chip
CPU Chip
L3 Cache
500+ns
3Gb
12.8Gb
15ns
Core 50 Gb
Core
L2 Cache
SSD
200,000 ns
0.5 Gb
DRAM
Memory
L1 Cache
L2 Cache
4ns
L1 Cache
1.5+ns
Mechanical
Disk
10,000,000 ns
0.07 Gb
Processor
Processor
Data Access Latency
Bandwidth
Source: Intel
Public
15
A Useful Analogy
CPU
MAIN MEMORY (RAM) - LOCAL LONDON SHOP (30m)
L1 CACHE,
TABLE (1m)
L2 CACHE
KITCHEN FRIDGE (3m)
L3 CACHE
THE GARAGE (9m)
Public
16
A Useful Analogy
CPU
MAIN MEMORY (RAM) - LOCAL LONDON SHOP (30m)
L1 CACHE,
TABLE (1m)
DISK BREWERY , MILWAUKEE USA (6,000,000 metres)
L2 CACHE
KITCHEN FRIDGE (3m)
L3 CACHE
THE GARAGE (9m)
Public
17
When you store tabular data you get to store it in one of two ways
Table of Information
A
10
35
by column
many columns
40
12
10
35
40
12
or by row
A 10
35
40
12
memory address
Public
18
For rows, data is moved to the processor in chunks but only a tiny
proportion of those chunks are useful
By Row
A 10
35
40
12
fetch data
Data laid out in sequence
Summing numbers
Only a small proportion of data moved

can be used
Lots of padding
Processor spins its wheels
Processor
3 Bn ticks / sec
Public
19
With data stored in columns Every Byte Counts

9
Column is dropped into on-chip

cache memory
10
Caches kept filled no padding
35
Processor doesnt have to wait
Pick up multiple data items each time

you fetch data
Hold data compressed
12
Compute on compressed data
53
Amazingly more efficient
100,000x speed improvements
101
2
40
CPU Chip
L3 Cache
44
L2 Cache
L1 Cache
Processor
3 Bn ticks / sec
Public
20
Columnar data stores offer huge benefits, if you can use them in a
general purpose way
Table - by column
Columnar data store benefits
10
35
40
12
Highly dense data structures

Multiple values for computation available at once
Fully exploit modern CPU architectures
Can be joined with row-based data

Traditional Column Store Benefits still apply
Compresses nicely
Easy to add new columns non-disruptively productivity
Reduces data being processed to just those columns
accessed
Get full benefit by using them for everything
Transaction processing
Text
Spatial
Predictive, etc.
Public
21
All those extra transistors can be used in a number of ways to

speed up computation and throughput by 100,000x or more
Register(s)
Core
CPU Chip
3.4 GHz
L3 Cache
Logs
Persistence
Used to be1 = 1 data value

processed
Make registers bigger, e.g.

256 bits instead of 32
Add circuitry to let them

process multiple values at
a time vector
instructions
L2 Cache
DRAM
Register
L1 Cache
CPU
Give each Core its

own fast cache
More processor
cores per chip
Computations in
registers seldom wait
Fast memory to
keep cores fed
Thus make full use of

Add more registers!
fast registers
Public
22
HANA Memory Data Flow

Register(s)
CPU Chip
3.4 GHz
Core
Register
L1 Cache
L2 Cache
L3 Cache
CPU
DRAM
Logs
Persistence
Parallelism - Multi server / CPU / Core

Vector / SIMD multiple values / intr
Scanning
5 Bn/core/s
Aggregation
12m / core / s
600 Bn scans / single server / sec
ALL Operations
RDBMS
Transaction
Update
Text
Predictive
Spatial

Enables:
Simplicity
Productivity
Public
23
What SAP means by in-memory can be very

different to what others may mean
Register(s)
CPU Chip
3.4 GHz
Core
Register
L1 Cache
L2 Cache
L3 Cache
CPU
DRAM
Others systems simply use RAM

memory to reduce disk I/O
Logs /Persistence
Traditional use
Doesnt get you to 100,000x
Other uses limited (e.g. no OLTP)
HANA uses these memories here to feed vector

instructions, 100,000x performance advantage.
HANA does this for ALL its processing.
These memories, and the way they are used are
completely different things to DRAM
To do this you need to start from scratch.
Algorithms use these new parts of processors
Public
24
Traditional table design in disc-based RDBMS many tables

Complex assemblies of tables complicate BI development and change
Audit / Subset Records
.
Main Master Record
Application-built secondary Index tables
Application-built aggregate tables
ABAP
VDM / SQL
DBA-built secondary Index tables
DBA-built aggregate tables
Public
25
S/4HANA design concept makes use of the much simpler and

elegant columnar data method
Individual attributes each held in
their own separate column store
No complex audit tables. Audits

can be reconstructed as and when
needed from previous values
No indexes, each column is its own

index
Validity Vector
No Aggregates.
We have the ability to dynamically
produce aggregations on the fly
A new value is inserted, the old one is not overwritten but

kept, marking it with a timestamp / validity marker.
One byte is written, one marked as no longer current
Public
26
S/4HANA Example of dramatic simplification:

Logistics - Materials Management
BEFORE HANA
MKPF
MARD
MSTQ
MSPR
MSTE
MSLB
MCHB
MSEG
MARC
MSTB
MSKU
MSSQ
MSSA
MSKA
MKOL
MSTQH
MSLBH
MSTEH
MSKUH
MARCH
MSPRH
MSTBH
MSSQH
MSSAH
MSKAH
MCHBH
MARDH
MKOLH
SAP Logistics table assembly and auxiliary aggregates and indices

28 tables not counting change log tables
AFTER Conversion to HANA
MSEG
New
MSEG
New
SAP sLog
1 table
Public
27
Example of massive simplification:

SAP Accounting powered by SAP HANA
Stability
From
Flexibility
Customer Benefits
Harmonized internal
FI
Document
Logistics
Document
Processing
Financial Accounting
Stability
Totals & Indices
and external
reporting
Significantly reduced
Pre-Defined Aggregates
CO
Document
To
Totals & Indices
Analytics
Management Account.
reconciliation effort
Significantly reduced
memory
consumption
Flexibility
Higher flexibility in
Processing
Logistics
Document
FI Document
Aggregation on the fly
CO Document
via HANA views
Central journal for

Analytics
Logical document
reporting and
analysis
heterogeneous
system landscapes
Public
28
2016
SAP=SE
an SAP
affiliate company. All rights reserved.
1 block
10ordata
objects
29
2016
SAP=SE
an SAP
affiliate company. All rights reserved.
1 block
10ordata
objects
30
Public
31
SAP HANA, the great simplifier of enterprise software
SAP HANA
In-memory platform
2010/11
SAP Business
Warehouse
powered
by SAP HANA
SAP Business
Suite powered
by SAP HANA
SAP Simple
Finance
powered
by SAP HANA
Real-time analysis
Real-time business
Instant financial insight
Real-time reporting
OLAP and OLTP together
No aggregates
SAP HANA Enterprise

Cloud for SAP Business
Suite on SAP HANA
Single source of truth
2012
2013
2014
Simplified data model

New user experience
Advanced processing
Choice of deployment
2015
Public
32
Some facts about SAP S/4HANA
10x
1. Built on SAP HANA

2. ERP, CRM, SRM,SCM, PLM in one system
smaller data footprint

3. No locking, parallelism
7x
higher throughput
1800x
faster analytics & reporting
4x
less process steps
4. Actual data (25%) and historical (75%)

5. Unlimited workload capacity
6. Predict, recommend, simulate
7. SAP HANA Cloud Platform extensions
8. SAP HANA multi-tenancy
9. All data: social, text, geo, graph processing
10. New SAP Fiori UX for any device (mobile, desktop, tablet)
Three deployment options: on-premise, public cloud, managed cloud
Public
33
Revising our Assumptions about System Design

Things that are now much easier with HANA
Simultaneous Real time update (Xm tx/s) and complex analysis on single copy of the data
Doing BI directly on an operational system data in real time
Developing using a much simpler data model the logical data model
Using sophisticated math for forecasting, predicting and simulation, with fast response
Being able to make changes on the fly rather than N week mini-projects
Faster changes to simpler data models, metadata rather than physical data changes
Interactive examination of data, even in production volumes
Fast prototyping using production scale volumes
What were batch processes become interactive

Public
34
Speed allows elimination of aggregates, indexes

this alone can result in a 90%+ reduction in complexity
Calculation Engine
Query Results
Query
Aggregates
Indexes
Query Results
Query
SAP HANA
Data Warehouse
Copy
ETL
Data
Operational Data Store
Optional
Copy
Data
Public
35
On The Fly Transformation provides greatly increased flexibility for

sharing data
View Layer Concept
Presentation
Layer
Spread
Sheet
View
Business
Transaction
Analytical
Application
View
Any Software
View
View Layer
View
View
View
View
Persistence
Layer
(Main
Memory)
Log
Source: In-Memory Data Management, Hasso Plattner/Alexander Zeier
Public
36
Project Efficiency ~60% reduction, tasks shrink or are eliminated

6 Weeks
Define
Current Mode of
Operation (CMO)
Mth 1
~7 month project
4 weeks
Develop
2 days data
3 weeks
Test
Mth 2
3-4 weeks
Rework
Mth 3
2 weeks
Tune
2 weeks
Backload
4 weeks
Volume Test
Mth 5
Mth 4
2-3 weeks
Report
Mth 6
2 weeks
Implement
Mth 7
Traditional RDBMS
Example:
~3 months project
Future Mode of
Operation (FMO)
SAP HANA
(column-store in-memory
DB)
4 weeks
Define
Jun
Single Modelling Tool

(Power Designer)
Aug
4 weeks
Develop/Test/Rework
unlimited data!
Replicate rather than

ETL
Avoid physical model (46 layers/ &
transformations)
Jul
Sep
1-3 days
Backload
1 day Tune!
2 weeks
Report Dment & Volume Test
1-2 weeks
Implement
Less Development
Activate replication rather than ETL
No index (re)-build
Virtual Model
No physical layers
No need to change
physical data model (e.g.
aggregations)
Replication or ETL
can go 50X faster
(e.g. BW PoC)
Less Testing
Replication easier to test
No embedded calculation
Fewer transformations
Only need to set

parameters
Faster, Iterative test/fix/test
Model-driven development
Higher self-service/analysis
means less reports to build
No need to renew sematic
layer
Virtual Model
Easily transported
Faster reload (no
intermediate physical
layers, in-memory)
We took an
analytic that took
us 6 months to
develop and we
redeployed it on
HANA in two
weeks. Results
come back so
quickly now, we
dont have time to
get coffee
Justin Replogle,
Director IT,
Honeywell
Public
37
Simplified Stack, fewer parts, easier development

The HANA architecture lends itself well to an initial TCO
impact analysis.
Based on preliminary analysis with
customers, we established that the overall TCO impact of the
roadmap will be beneficial to operating costs. (i.e. excluding
the substantial business benefits from in-memory technology).
1.
Fewer servers and storage
2.
Less layers of software
3.
Simpler Administration
4.
Lower BI run cost
5.
Faster time to deliver BI projects
6.
Productivity - Tools at your

fingertips
7.
Reduced Shadow IT costs
Public
38
The SAP HANA Platform

A complete platform. Development, Administration, All styles of processing and data
Public
39
S/4HANA the primary reason for HANA and the culmination of a five
year release process
SAP HANA
In-memory platform
2011
SAP Business
Warehouse
powered
by SAP HANA
SAP Business
Suite powered
by SAP HANA
SAP Simple
Finance
powered
by SAP HANA
Real-time analysis
Real-time business
Instant financial insight
Real-time reporting
OLAP and OLTP together
No aggregates
SAP HANA Enterprise

Cloud for SAP Business
Suite on SAP HANA
Single source of truth
2012
2013
2014
Simplified data model

New user experience
Advanced processing
Choice of deployment
2015
Public
40
Click on picture in screen show mode to view video

https://www.youtube.com/watch?v=q7gAGBfaybQ
Public
41
Public
42
Public
43
Public
44
How might HANA simplification solve pressing problems?

Productivity
Users
Developers
Agility
Faster response, time to
market
Easier change
TCO
Radical simplification of
IT landscape
NEXT STEPS
Review requirements, look at them with

fresh eyes
Revisit keeps me awake at night issues
Determine how many could be solved, or
assisted by the new capabilities of HANA
Identify those that are now possible and
were not before
Identify those that are hard / costly to meet
now but could be solved easier / quicker /
at less cost, reconsider how to deliver
them
Public
45
https://blogs.saphana.com/2016/03/11/hana-the-why/
HANA The Why Video Jan 2016.pptx
Mark Mitchell
Thank You
Q&A
SAP Database & Technology,

HANA Global Centre of Excellence
SAP (UK) Limited,
Clockhouse Place,
Bedfont Rd. ,Feltham,, Middlesex,
TW14 8HD
United Kingdom
m.mitchell@sap.com
T +44 208 917-6862
Henry Cook
www.saphana.com
www.sap.com/hana
www.youtube.com/user/saphanaacademy
SAP Database & Technology,

HANA Global Centre of Excellence
SAP (UK) Limited,
Clockhouse Place,
Bedfont Rd. ,Feltham,, Middlesex,
TW14 8HD
United Kingdom
Henry.Cook@sap.com
T
+44 750 009 7478
Speaker Notes Follow
In order to make this presentation self contained the speaker notes for the slides are
included
These can be printed or opened in a separate window to accompany the presentation
They are also useful if you want to refresh your memory regarding a particular topic
Public
47
HANA The Why

The purpose of this session is to remind ourselves of the reasons why HANA was invented, and
why it is unique. HANA represents a fundamentally new approach to large enterprise systems,
one that provides significant simplification. Because it is a new approach it overturns many of
the old assumptions we have about enterprise systems and causes changes in technology,
applications, systems design etc. Because of this it can be sometimes difficult to see the forest
for the trees.
It is a disruptive technology that is having a major effect on the marketplace. Witness the
number of competitors now scrambling to introduce HANA-like features.
It should be viewed in the same light as the introduction of the mainframe, the introduction of
client/server, the PC and the Internet, and will spark a whole generation of in-memory systems.
Well hear as we go through why HANA is special and differentiated and why we expect to
maintain a leadership position for the foreseeable future.
The scene shown is in Hawaii (you can almost feel the warm breeze come through the screen)
Hasso Plattner the inventor of HANA and our CTO at the time, Vishal Sikka have both visited
Hawaii (Hasso is a keen sailor), and in Hawaii there is a place called HANA Bay.
In fact when people talk about the road to HANA you can see it here the road just up from the
shoreline is the road to HANA Bay in Hawaii and if you do the trek to the other end of it you get
an award for doing so.
There are several stories about how HANA got names one is that it was named after HANA
Bay, another that it informally stood for Hassos Amazing New Architecture.
Each year we have been taking HANA customers who are in the 100,000 Club to HANA Bay.
These are customers who have taken a piece of production work and used HANA to speed it up
by 100,000x or more. So, your mileage may vary and wed not guarantee these kinds of results
but speedups of 10x, 100x, 1,000x and more are very typical.
Public
48
A logical evolution each being necessary to provide significant new

business capability and escape the constraints of the past
Before we go back to the beginning lets just take stock of where we are with HANA.
As youll be aware SAP applications have gone through a series of generations, the original system called R/1
Was mainframe based as was R/2.
Twenty three years ago the applications in the Business Suite were being constrained, even when we used the
largest mainframes available.
Note that the R always stood for Real Time the idea that we could do business immediately with no
unnecessary waits. Remember that before this it was usual for applications to be purely batch, using decks of
cardboard punched cards or magnetic tape. The early mainframe versions used the newly available online
terminals allowing work to be done in real time with online transactions.
As larger organisations adopted SAP, and those organisations grew they outgrew the capacity of even the
largest mainframes.
So, in 1992 SAP made a bold move, and became one of the first large software vendors to move to a completely new and innovative architecture, the Client /
Server architecture. This allowed large applications to be broken into pieces and those pieces to be spread over different servers. Moreover these servers
could be less costly UNIX servers, rather than expensive mainframes. Where we wanted to deploy different modules, or different applications, Enterprise
Resource Planning, Customer Relationship Management and Supplier Relationship Management etc this could then be done by placing them on different
servers and networking them together. This allowed us to sidestep the constraints of a single mainframe server. There were other benefits too, the Clients in
the Client Server relationship no longer needed to be dumb terminals they could be powerful and flexible Personal Computers with attractive and easy to
use graphical user interfaces we forget now just what a revolution this was .
As we said, for the past twenty three years this worked well, and represents the state of the art of the technology that has previously been available.
However, in our view current technology has limitations, particularly in the area of complexity, performance and flexibility. So, we set out to discover if there
was a fundamentally simpler way of implementing large systems. It turns out that there is, and this radical simplification is what we now know as HANA.
So, for a second time we are bringing in a revolutionary way of doing things, the move to in memory computing. Whilst well continue to enhance and
maintain our existing Business Suite, we now have S4HANA the Business Suite which is able to fundamentally simplify how it works and how it can be used,
a revolutionary platform which brings significant new functionality, function that cannot be provided without using the unique capabilities of HANA.
Public
49
Accelerating business innovation through radical simplification

Weve seen how HANA is now well established, we have introduced
it in a cautious and well planned manner, and it is realizing its
original vision. Now lets go back and explore why we set off down
this path.
At SAP, our job is to bring the best combination of break-through
technology innovations together to help you accelerate your
business agenda
With our history and focus on software innovation, SAP is uniquely
positioned to help you simplify your IT stack and accelerate
innovation
However, 7-8 years ago SAP found itself in a bit of a bind.
The ERP applications were large and complex with 15 month
release cycles.
We were surrounded by competition, many of them increasingly
more nimble than us.
We were dependent on others for data management, some of them
major competitors, and all of this complexity incurred great cost.
The only way we could see out of this would be if we could
radically simplify what we did, and this was the objective of the
research project that eventually produced HANA. This entailed
hundreds of developers working around the clock for 6-7 years to
get to where we are now.
However having done this we are now poised to pull ahead, and
stay ahead of the market because we have a fundamentally simpler
and more effective base from which to build.
Public
50
Traditional ERP system architecture

Lets just recap the history of ERP. Originally we ran on the mainframe and ran a
single application. Access was via online terminals (a major innovation at that time)
and everything was done in real-time. At the time we were serving mid-sized German
companies.
But then we sold to bigger companies, and those companies grew, as we did so we
needed to deal with the multis; multi-company, multi-language, multi-currency,
multi-application (remember with the mainframe terminals were tied to applications,
multiple apps meant multiple terminals)
This exceeded the capacity of the mainframe, so we made a big leap, with SAP R/3,
to a three tier Client Server architecture, splitting the Client Interface, the application
logic and the database access across different servers, thus spreading the load.
At the same time we now allowed the newly available PC front ends to access multiple
back end applications, instead of having to have one mainframe terminal for each
application we needed.
In the third step we see how this expanded as new applications were added, some of
which we wanted to be able to sell on their own without necessarily having the ERP
core, and at the same time we could mix and match servers to tune for performance
and also to make operations easier. At the top of the diagram we see the appearance of
separate management information systems, data marts and spreadmarts the proliferation of spreadsheets that are actually being used as operational data
marts in the organisation. These were used by organisations to make SAP data available for querying and reporting.
Note that where these different applications were sold with ERP as was usually the case a subset of the ERP data was replicated within the applications
and there would be feedback processes that fed back to ERP too.
In the 4th step we see the addition of a dedicated server for the Business Warehouse, to make management information available from SAP applications, but
often this didnt kill off the separate management information systems, in fact many organisation used BW as a mechanism to populate separate management
information systems. There might also be a separate generic Data Warehouse added, to combine SAP data to non-SAP data at the time it was easier to do this
by extracting the SAP data and taking it elsewhere rather than bringing the non-SAP data in (well see that this has changed). More servers are added, more
data marts and more redundant copies of data however remember that by going this route we were able to scale the systems and to optimise for individual
applications, and, at the time there was no alternative given the technology that was available.
Public
51
Transformation through Simplification

Returning for a moment to our strategic reasons for producing HANA this
diagram shows how a strategy of simplification is allow us, and can allow us
to innovate, to renew itself, without having to incur large amounts of
additional cost or divert resources from essential development of support.
By removing complexity, which saves effort (Services, admin), reduces the
amount of hardware required, through landscape simplification and can also
reduce the overall amount of software needed we can make room in the
budgets to do the new innovative things needed to take advantage of
opportunities and to stay relevant.
This is precisely the strategy that SAP has been following to escape form the
complexity and cost that was weighing us down and which is now allowing
us to pull ahead and stay ahead of our competition.
If you think about it this is the only way to be able to escape this complexity
and cost trap without adding massive extra cost.
One of my colleagues coined the term transformation through
simplification, if you simplify then you transform almost by default, in fact it
is hard not to, because you begin to find you are using less effort and have
less cost and these can be put to work doing the new things you need to do
to be able to compete.
Our colleague Norman Black termed this transformation through
simplification, and if you think about it if you simplify things you naturally
transform things you can help but do that because you naturally start to do
things in the new, simpler, way.
Many organizations are in the situation that we were in 7-8 years ago, and
likewise many can now take advantage of what we have done with HANA,
Cloud, Mobile etc. to move to a simpler, more productive, more agile and less
costly way of working.
Public
52
HANA Simplification shows up as:

Well see that HANA brings a much simpler and more elegant approach to
large information systems. As well see, we should not be surprised at this
as it was the prime objective in its development.
As we go through looking at the different aspects keep in mind that we are
expecting HANA to provide benefits in terms of productivity (for users and
developers), in agility and in reduction in costs. So, it is useful, every now
and again as we go through the various topics, to ask ourselves why does
this improve productivity?, why would I be able to do things in a more
agile way? and how does this reduce costs?. In most cases there are
obvious reasons why this would be so.
The key to understanding HANA is that it is fundamentally about
simplification and this expresses itself in several ways.
It can make end users and developers more productive, giving them results
quicker (orders of magnitude quicker), being able to develop new useful
business benefit bearing function faster and enabling them to do much
more work in a given period of time. For developers this is because the
system and data structures they are dealing with are fundamentally less complex. For end users they are able to use techniques not previously possible
and to get their answers interactively instead of having to wait minutes or
hours, thus they work more in the flow.
It makes people more agile by being able to respond faster, whether that is with instant results to and ad hoc query or being able to put together a new
requirement much faster than with existing technology, e.g. one customer quoted we reproduced in two weeks with HANA an application it had taken six
months to build on the current systems and HANA was a better system with much better performance.
Developers can bring new applications to production much faster, because the design process is much simpler, developers get instant feedback, and there
is less to design and develop.
Likewise, where HANA can be used to collapse multiple MIS systems into one, and combine one or more OLTP and OLAP systems together this can bring
about a massive simplification and cost saving in our IT landscape.
The aims of HANA are to simplify ,and in the process build a better and more profitable business.
Public
53
How do traditional systems impede benefits?

Before we go on its worth reflecting for a moment on what kinds of problems we
encounter in existing systems.
One of the things that Hasso and his team spotted early on was that a large proportion
of the data structures in an application have nothing to do with the business purpose of
that application. Rather they are the supporting data structures that have to be added
to make the system perform, these are the familiar data pre-aggregates, indexes, cubes , materialised views,
pre-joins etc.
These can account anywhere from 60% to 95% of the data objects in the application.
That is, if you looked at the data model for the application (that is the
physical data model that is used to define all the data items) youd find that on
ly a small percentage was basic business data, the data on Customers,
Transactions, Products etc. The remaining majority of the data items are there to help
ensure performance, for example we might have several layers of pre-aggregation of
sales data, daily, weekly, monthly quarterly and yearly. Likewise we probably have
pre-aggregation of the different intersections of data dimensions product by
geography, with again multiple levels product at individual item, product group,
product super-group, product class, these can be combined with geographic measures at the location, district, region and country level all the permutations
and combinations. Somebody has to design, develop, test, maintain all of these !
This is a colossal overhead. But is one which we dont notice because weve always had to do it and everyone has had the same problem so we assume that
this is just the way it is its the standard way that we build systems.
Similarly, if we want to use multiple processing techniques say database, predictive and text, in current systems these are typically separate systems with
separate hardware and software stacks to use them together you dont simply invoke them you have to do an application integration job to use them
together.
Another problem is simply response time. Wouldn't it be great if all operations came back in a second or two ? But they dont, we are used to delays of
minutes hours or days. This destroys the flow of management discussions and problems solving. It also makes it difficult to use sophisticated maths to solve
problems. because it takes too long, again we regard this as normal.
Its also hard to combine data from different sources. Even if we can reach out and read data from existing systems this typically doesnt perform very well,
thus we find it hard to re-use data form existing systems and protect the investment in them and it takes a long time to meet requirements.
Public
54
The Motivating Idea

Well continue this section with a picture from Hasso Plattners book on inmemory computing that encapsulates the original aim in its invention. This
picture shows The board meeting of the future.
All the CXOs are gathered around and they have all their information at their
fingertips. By the way, the same applies to all the staff beneath them, too, the
staff in branches, on the road, middle management, supervisors, field staff
and call centre operators, everybody has direct and immediate information.
Operational data is completely up to date, to the second, there is no need to
wait for complex month end runs we can keep pace with what customers are
doing and what is happening in the supply chain second by second.
Not only that but if an analysis is required it can be performed then and
there, within seconds, no need to gather data and meet again next month,
analysis no matter how complex can be performed sufficiently quickly to
provide input into the conversation as it happens, and that analysis is done
on complete information that is known to be up to date. There is no
disagreement between the operational and analytical systems, because they
are one and the same system.
Clearly it will take some time to get there, for customers to implement the
complete vision, but I think that you will soon see that this is where we will
get to, and why HANA and in-memory systems are uniquely able to get us
there. In fact, if you look at what we are doing with HANA Live and Simple
Finance you will see that we are a substantial way along the road. SAP HANA
provides a fundamentally new capability. A company that can operate in this
mode, with the agility, control and cost effectiveness that it implies will have
a significant advantage over a competitor company that does not.
Public
55
History 2007 The Business Goals of HANA

What we see here is a slide that was used by Hasso Plattner, Chairman and
one of the original founders of SAP, at the launch of Business Suite on
HANA in 2013, and which outlines the original design objectives for HANA.
Hasso had founded his own university, the Hasso Plattner Institute in
collaboration with the University of Potsdam and was lecturing on enterprise
systems.
As part of this he discussed with his PhD students the design of enterprise
systems, and his students being bored with learning about old fashioned
ERP systems wanted something more modern to study and discuss. Hasso
set them the task of working out what a truly modern enterprise system
should look like if we could start with a clean sheet of paper and
incorporating all that we now know about systems design.
The title here talks about ERP, as this was the Business Suite on HANA
launch, but the actual objective was really to figure out what any modern
enterprise system should look like.
It is noticeable that the objectives are mostly business objectives. A good
way of thinking of this is that the objective was to remove all the things that
have bugged us about big system for the last 20-30 years.
For example we split OLTP and analytics apart over 30 years ago, because it
was not physically possible to combine them on the system, this was done
two generations ago and weve forgotten why we did it, it has just become
common practice. Likewise wed like to get rid of batch, do BI on demand
against the transactional system, not need aggregates, be able to use heavy
duty maths etc. etc. Wed also like a sub-second response time, because that
is the way that human beings are wired, they are maximally productive when
they dont have to put up with wait times and delays.
Of course, on the way through wed expect to make use of techniques such
as parallel processing and holding all our data in memory.
Public
56
HANA Techniques: How to Build a New Kind of Enterprise System

This is a representation of many, but not all, of the main techniques pioneered by SAP
HANA. Some are adaptations of previously know techniques such as Massively Parallel
Processing and Column Stores, some, like the updatable column store were totally new
innovations. However, where existing techniques were used typically HANA would take
them a step further and, equally important, these techniques were combined in a
particularly innovative manner. This took over six years of focussed R&D.
The development method itself was innovative, it was a distributed development project
using top talent from around the world. When the developers in Europe went to sleep,
those in Asia would wake up and continue, and when they reached the end of their day
theyd hand over to developers in the USA and Canada. This went on for several years
with hundreds of developers keeping development going literally around the clock. Other
vendors typically took 10 elapsed years to do what we did, we did it in 3 by having a
24/7 continuous shift system
HANA is known as an in memory database but it is worth noting that of all the
techniques only one of them mentions being in-memory the no disk technique.
This is a necessary part of the system but as you can see is by no means the full story.
Also the way in which we use the techniques can be different. Column Store databases
had appeared before and shown their benefit and high efficiency by only transferring data in the subset of columns needed for a query and by allowing very
efficient compression. However, HANA takes this further, it uses column stores not just for these traditional reasons but to ensure that by filling the column
stores with binary encoded data (on the slide as lightweight compression) it can keep the Level 1,2 and 3 on chip caches filled and thus make full use of the
SIMD and vector instructions available in modern CPUs. This is how we get 3.2Bn scans / core / second and that in turn means we can dispense with
aggregates and indexes.
HANA is a general purpose database, so another unique innovation is the ability to do transactional updates against the column store. As we mentioned, and
as you can see here ,there is a lot more to HANA than simply putting our data in memory.
Modern workloads consist of more than just database work, there is also text processing, spatial, planning, OLAP, etc. etc. Therefore we have specialist
engines for each of these that can collaborate within the in memory system, and we have an innovative language that allows us to process in all these different
languages whilst keeping the procedures together, being processed in memory, in parallel.
Public
57
Pepsi Ad
If we think about our slide HANA Techniques: How to Build a New
Kind of Enterprise System which shows all the techniques that are
used by HANA, both those that are adopted, and those that we
invented.
There is an analogy with an award winning series of adverts that Pepsi
had in the 1970s, which summarised all the things you associate with
Pepsi in one high energy snappy sentence.
The theme of the ads, and the strapline that went with it was Lip
smackin, Thirst Quenching, Ace Tasting, Motivating, Good Buzzing,
Cool Talking, High Walkin, Fast living, Ever Giving, Cool Fizzin Pepsi!
Pepsi, fizzes, but they didnt just call it Fizzing Pepsi - that would be
selling it short.
Glancing back at the previous slide we see that we have a Massively
Parallel, Hyperthreaded, Column Based, Dictionary Compressed, CPU
Cache Aware, Vector Processing, General Purpose Processing, ACID
compliant, Persistent, Data Temperature Sensitive, transactional,
analytic, Relational, Predictive, Spatial, Graph, Planning, Text
Processing, In Memory Database HANA!
Every one of those things contributes to the unique thing weve done.
Weve shortened that for convenience to The In Memory Database
HANA, but we should never forget that there is a whole lot more to it
than just In Memory.
https://www.youtube.com/watch?v=jB8rnZ-0dKw
Public
58
HANA is designed to be more than just a Database

First lets do a quick recap on what HANA is what would turn up on your floor or
in your cloud if you ordered one? Dont worry about the detail for now, this is just
a quick note to fix in our minds what HANA aphysically is and isnt, we can come
back to the detail later on.
HANA is an appliance a combination of software and hardware, the hardware being
available from multiple suppliers, though it can also be supplied now using cloud,
virtual machines or a tailored data center configuration that can make use of
existing disk. It adheres to the appliance philosophy of being pre-designed,
pre-built, pre-tested and can be delivered ready to plug in and go. Where we differ
from other vendors is we believe it is no longer necessary to prescribe a single
type of expensive premium priced hardware. It has standard interfaces to the
outside world that make it easy to integrate with your IT estate.
HANA is not just a database. It has a very modern style of architecture in that it
contains a number of collaborating engines each aimed at a particular style of
processing.
The goal is to enable all the different types of processing that applications might
need to do and to do them within the database, close to the data, and feeding the local caches within the modern CPUs so as to fully realize their enormous
processing potential.
This includes development life cycle tools.
Also, Text processing, the ability to do sophisticated text search and sentiment analysis.
There is support for multiple programming languages, including sophisticated SQL scripting languages and support for analytics, including business
function libraries and the open source R statistical suite.
There is a planning engine for specialist planning functions, in particular aggregation and dis-aggregation.
This allows pretty much any type of application logic to be sunk down into the database and thus fully benefit from the 100,000x processing gains.
We also support federation capability to seamlessly pull in data from remote databases and other systems such as Hadoop. This is natural, and just an
extension of our multi-engine design, our query planner and optimiser simply makes use of other engines that are outside of the in-memory core.
So, what well expect to see is certain applications benefit straight away, and others benefit more as they start to exploit this way of working.
OK so now we have a clear idea of what HANA is lets go back to why it was invented.
Public
59
There has been a revolution in hardware

Computer processor technology has changed out of all recognition over the
past few years. Twenty years ago we might have a system that had four
processors, each of which ticked away at 50 million ticks per second
(50MegaHertz). Wed most likely have one Gigabyte of memory, the
processors would be built using one million transistors. This would be a
processor or approximately the Intel 486 class. Also these four processors
would actually be four separate chips.
These days the numbers are very different. The individual processors would
Tick at a rate of 3 billion ticks per second (3 GigaHertz), each chip would
have 2.6 billion transistors, each with multiple processing cores. To put this
in perspective, if transistors were people the old CPUs with a million
transistors would be equivalent to a city such as Birmingham UK, or
Brussels Belgium. As single modern microchip would represent one third
the population of the planet. A single server might be 8 CPUs of 15
processing cores each, totalling 120 processing cores, and this would access
6 Terabytes of data, that is 6,000 Gigabytes.
So whereas 20 years ago a typical business system might have four separate
processors, each ticking away at 50 million ticks a second, pretty soon we
can see well have a simple sever that will have 480 processing cores, each ticking away at 3.4 billion ticks per second.
So we have over a hundred times the processing elements and those processing elements tick away over seventy times faster ! Plus, as well see there is
another wrinkle too which well discuss in a minute these new processors can process many data items at a time with each instruction, the old ones could
handle just one at a time. This means we have over 100,000 times more compute power available on a single simple server! And, of course, this is very cost
effective as its all commodity (Intel) microprocessors., cost performance diminished by something like five orders of magnitude.
Thus, computers now are completely different animals to what they were 20 years ago. In fact it is misleading to use the same words CPU, Processor etc
to describe these wildly different things. One of these modern servers is the equivalent of several data centres from 20 years ago.
The question is, how can you tap into this amazing computing power? As well see you can do this but you have to do it in a completely different manner to
how traditional systems have worked . Remember, this trend has only really taken off in the past 5-8 years so any software written before then will typically not
be using the techniques needed to fully exploit this opportunity.
Public
60
HANA, works in a fundamentally different way to other systems,

this initially looks complex, but is actually easy to understand.
Firstly, dont panic!. This may look very technical but it is actually very easy
to understand so please just go with the flow and stick with this! You will
understand it, and thus understand why we are so different, and so are able
to deliver major new business capabilities plus youll be able to impress
people at dinner parties with your knowledge of modern microelectronics!
This diagram, using information from Intel, shows the relative access time and
data speeds for different parts of a typical computer system. Its a little bit
out of date, but the principle idea remains the same.
OK so what did we do with all these transistors ? The diagram shows three
Intel Xeon chips, these are the blue boxes. In the middle chip we are
looking inside the chip to see two things, multiple processing cores and the
special memory caches (Level 1, Level 2, Level 3) contained in the chip.
CPUs used these extra transistors to have more cores, more processing
elements on each chip, starting with two, then four then six, were now up to eighteen cores per chip and we expect this to increase further. So each chip now
contains many processing elements.
A modern system is made up of different parts that are interconnected,
typically CPU, memory and disks. In addition different processors can also
talk to each other. There is the CPU, the memory embedded in the CPU, the
separate RAM memory, other processors and disks both hard disks and
solid state disks. The red labels shows the length of time it takes to get to the data and the green shows the speed in Gigabytes per second to transfer data. A
nanosecond is one thousand millionth of a second, or one billionth of second. Mechanical or external devices cant keep up with speed of modern silicon.
To get data from the fast memory caches (levels 1,2, and 3) on the chip takes just 1.5 or 4 or 15 nanoseconds very, very fast. But to get data from a hard drive
takes an enormous time - ten million nanoseconds. Even Solid State Disks,external devices, take 200,000 nano-seconds.
So to keep all those many processing cores fed with data and thus use their full amazing processing potential, then we need to use the on board cache
memories, and to keep these cache memories full. In order to do this the software running on the chip has to be aware that these caches are available and to
be written in a way that can fully exploit them, this is what we mean by cache aware. Software that was written before these memories appeared dont know
they are there and cant exploit them, you need change the way the software is written to make full use of them, its hard to retro fit this way of working onto a
traditional system. Plus we can do this very cost effectively using commodity CPU and memory chips.
Public
61
A Useful Analogy
We are not good at thinking in terms of billionths of a second, since that
is so far away from our day to day experience. So here is a good analogy
thought up by one of my German colleagues. Imagine we are sitting in a
house in London, enjoying a drink. In this analogy we substitute beer for
data.
The Beer you are consuming is the data in the CPU, it is immediately
available and being processed.
The beer in Level 1 cache is the beer on the table, within easy reach, 1
metre away.
If we need more then we can go to the kitchen refrigerator, 4 metres away,
this is like level 2 cache
Then theres the refrigerator in our garage not more than 15 metres away
- level 3 cache.
Up to this point we are still just using beer in our house (that is data from
memory on the CPU chip) we have not even yet gone to DRAM, that is left
our premises.
If we need more than this then we can go down the street not more than
40 metres away, fortunately we are next door to a liquor store thats our
RAM memory.
But what happens if we run out of beer (data) and have to go further to
the bulk store to the brewery warehouse? the equivalent of the hard
drive.
Public
62
A Useful Analogy
What happens if we run out of beer (data) and have to go further to the
bulk store to the brewery warehouse the equivalent of the hard drive. In
that case we have to go to Milwaukee, USA 6 million metres, or 6,000 Km
away !!!
(Of course if we wanted to save some time we could use SSD, and just go
to the south coast of the UK! , that would reduce the distance to just 120
kilometres to get our next beer.
What this shows is the huge difference in the ability of silicon to process
data and the ability of mechanical devices to feed them all of which has
happened in the last 7-8 years. Software written before then cannot exploit
these features because they dont know theyre there. Where these
techniques are starting to be used by others they are typically bolt-ons to
existing complex systems and have various restrictions imposed on them.
Rough approximations but they give a good sense for the relative
distance. (Check for current numbers, they are improving all the time)
ns
m
km
CPU
0
0.00
0.00
L1
1.5
1.00
0.00
L2
4
2.67
0.00
L3
15
10.00
0.01
RAM
60
40.00
0.04
SSD
200,000
133,333.33
133.33
HDD
10,000,000
6,666,666.67
6,666.67
Public
63
When you store tabular data you get to store it in one of two ways
Weve now established that to get access to the amazing speed of modern
processors we have to use all those multiple cores, and feed them via the
cache memories held within the chips.
Column Based data stores are one key technique that helps us do our
work in-memory, they have become both proven and popular in recent
years.
We tend to hold our data in tabular format, consisting of rows and
columns, this is the format used by all relational databases, and this is the
way HANA represents data too, in this very familiar and standard format.
When you store any data in memory, or on disk, you need to do this in
some kind of linear sequence where data bytes are strung out one after
another.
You can either store the data row by row (most databases do this).
Or you can store the data column by column. We see this illustrated
above, well now explore the implications for each, and most importantly
how this affects our ability to exploit these modern advances in computer
chips. This may not be immediately obvious, but it soon will be.
Public
64
For rows, data is moved to the processor in chunks but only a tiny
proportion of those chunks are useful
Here we see the data laid out and physically stored in rows, in the more
traditional manner weve used for decades.
Using this row based format we have to skip over the intervening fields to
get the values we want. E.g. if we want to sum the number fields highlighted
with red boxes above, first we read the first one, then have to skip over
some fields to find the second one, then skip over some more to find the
third and so on. These rows can be hundreds of attributes long, each row
may be hundreds or thousands of bytes, 1,000 bytes would not be unusual.
Processors typically fetch data in chunks, and bring them to the processor
to have computations done on them.
In this diagram the alternating blue and green lines show the successive
memory fetches which are retrieving data ready for computation to take
place.
A processor typically fetches data from cache memory 64 bytes at a time.
But a row may be 200, 300, 500 or more bytes long. Therefore it is going to
take many fetches to get to the next useful value to be added, so most of
the time were skipping over padding between the useful values. All the
while this is going on the processor is spinning its wheels, ticking away
waiting for the next chunk of data that has a useful value contained within it
to operate on.
So, to run at full speed and get the maximum out of these fast chips its not
enough to have many fast processors, we also need to make sure that the
next data that the fast processor wants to process is sitting waiting for it in
the cache memory and will be retrieved as soon as the processor is ready to
process it.
Public
65
With data stored in columns Every Byte Counts

Now consider the column based format. Here the number fields are held
together one after another, in one big column, as are the other column values.
This leads to a very dense data format that is easy to compress and where
every byte of data counts.
We can see how it is easy to take a whole column (which may be millions or
billions of items) and simply feed it into the on-chip memories in a
continuous flow. In this way the on chip memories are continually kept full.
A processor is never kept waiting, each time it is ready to process more data
there is a cache full of data close by, thus we make full use of our fast modern
CPU processor.
Thus Column based storage is not just a way of efficiently organizing data
but it is key to being able to feed modern CPUs with sufficient data to keep
them busy, every byte in a column store counts so if we can fill our local
caches with it we can process them very fast on top of the benefits we
might get from compression.
The CPU cores are ticking away at 3-3.4 billion ticks per second, and we are
making full use of that incredible speed. Not only that but processors now
have special instructions that can processes many data items at a time, say
10 or 20. We can do this because all the values are sitting tightly packed
together, so we can grab them several at a time.
With this design each time the processor is ready for another 10 tightly packed data items they are already sitting waiting in the cache memory on the CPU, our
very fast CPU cores, which can process multiple values at a time never have to wait for data, and thus we get the full use of them. This is where we get the
100,000x performance increase that is the key to everything else we do. With this 100,000x performance increase we can do away with the need for aggregates
and indexes and thus massively simplify how we can build our applications.
(Note that simply being a column store does not mean another database can do what we can. Column stores were already used before, but simply because
they reduce the need for disk IO when the columns are on disk. If we query a table of 100 columns but only need to process say two columns then we only
need to retrieve 2% of the data in the table, this speeds things up by 50x (100% / 2%) but does not get anywhere near the performance we see by using our
techniques). This is the key reason we use column based data because of the fit with modern microchip architectures.
Public
66
Columnar data stores offer huge benefits, if you can use them in a
general purpose way
Of course using column store data also provides us with the benefits of
easier compression (because all the data in a column is of the same type)
and the ability to add new columns non disruptively that is without
affecting those already there.
Column stores had already come into use for analytic applications
they were so efficient for this kind of working, the data compressed well,
the data was tightly packed together and youd only retrieve from disk
those columns mentioned by a query. So if our query only looks at three
columns in a hundred column data we only have to scan three percent of
the columns. This saves a huge amount of disk IO and data movement,
hence the query speed up. But it doesnt get us anywhere near the
100,000x speedup we see through the CPU cache working.
But it is the ability to use the local cache memory for our main
computation, and thus make full use of the potential of modern
microchips, that is the important concept here.
In order to be able to fully take advantage of modern CPUs in this way we
need to be able to use this technique across a full range of workloads.
OLTP, OLAP, Text, Predictive, and it turns out that this technique is suited to all of these too, of course you need to design your system from the
ground up to do this.
In the past column based storage has performed poorly at updating, therefore SAP invented a way of doing high speed updates against a column store this
is a unique capability, and it is this which makes the use of column stores general purpose, and we can also use them for text processing, spatial, graph,
predictive etc. etc and any mix of them.
This means that whatever components of a modern workload we have we can get the full benefit of the modern CPUs across the full range of workload we
might wish to do. All data is held this way, and all processing makes use of it.
Other systems are starting to use these techniques but often they are bolted on to the existing database, so all their traditional cost and complexity are still
there. You have to nominate which data to hold in memory, usually its used only for read only queries, you have to do your updating somewhere else and other
styles of processing like text, spatial, predictive cant use these techniques. So you dont get the simplicity of design and development or the runtime speed
advantages.
Public
67
All those extra transistors can be used in a number of ways to

speed up computation and throughput by 100,000x or more
So, to summarise, and see the whole flow within the system, weve seen that
whilst we cannot speed processors up any further we can put more and
more transistors on them, lets consider how we might increase processing
power by using those extra transistors.
Firstly we can put more than one processing core on a single CPU chip. This
is now well established, we started with dual core chips, then went to four,
six, ten and now we have fifteen. More processors mean more computation
done provided our software can exploit them .
We want to keep those cores busy, so we can use other sets of those
transistors to implement very fast memory very close to the cores, actually
on the CPU chip itself, this means cores seldom have to wait for their next
batch of data provided the software knows how to do this.
Likewise if we look at each individual core we can see that we could add
some local cache to each core, in fact we can implement two levels of cache,
one feeding the next, that means that within each core, when we are moving
data into the processing registers the data is highly likely to be right there,
so the computer instructions never have to wait for data, its been
pre-positioned into those very fast memory caches right next to the
registers. If we go down the next level we can see opportunities to turn
extra transistors into processing power there too. Traditionally a processing element, using its register would process one value at a time. An individual
computer instruction would load a single value, do something with it, like add another single value or compare it to another single value, then take the single
value result and store it somewhere.
But what if we used our extra transistors to widen the register, say from 32 bits to 256 bits, and what if we implemented special instructions that could load,
add and store multiple values into the register? Then with each instruction we could process many more times data. Of course wed be loading data values at
a very high rate, processing them N at a time but we can rely on our close memory caches to have the data we need ready so we dont spin our wheels
waiting for data, again provided the computer software knows about these features and how to use them.
Software created 8 or more years ago will typically not be able to exploit these features, because they did not exist at the time. This would be very difficult ot
retro-fit to an existing row-based and disk based database you really do have to start with a blank sheet of paper.
Public
68
HANA Memory Data Flow

In this view we show the flow of data from the solid state memory (DRAM
storage) into the registers where its processed.
We can see from this how it is essential that we hold our data in columns.
If we do this we can readily see how we can have a stream of compact,
tightly packed data values constantly flowing into the Level 3, level 2 and level 1 caches on the CPU chip and within the processing cores, keeping them filled
so that the processors never have to wait for more data.
Modern CPUs have registers that are wide, 128 or 256 bits and special
instructions that can process many values at once if they are packed into
a register together, so we might be able to process data, with a single
instruction, ten or more at a time!
Whenever the register needs another 10 values, say, then they are ready
waiting. This means that the very fast (3.4Ghz, or 3.4 Billion ticks per
second) CPUs we have available can be fully utilised because they always
have data ready to process and thus, unlike other software, we realised
their full power.
To make use of vector processing we have to compute with the data held
in binary format and we do this by using dictionary compression which both compresses to save space but more importantly provides us with a binary
representation of the data that we can compute with. For example when we execute comparisons where we need the order of values to be preserved.
If the data is not compressed in this way we cannot make use of the vector instructions and we would not be able to keep the level 1,2,3 caches filled with data
ready for the CPUs (if the data is not in binary format and is therefore larger then it takes longer to transfer the data or put it in the right format, whilst this is
happening the CPU would be idle, twiddling its thumbs - HANAs dictionary compressed cache aware processing avoids this loss of efficiency.
The dictionary compression also makes the data smaller of course, so we can fit more in the DRAM and also more in the CPU caches but this is really a
beneficial side effect that makes our in-memory system even more economic by needing less storage. The key reason we use dictionary compressed data is
this it allows us to follow the chain of logic that enables us to use the very fast and efficient vector processing we mentioned at the beginning.
We have customers that report processing speedups of 100,000x or more.
We can spend some of this huge speed advantage by trading it off against the need to pre-compute aggregates if we do away with these then we do away
with 60-95% or more of the complexity of the application it becomes much simpler, smaller and more elegant and the business benefits of productivity, agility
and TCO flow directly but to do this you have to do all of that which weve described.
Public
69
What SAP means by in-memory can be very

different to what others may mean
So, from the preceding information we can see that when we talk about HANA being an
in memory machine we are talking about completely different types of memory being
used in completely different ways to traditional DRAM.
The key point here is that the cache memories in the CPU and the ordinary Dynamic
RAM (D-RAM) memories are completely different things. HANA is designed from the
ground up to do its computation in the cache memories and thus gain access to very
high speed computation, and we do this for all our processing. Other systems simply
put data in DRAM to save IOs or make limited use of the CPU caches just for limited
tasks. They are completely different techniques.
In the past database vendors have used larger amounts of DRAM to hold data from
disk to avoid having to incur the overhead and time delay of disks. There is nothing
wrong with this, and it gives you a good speed boost. This is a well understood
technique that has been used for many years. The more data you hold in the memory
buffers in DRAM the fewer times you have to incur the delay waiting for disk and
everything speeds up.
But it does not give you 100,000x speed boost we see with HANA, the speed boost that is needed to considerably simplify our systems.
When we talk about in-memory in relation to HANA we are talking about the Level 1, 2 and 3 caches inside the CPU, we mean taking the column store data and
ensuring the caches are constantly kept full, and being able to take our dictionary compressed binary data many values at a time to fully utilise the vector (SIMD)
instructions that can process data many items at a time with each instruction.
This is a fundamentally different way of doing our computing and to do it we needed to design HANA from the ground up.
Another key point is that not only do we fully exploit these new CPU features that have only appeared in the last 7-8 years but we do this for ALL our
processing, that is we have a system that can take advantage of this much more efficient way of doing things for relational database, predictive, planning, text
processing, etc. etc. What is even better we have invented a way of being able to store the data in a way that allows us to do transactional processing on it too
so we get the speed advantage and can apply it to our whole workload. This means that we dont have to think about which part of the system to use for what
part of the workload, we can use it for everything we may wish to do - a considerable design simplification and source of productivity and agility.
So simply saying that something works in-memory is not sufficient, we then have to ask Which memory do you mean exactly, how do you use it and what can
you use it for? The answers youll receive will be very different for different products.
Public
70
Traditional table design in disc-based RDBMS many tables

Complex assemblies of tables complicate BI development and change
Lets just recap on what is happening under the surface of the traditional way of doing
things, where data is stored as rows or records of data, with many attributes held for a
row. Here we see a large master record containing many attributes surrounded by other
tables, lets explore what those tables are. The master table itself will have many attributes,
possibly several hundred, they may represent attributes used in many different industries,
many not relevant to a particular company.
The turquoise block represents a one character indicator that weve just chanced, say 1
to 2. To do this we have to update the entire record, which may be 2,000 characters long
or more. We also have to write an equivalent sized audit record, or maybe we can get away
with keeping just a subset of the record, as we see at the top.
On the right hand side we see extra tables where we keep pre-aggregated and summed
results, but of course if we update the base record we may have to update these tables too
as various SUMs and COUNTs may have changed, these are application tables, but in the
background we may also have similar tables helping the database manager produce
results and they have to be updated too. We see our turquoise blobs appear where
updates may be necessary. On the left hand side we see a similar structure but this time
for secondary indexes, that is if we have many invoices mentioning products we may also
wish to quickly find out which products are in which invoices, so we have tables,
maintained by the application, which tell us this, these may also need to be updated.
Also we may have similar indexes maintained by the database rather than the application and these need to be updated too.
To summarise, we need a multi-table assembly to get the required business information, and we need auxiliary data sets supporting disc-based row table update
to achieve acceptable write and read performance, these are complex and time consuming to optimise. We also needed a complex ABAP development and/or
complex data model to be able to maintain these structures and keep them synchronized, and also to navigate them in order to do reporting and querying upon
them.
This is Inherently, complex and require exhausting unit and integration testing efforts across the complex data set and table assembly to check any small
enhancement request of the business user community, almost making it impossible for any ad-hoc, on the fly change, and also making it very difficult to provide
timely changes to the system and making very costly the efforts to deploy upgrades and enhancement releases. This way of working maximizes the constraints to
deliver innovations to the business. However, with traditional disk and row based technology there is not choice this is the way it has to be done.
Public
71
S/4HANA design concept makes use of the much simpler and

elegant columnar data method
S/4HANA design concept is based on inserts only the single changed value
only into the in-memory columnar store for the field where the change
occurred it works like this.
Each attribute has its own column of data, it no longer physically shares a row
with other attributes (but we know which attributes constitute a row they are
the Nth value in each column for the Nth row).
When an attribute is modified we dont overwrite the old value, instead we
insert a new value and mark the old one as changed. We have written one
piece of information and modified another thats it, weve avoid to write
whole rows.
Because we still have the old value we can reconstruct the old rows for audit
purpose at any time, in fact we can do that for any point in time. Thus we dont
need all the complex audit data structures of whole extra rows or partial rows.
This is all done live and in memory, of course, we write the change to a
permanent log in case we need to recover but that is fast and simple.
(Note: For the technically minded SAP HANA adds a validity vector to the
tuple, the individual value, to identify the most recent record from a time line
perspective, the validity bit is read during a query execution to speed up the
overall read dramatically.
The bit vector is a technique to speed up the read of the differential buffer where changes are kept for the uncompressed delta changes, so that the combined
read across the differential buffer and the compressed main memory is much faster than the read of a row record on disc or even in memory, as the system can
perform a table scan. For each record, this validity vector stores a single bit that indicates if the record at this position is valid or not. The vector remains
uncompressed to ensure proper read and write speed).
We dont need indexes as every column effectively works as its own index. If we want to pick out particular values we scan the dictionary for that column, pick
out the bit compressed values we need then do an ultrafast scan of the column, no separate data structures are needed.
Likewise we no longer need to pre-aggregate data, we have sufficient speed to be able to roll up and data we wish on the fly.
This is pretty abstract so lets look at the practical consequences of this by looking at our Logistics application.
Public
72
S/4HANA Example of dramatic simplification:

Logistics - Materials Management
Here is the Logistics application before and after
conversion to the simplified version using HANA.
At the top of the slide we see the original data structures
needed. These include all of the kinds of things that we
spoke of earlier, not just the main table (MSEG) but all the
other tables needed to support it, all the layers or
aggregation, secondary indexes, etc
This came to a total of 28 tables to be created, maintained,
tuned, administered and changed over time.
At the bottom we see the new application data structures,
basically a single table. Think of the implications of this in
how easy it is to introduce new innovations and how
simple it is to create new reports that use the data without
having to worry about the impact on the other 27 tables
that are now no longer there. Think about now less error
prone this is, how quickly changes can be made and how
much less testing and administration is needed.
Therefore how much easier it will be for us to introduce
new innovations on top of the ones already enabled by
HANA. This is what allows us to pull ahead of the market
and stay there. We will simply be better able to innovate
than companies reliant upon previous generation
technology, and our customers will benefit by being able
to differentiate themselves in ways that cant be provided
by other software applications.
Public
73
Example of massive simplification:

SAP Accounting powered by SAP HANA
This exploitation of modern microchips and the incredible speed that it makes
possible allows us to do away with pre-aggregated data, indexes and other
supporting data structures.
A good illustration of this is what we have done with our Simple Finance
application. Please note: Whether you are planning to use, or considering our
Finance application is not the point here, here we are using it simply as an
example of how we can simplify a major application.
It was the first of the SAP ERP applications to be re-engineered to use the
unique capabilities of HANA. It is one of our most important innovations, and
was introduced in 2014. It is essentially an entirely new architecture for SAP
ERP Financials.
Its main characteristics are:.
Convergence of FI and CO. There will be one logical document that is the
common basis for both regulatory and managerial accounting. Thereby, a
much higher degree of consistency between FI and CO has been created
abolishing the need for time consuming and error prone manual
reconciliation. Since they are now the same record they cant be different.
Abolishment of pre-defined aggregates. All aggregation and transaction
processing is now performed on the fly based on HANA Live views. The
totals and indices in FI and CO are a matter of the past. This fact is a further
move to preserve data consistency throughout the entire technology stack.
As a side effect and due to HANA, memory consumption is drastically
reduced, helping to reduce TCO.
More flexible reporting. As a beneficial side effect, reports can now be configured by the end user in a very flexible way without requiring any assistance from IT.
We can report on any attribute.
Large customers in particular are interested in leveraging Simple Finance on SAP HANA for harmonized real-time internal reporting (the so-called central journal
/ finance approach) prior to consolidating their full system landscape into a single ERP system.
Public
74
Finance System Before HANA

Heres a good concrete illustration of what we mean by complexity, and
how we provide radical simplification.
Under the Financial application there are about 23,000 data objects
these can be tables, aggregates, indexes etc.
Every little blue rectangle on this diagram represents ten objects so in
fact this diagram is considerably simplified !
Now lets consider a business operation such as a corporate
restructuring, an acquisition, or a demerger. How will that affect the
values that have been pre-calculated and deposited in all these physical
data objects ?
The only way to be sure is for someone to go through them and think
about them, design any changes, develop the change mechanism,
unload and reload and recalculate the data. Clearly a very onerous task
and one that therefore is a significant impediment to making
organisational change.
Remember, when we are evaluating say three scenarios we need to work
out which subset of these physical data objects are needed to represent
those scenarios. We have to replicate these three times and load them
with data structured according to that option. When weve done that is
scenario three better than scenario one because its better, or does it just
look better because something changed in the data in the five weeks it
took to load everything?
By the way, when we do this we also need to worry about which objects
can co-exist with other objects on our disk storage, which can and
should be separated in order to make loading or querying more efficient.
So what is the implication of the simplification that we have done ?
Public
75
Finance System After HANA

In the simpler Finance application we have removed 95% of all the data
objects !!!
That is we have removed 95% of all the things we have to worry about
and maintain in the application.
The function remains exactly the same. In fact we can now do things we
could not do before because we have been freed from being slowed
down by the complexity.
It is intuitively obvious that the diagram above will be significantly easier
to work with, we will be able to deliver function much faster, at lest cost
and with much greater flexibility.
If we want to change company structures and roll them up another way
then we just go ahead and do it there is no need to unload and reload
the data.
If we want to represent the company in several different ways we can do
that too because there is no cost in defining the different structures
because we dont have to store the data.
This will help us be able to change our organisations on the fly and
move toward continuous intercompany reconciliations, and continuous
close and many more functions besides.
It is worth flicking back and forth between the last page and this and just
thinking about the implications for development, for system change and
administration.
SAP invented HANA to make it possible for us to introduce new
applications and change our existing ones much faster and more easily
and from the above you can see how we succeeded and you can do the
same to make your organisation more productive and agile and to
lower costs.
Public
76
SAP HANA
More than just a database a platform
Of course we need to build these capabilities into a complete working
system, and we have done this with what we call the SAP HANA Platform.
At its core is the in memory computing engine weve discussed, but this
is complemented by extending this with large scale disk based column
stores, stream processors, data replication, extract transform and load
capabilities and easy integration with open source systems such as
Hadoop. The modern architecture that contains a number of different
complementary engines. The core engines run in memory to provide the
simplicity and agility that in-memory gives, but it is extended by many
other engines external to the in-memory core, engines for multi-tier
storage, Hadoop as an engine for large volumes of unstructured data,
engines that happen to sit in legacy systems, and specialist engines
such as for streaming or for communications with mobile devices.
This architecture is simple, elegant and modern. It allows for any mix of
processing, provides very cost effective IT and yet gives you the
productivity and agility advantages of in-memory.
These are generic advantages and the can be used for both SAP
applications, non-SAP applications or mixtures of the two.
This allows us to use the platform to address a wide range of information
requirements and match the right kind of tool to the right job. It allows us
to very easily integrate the SAP HANA Platform into existing IT estates,
complementing what is already there, and then meeting requirements in
a simpler and more cost effective manner.
Well not dwell on this now, as SAP has many comprehensive
presentations to take you through the SAP HANA Platform, the point here
is that having invented a fundamentally simpler and more effective way
of building enterprise systems we have built this out into a complete
platform.
Public
77
SAP HANA, the great simplifier of enterprise software

The vision of SAP HANA has been introduced in cautious well considered steps over a
number of years, introducing new function gradually and fully exercising the core
platform. In 2011 (actually 2010) we released HANA simply as a stand alone analytical
platform.
From 2012 we could drive real-time operational reporting and simplify how they run
their SAP BW. SAP BW powered by SAP HANA has already exceeded +1600 customers
From 2013 our customers could start working as real-time business and simplify how
they run their SAP Business Suite by bringing transactions and analytics together into
a single in-memory platform. SAP Business Suite powered by SAP HANA has exceeded
+1800 customers in only two years (one of the fastest growing product in SAPs
history)
Business Suite, specifically enabled by HANA provides our customers with significant
benefits through massive simplification, much greater flexibility and much greater
performance and all at less cost. More than 5800 customers have already adopted the
platform to do just that with our existing applications optimized to run on SAP HANA:
In June 2014 we enabled people to drive real-time insight across finance and simplify how they run their finance system with SAP Simple Finance powered by SAP
HANA, simplifying the application by 95%, removing 22,000 data objects, removing aggregates, data redundancies and replication
With S/4HANA, we are building on the success of the SAP Business Suite powered by SAP HANA with a completely new suite. S4HANA is only built on SAP HANA
because only HANA can deliver the level of simplicity required by customers today:
Now in 2015 S/4HANA is natively built on SAP HANA for massive simplifications (simplified data model: no indices, no aggregates, no redundancies), also using
SAP Fiori offering an integrated user experience with modern usability (these interfaces are role-based, with 3 steps max to get the job done, developed mobilefirst, and offering a consistent experience across the various Lines of Business.
S/4HANA is natively built for advanced innovations (e.g. new applications predicting, recommending, simulating / processing of text, geo data, graphs, genomes).
Also, S/4HANA is natively engineered for providing choice of deployment (on-premise, cloud, hybrid). In addition S/4HANA fully leverages the new multi-tenancy
functionality enabled by SAP HANA
Public
78
Some facts about SAP S/4HANA

Now that weve established how weve been able to do something very
different, to fundamentally simplify enterprise systems lets look at how this
expresses itself in our new generation of applications, and see how a few
current facts about S/4HANA speak for themselves.
It is clear form these that we have succeeded in the vision that we set out to
realise. S/4HANA is a new code base, and with Fiori a new User Interface (UX),
plus new guided configurations that help with adoption.
These simplified applications are seamlessly integrated to offer one solution
for a wide range of business problems. All these application get completely a
modern web-based Fiori User Experience ready for real cloud consumption
All these capability taken together makes these applications a completely new
product: with new database, data management, technology and front-end.
A major achievement is the ability to reintegrate ERP, CRM, SRM, SCM, PLM in
one system - to save hardware costs, operational costs and time.
This is possible because S/4HANA has a 10x smaller data footprint compared to
a best-in-class business suite on traditional database. But remember now we
implement these on platforms that are large scalable clusters of processors, we
have a unified system but one that is easily and linearly scalable.
Thus we can see that in some ways we have come full circle, back to the
integration of multiple modules and applications on a single platform, but now
considerably simplified and with much greater performance.
Another example is less process steps: Processing receivables app in SAP GUI
vs. FIORI/Simple Finance: Number of screen changes 8 --> 2 (4x)
Public
79
Revising our Assumptions about System Design

Things that are now much easier with HANA
Before we go on its worth doing a quick checkpoint. Weve explained how HANA was
specifically designed to solve major problems with existing systems. Some of what weve
said about HANA is counter intuitive, because it goes against twenty or more years of
experience with computers. There are certain assumptions we make about systems
design because those assumptions are based on long experience. But here we must not
just learn about HANA but un-learn many of those assumptions because they are no
longer true.If we have a requirement that needs high speed transactional update against
a data store that we want to simultaneously do complex analysis against then we can in
the past wed have to separate these two pieces of the requirements into different parts
of the system, and OLTP updating system and a complex query system and then
implement logic to connect them, keep them in sync etc. That is no longer true, HANA
allows us to combine both on true single copy of the data.
Thus we can do BI queries against the operational data, either a custom application
weve written, or an SAP application such as the Business Suite.
We can develop using a simple data model that consists of pretty much the logical
business data model, rather than having to embellish it with lots of added aggregations
and indexes. This makes for much faster development and much easier modification.
We can implement more requirements and keep the system up to date with changed requirements more requirements met equals more benefit.
Large scale math can be used, often interactively. Previously wed shied away from this because response times would be too long. But now we can insert
heavy duty math into what look like interactive OLTP transactions and get superior results from more sophisticated analysis.
Because of the ease of change we can commit to keeping the application up to date more easily, supporting a faster pace of change, for example modifications
to analytic rule-bases or constantly changing reports.
We can check out our data, even at production volumes in seconds. This allows a much faster pace of development, and we often dont have to have separate
phases of the projects one for functional development on a subset of the data and then others for full volume testing.
Likewise we can most likely do away with most batch processes and instead streamline our processes so that they become interactive, thus enhancing the
productivity and responsiveness of those who work with the system, both developers and users.
So this is just an aide-memoire of things to reconsider, things that used to be complex and scary but which now are relatively straightforward. Well explore
some of these in more detail now.
Public
80
Speed allows elimination of aggregates, indexes

this alone can result in a 90%+ reduction in complexity
Thus, importantly, one of the ways in which we choose to spend this speed
increase is not in simply making things faster. Rather, we take that speed and
use it eliminate complexity. When we can do our processing so fast you no
longer need indexes and aggregates and all the complexity that comes with
them.
In fact, for most types of processing we can not only eliminate all this extra
complexity and baggage from our systems but still end up with a system that is
much faster than our old ones!
This is the goal of HANA, not simply making things faster, but radically
simplifying everything we do, this represents a fundamentally new way of
doing things, a step change in information systems, just like the mainframe
was, Client / Server, the PC, the Internet.
Remember, what we are aiming to do, is to improve productivity, agility and
radically reduce cost of ownership.
When we look at the above we can see lots of reasons for this. Users get
instant or near instant results, even for complex processing. Developers can
deliver new or changed function to them sooner so they can accrue more
benefits, they can do this since the whole system is much simpler to develop in
there is less to develop and what is left is simpler to develop with.
If we need to respond to new opportunities and threats we can do much more
simply too, for the same reasons, simpler systems are more agile to work with.
Obviously we have radically simplified the IT landscape so we save costs on
hardware, data centre costs and administration. Aside from being on
commodity Intel systems well expect to need smaller systems and fewer of
them. Note that they are only smaller in number and size, their compute power
may be many times that of the original systems.
Public
81
On The Fly Transformation provides greatly increased flexibility for

sharing data
Another thing we can do with HANA is to defer the transformation and
combination of data into new forms until the moment we issue the query.
That is, transformations that would normally be done as part of an ETL
run can be done on the fly.
This can make us incredibly more productive, we can develop new
reports quickly, if weve got something wrong there is no physical data to
reload, we dont have to integrate the data physically before we can
combine it.
Applications can easily share data with each other, they just have to read
it, as if it was part of their own application think profitability metrics
used by marketing for example.
We already use this technique with our ERP system using a virtual data
model called HANA Live to provide easy to use views on to the
operational ERP data.
Each layer of the view simplifies the underlying data structure. One layer
may combine tables, another may substitute user friendly names, another
may calculate measures so that what starts as a complex third normal
form set of thousands of tables is presented as a set of user friendly
cubes or star schemas.
Also consider how easy it is to fix errors, if we have done a transformation incorrectly we just correct it and then recalculate no need to do lengthy and time
consuming reloading of data structures, this makes us much more agile.
It is also simple to combined data from different systems.
Consider also that using this technique we may have multiple different versions of views in use simultaneously. If we were going through a transition, say a
restructuring, then we might have an as is view, and a to be view, and maybe several alternatives in force at the same time. After all, they are just definitions,
we havent had to prepare and physically load the different versions of the data because were generating each of them on the fly, we can have as many as we
care to define.
Think of the freedom that this gives us to flex and make changes to the organisation.
Public
82
Project Efficiency ~60% reduction, tasks shrink or are eliminated

This is a diagram showing the effect of simplification on a typical project
plan.
The data was drawn for half a dozen SAP BW projects, but the principle is
the same for any project.
At the top we see the traditional way of doing things, and at the bottom
we see have we do them with HANA.
This is again pretty simple, many of the tasks shrink and many of them
just go away. There are no physical cubes to design, place on disk, and
tune they dont exist any more.
When we are checking out the data we can do this with queries that give
us instant results so we can go through many cycles of data checking
very quickly.
We dont need a separate volume test phase. Usually wed functionally
test on 10% or less of the data, then do a separate phase where we crank
up the volumes, and which point we discover the data errors wed missed
and scaling problems. With HANA we are more likely to used production
scale volumes from the beginning so we dont need a separate phase.
As we implement our different queries and as the requirements get
modified we would normally have to design the database, that is define
the physical data structures in a way that that will provide adequate
performance for our many users. With HANA we dont need to do this as
we dont need to do this, we can run pretty much on just the logical
model with no aggregates, cubes and indexes required. It is just
common sense that this takes much less effort.
Public
83
Simplified Stack, fewer parts, easier development

HANA also offers the opportunity to reduce the number of different
hardware / software combinations in the IT estate.
Because HANA is a complete platform, containing multiple processing
techniques and tools then quite often we can just invoke the features in
the HANA platform and dont need separate components or it may be we
still have some separate components but there are now fewer off them.
We probably have less copies of the data, and a lower latency in getting
results due to moving data between different layers. Moving data between
different platforms or stacks also contributes to lack of agility since we
have to do an application integration job to solve our requirements.
Of course the separate stacks also contribute to complexity and cost, and
can also lead to a lack of transparency and control. Simply put, if there
are a smaller number of components and they are all gathered in one
place we can develop more quickly and at less cost.
Advantages of SAPs approach are that we have a single platform that can
be used for both transaction processing and reporting. There is a lower
cost to serve since the server is smaller and simpler. When we develop
applications we just invoke the different components as and when we
need them. The overall system is smaller and easier to administer. We can
also grow it incrementally using those features we need as and when we
need them without having to add whole new platforms.
:
Public
84
The SAP HANA Platform

A complete platform. Development, Administration, All styles of processing and data
Weve shown how we can use advanced in memory techniques to
radically change how we do our information processing to radically
simplify our systems and provide superior performance.
What we also needed to do was built a complete general purpose
information processing system around this core, as we need to be able to
cope with a wide range of different workloads.
This is shown in the diagram above. Here we see the various HANA
engines, but we also see the obvious extensions such as data
provisioning tools, access to a high volume warm data store and
integration with
HANA platform being used by both SAP and non-SAP systems. We see
the multiple in-memory engines being extended with things like tiered
storage and federated access to remote systems and Hadoop.
We also see the multiple data input methods allowing for ETL, ELT,
replication and streaming.
With this we can cope with any general purpose workload we might
encounter and we are able to deploy the right kind of component for the
right kind of job.
The modern layered architecture that we follow makes the system easy to
extend as new modes of storage and processing types are invented
weve just demonstrated this with the introduction of a Graph engine for
holding and traversing very large networks of nodes and linkages
between them which enables us to naturally represent network problems
such as the monitoring of a telecommunications network or keeping track
of the relationships between people, places and things.
Public
85
S/4HANA the primary reason for HANA and the culmination of a five
year release process
So, we can now see why we developed SAP HANA, and how we are able to
bring about the significant simplification that it offers.
Weve seen that by fully exploiting modern microchips through innovative
techniques we can fully exploit them to get speed ups of 100,000x or more.
This then allows use to eliminate unnecessary data structures such as preaggregated data, indexes etc, thus significantly simplifying applications,
making them easier to develop, maintain and use and there is enough speed
increase left over, after making the simplifications, to still have the
applications run hundreds or thousands of times faster, thus adding to our
productivity by eliminating wait times.
We can thus see, in the picture above, that S/4HANA was both the long term
goal in the development of HANA, the next generation of ERP with significant
capabilities that can only be provided using the simplicity and speed of HANA
capabilities that cannot be provided using previous technology.
We can also see that this is the culmination of a careful and methodical five
year release schedule, first releasing the core technology, then moving on to a
non-mission critical application (BW), then porting the Business Suite to
HANA, then taking the core application (that the others depend on) Finance
and showing how it can be simplified, then releasing then moving on to other
parts of the Suite to do the same thing there.
At different parts of HANAs history it has been type-cast into a number of different roles, an in-memory query accelerator, a replacement for BW Accelerator, a
turbo charger for the Suite, so its easy to see how the perception of HANA can get stuck in any one of these roles. But now, with the successful introduction
of Simple Finance and S/4HANA that its true, general purpose and multi-purpose role becomes clear. It represents a fundamentally better, simpler and more
effective way of using information that can be applied to any information task.
The radical simplifications that HANA brings allows the new generation of ERP S/4HANA to evolve from its predecessors, R/2, R/3 and ERP and be able to
provide significantly different business capabilities, such as fast close, predictive close, creation of real time reports on the fly, easy restructuring, more flexible
reporting on any attribute stored and many more.
Public
86
Boardroom of the Future - 1/4

Remember that Boardroom of the Future picture that we started with ?
The simple picture of the vision of what we wanted to achieve with
HANA, well, from the third quarter of 2015 SAP started running its board
meetings using our first version of that kind of system.
These are a series of screenshots taken from a short (11 minute) video
thats available on YouTube which provides an overview of the actual
system.
See: https://www.youtube.com/watch?v=q7gAGBfaybQ
You can just click on the picture to view the video.
This system is currently being offered as a commercial product, so other
companies will be able to gain the same agility advantages too.
In its current version it is run on three very large touchscreens. In this
picture we see the agenda items listed on the screen, and the person
running it will just have to touch an agenda item to display the
information relevant to the discussion in that part of the agenda
Public
87

Here is a typical expansion of one of those agenda items. It is a display
with a whole range of KPIs graphs and statistics that describe the
situation.
We can touch different parts of the display to drill down to detail, or to
expand the display in different ways. This is highly interactive as even if
we have to process hundreds of millions of rows of detail data, or more,
we get the answers back in seconds, so as not to constrain the
discussion.
Participants can get their answer in human real time and deal with a
particular issue to its conclusion without having to defer it to future
meetings or put up with lengthy delays. There is no need for specialist IT
support to redesign parts of the database or build special reports
incurring waits of days or weeks, we can do anything we want when we
want right there in the meeting.
Public
88

Here the person at the screen has selected an item that provides
simulations and dragged it with his finger onto the screen. The system
has then provided a forecast simulation for upcoming time periods
based on the history its seen previously.
This can be overlaid with the actuals thus far for the year, and we can
predict, where we think well end up. This means we an see problems
coming when there is plenty of time to deal with them, not having to wait
till quarter end accounts before we realise were in trouble.
These can be financial measures, but they could also incorporate real
time feeds direct from our business processes that show where we may
have bottlenecks in the system that are causing problems with the
financial numbers. If we want we could expand it with customer
information or signals from the market that show the trends on demand,
or lack of demand for particular products.
This is completely flexible because we are doing all of the analysis by
rolling up from the item details, so we can do this at will, simply by
saying how we want it rolled up.
Public
89
Boardroom of the Future 4/4

Here weve moved on to a discussion of the company sales pipeline. We
see a map of the world coded according to where the revenue is coming
from.
On the right we see a cluster of colour coded blobs, the size and the
colour of the blob tells us about a particular large deal that is part of our
pipeline. We can touch a blob to expand it and drill down into the detail.
We can cross relate an opportunity to the staffing for it, so we can
immediately see if we have sales teams that are overloaded or who need
particular help. This is all transparent and immediately visible on the
meeting.
So, as you can see we are now coming full circle back to the original
vision for HANA, enabling the next generation of flexible ERP, a general
purpose platform that allows us to implement systems with greater
productivity, agility and at lest cost, and making good on the promise of
doing business in real time.
Public
90
How might HANA simplification solve pressing problems?

Thank you for your attention. Weve covered a lot of ground in this
presentation, but we believe that it should now be clear why HANA was
invented, what it is, and what is so special and disruptive about it.
We have seen many examples and illustrations of how it can help a
company very directly gain new business value.
As we note above, we expect the benefits to be the result of a
fundamental simplification in the implementation of new business
requirements. These benefits principally appear in improved productivity
for users and developers, greatly improved agility, and a potentially
radical simplification of the systems landscape, with of course
spectacular improvements in performance too.
But this is not just an interesting academic exercise. Instead it gives us
an opportunity to revisit requirements and look at them with fresh eyes.
These may be problems that weve previously not been able to solve, or
it may be that we have problems we have solved, but there is now a
much easier, less costly and faster way to solve these and which provide
additional benefits.
We might do this by homing on particular issues or we might have wider
scope Design Thinking discovery sessions.
We look forward to working with you to find ways that give you new ways
to gain business benefit. Thank you.
Public
91
Thank You and links to further information

Thank you slide for audience.
Also a series of links for further information.
These include:
Links to the original blog and video, this Slideshare provides a means for
people to obtain a copy of the slides. As stated earlier the best way to
consume this slide deck is to first watch the original video on YouTube,
then use this deck as a refresher, or to support your own meetings.
There are also contact points within the SAP Global Centre of Excellence
for HANA should you wish to ask questions or discuss this with SAP, or
simply contact your SAP representative
Plus there are the high level online links to SAP HANA sites, in particular
saphana.com and sap.com/hana
A wealth of information about many different topics can also be found
thorough the link to the SAP HANA Academy
Public
92

SAP HANA Technical Intro

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

SAP HANA Technical Intro

Enviado por

Direitos autorais:

Formatos disponíveis

HANA The Why

SAP HANA Global Centre of Excellence

A logical evolution each being necessary to provide significant new

IoT APIs Mobile

2016 SAP SE or an SAP affiliate company. All rights reserved.

Accelerating business innovation through radical simplification

2016 SAP SE or an SAP affiliate company. All rights reserved.

Traditional ERP system architecture

2016 SAP SE or an SAP affiliate company. All rights reserved.

Transformation through Simplification

2016 SAP SE or an SAP affiliate company. All rights reserved.

HANA Simplification shows up as:

How do traditional systems impede benefits?

Hard to combine multiple techniques

Slow response times: Destroys flow and

Hard to combine data sources: Time &

The Motivating Idea

In-Memory Data Management:

2016 SAP SE or an SAP affiliate company. All rights reserved.

The In-Memory Revolution: How SAP

History 2007 The Business Goals of HANA

Leverage Massively Parallel Computers

Use Design Thinking

Radically Simplified Data Model

OLTP and OLAP Back Together

No More Batch Programs

Response < 1 Sec

Virtual DW for Multiple Data

Aggressive Use of Math

Mobile, Wherever Appropriate

2016 SAP SE or an SAP affiliate company. All rights reserved.

HANA Techniques: How to Build a New Kind of Enterprise System

ACTIVE AND PASSIVE

SINGLE AND MULTITENANCY

HANA is designed to be more than just a Database

Preconfigured Appliance (or VM or Cloud)

In-Memory software + hardware

In-Memory Computing Engine Software

Data Modeling and Data Management

Real-time Data Replication via Sybase Replication Server

In-Memory Computing Engine

Data Federation: Remote RDBMS, Hadoop

Row & Column

2016 SAP SE or an SAP affiliate company. All rights reserved.

Application Server (XS server)

Predictive Analytics Library

SQL Script / Calc Engine Language

Business Function Library

Persistance (logging, recovery) , ACID

There has been a revolution in hardware

2016 SAP SE or an SAP affiliate company. All rights reserved.

Note: Figures are for single servers

HANA, works in a fundamentally different way to other systems,

2016 SAP SE or an SAP affiliate company. All rights reserved.

MAIN MEMORY (RAM) - LOCAL LONDON SHOP (30m)

MAIN MEMORY (RAM) - LOCAL LONDON SHOP (30m)

Data laid out in sequence

Only a small proportion of data moved

Processor spins its wheels

2016 SAP SE or an SAP affiliate company. All rights reserved.

With data stored in columns Every Byte Counts

Column is dropped into on-chip

Caches kept filled no padding

Processor doesnt have to wait