Runtime against full use, memory based sizing, and the restriction found late. Three knowledge checks along the way, and 4 clips from a senior licensing analyst.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. 4 times in the session the frame splits and a senior licensing analyst gives the view from inside real SAP negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back. Session eighteen. Last session ended on the things that sit alongside the FUE line in a conversion quote, and this is the largest of them: the database. S four HANA runs on HANA, HANA is licensed separately, and in most organisations it is the line with the least analysis behind it. There are three things to get right. Which of the two licences you hold, because runtime and full use grant very different rights for the same software. How the sizing works, because the metric is memory rather than users or cores. And why the number grows every single year without anybody deciding anything, which is the part that actually costs people money. Three knowledge checks, and the second one is arithmetic again. Let's begin.
Five things by the end. First, tell the two licences apart: runtime against full use, what each costs, what each permits, and why the difference between them is contractual rather than technical. Second, know the restriction, meaning exactly what a runtime licence does not cover and the specific thing organisations do that crosses the line. Third, size it properly: memory rather than cores or users, bought in blocks, rounded up, and sized at peak rather than at average. Fourth, explain the growth, because the database line rises every year with nobody deciding anything and there is a specific ownership gap where that happens. And fifth, reduce it: four levers in effort order, starting with the table review that tells you where the memory actually is.
Four things to frame it. Two licences: runtime and full use, the same software with very different rights and a very different price. Memory: it is licensed on memory rather than on cores or users, so your data volume is effectively your licence. It grows: nobody ever buys more database, the data accumulates and the requirement rises with it, quietly, every year. And restricted: runtime is tied to the licensed SAP application, and putting anything else into it is the most common breach in this entire area. Here is the framing. The database is usually the second largest line in a conversion quote and the one with the least analysis behind it. It is also the only line on that quote that grows without anybody making a decision. Let's play a clip on why that combination is dangerous.
Guest analyst clip. I want to explain why the database line catches out organisations that are otherwise well prepared, because it is not carelessness. Think about how a conversion project is staffed. There is a team on the user side, because that is where the headline number is and where the business case lives. There is usually somebody on the engines, because a previous audit made that painful. And the database is owned by the Basis team, who are technically excellent and are not licensing people, and who have never been asked a commercial question about it in their lives. So the database is the one line where nobody in the commercial conversation has any preparation at all. Then the quote arrives, and there is a memory number on it that nobody in the room can validate, and no independent figure to compare it against, and a deadline. What happens next is that it gets accepted, because there is no basis on which to challenge it. The fix takes about a day. Ask Basis for the current memory figure and the top ten tables by size. Read your agreement to find out which licence you hold. That is it. One day of work turns the least defensible line in the quote into one where you can say precisely why the number should be lower.
Everybody prepares for the user line and almost nobody prepares for the database line. That is the pattern, and it is worth noticing that the database has both of the properties you should be most wary of: it is large, and it moves on its own. Every other line in the estate at least requires somebody to do something before it grows. A new engine gets deployed. A new user gets provisioned. The database simply fills up, week after week, because that is what databases do. So let's start with the question that has to be answered first, which is which licence you actually hold.
Two commercial forms of one product. HANA runtime: bundled with the application and priced from the value of the application licence it supports, commonly quoted at around fifteen percent, and restricted to that application's data. HANA full use: the unrestricted enterprise licence, priced by memory block, where you may load your own data and run your own applications. The same software: there is no technical difference between them whatsoever, and the restriction is purely contractual, which means it is completely invisible until somebody checks. And under RISE: the database sits inside the subscription, which removes this particular decision and replaces it with a different set that module five covers. Now, dwell on the third point for a moment, because it explains almost everything that goes wrong here. Because the restriction is contractual rather than technical, nothing at all stops a developer loading non SAP data into a runtime licensed database. That is exactly why it happens, and why it surfaces at measurement rather than at the time.
So what does runtime actually permit? Storing data created by the licensed SAP application: permitted under both. Reporting on that data using SAP tooling: permitted under both. Loading data from a non SAP source system: not permitted under runtime, permitted under full use. Building custom tables and custom applications: not permitted under runtime, permitted under full use. And using it as a general purpose database: not permitted under runtime, permitted under full use. Read the exact wording in your own agreement, because runtime definitions have moved across price list versions and yours is the one that binds you. But the pattern is consistent across all of them: runtime is for the application's own data, and everything else needs full use.
First knowledge check. A team loads customer data from a non SAP CRM into your HANA database to run a report. You hold a runtime licence. What is the position? A, fine, since it is your data and your database. B, a licence issue, since runtime does not cover non SAP source data. C, fine, provided the data is deleted after the report runs. D, fine, as long as no non SAP application reads it. Pause here and pick one.
The answer is B. Runtime covers data created and processed by the licensed SAP application, so data from another source sits outside it, and owning the data is not the test. A is the natural instinct and it is the wrong test entirely, which is a large part of why this happens so often. C treats a licence restriction as though it were a retention rule, and deleting the data afterwards does not undo the fact that it was there. And D describes indirect access rather than the runtime restriction, and those two get conflated constantly because both involve the words non SAP. The important point is that nothing technical prevents any of this. Which means it needs a control rather than good intentions.
So how is it sized? Five parts. Memory, not compute: it is licensed on the memory the database is entitled to use, and cores and user counts do not enter into it at all. Bought in blocks: full use is sold in memory blocks, historically sixty four gigabytes, so the increments are large and rounding is not a detail. Runtime is a percentage: priced from the value of the application licence it supports rather than from memory directly, commonly quoted at around fifteen percent. Production and non production: check what your agreement requires for test, development and disaster recovery, because assumptions here are expensive and extremely common. And sized at peak: the requirement is what the system needs at its busiest, which for most organisations means year end rather than an average Tuesday. Let's play a clip on that first point, because a memory metric behaves quite unlike the metrics you have met so far.
Guest analyst clip. I want you to notice something about memory as a licence metric, because it behaves differently from everything else in this course and the difference matters. Every other metric you have met is driven by a decision somebody makes. Named users go up when somebody provisions an account. Engine consumption goes up when the business does more of something. Document counts go up when an interface is built. In each case there is a human action, which means there is a moment where somebody could in principle have asked what it costs. Memory has no such moment. Your database grows because transactions were posted, which is the entire purpose of the system. Nobody decides to consume more memory. It simply happens, continuously, in proportion to the business operating normally. Now think about what that means for governance. Every control you have built so far is a checkpoint at a decision. Approve this user. Review this interface. There is no checkpoint for memory, because there is no decision to attach one to. So the only control that works is a measurement on a clock. Quarterly, look at the number, look at the distance to the next block boundary, and act while acting is still cheap. That is not a sophisticated technique. It is just the only one available for a metric that grows while you sleep.
A metric that grows while you sleep. That is a useful way to hold it, and it has a direct operational consequence: the database is the one line where an annual review is genuinely too slow. Users change when somebody provisions them. Engines change when somebody deploys something. Memory changes continuously, so you want a quarterly figure and a threshold, exactly like the engine register from session nine, and for exactly the same reason.
Second knowledge check, and this one is arithmetic. Your memory requirement is one point nine terabytes and full use is sold in sixty four gigabyte blocks. What do you license? A, one point nine terabytes, prorated to the exact figure. B, thirty blocks, rounding up to the next whole block. C, twenty nine blocks, rounding to the nearest. D, whatever memory the hardware has installed. Pause here and do the division.
The answer is B, thirty blocks. One point nine terabytes is roughly one thousand nine hundred and forty six gigabytes, which is twenty nine point seven blocks, and you cannot license part of a block, so the requirement is thirty. A ignores the block structure entirely. C rounds the wrong way, and a partial block is still a whole block. And D confuses installed hardware with licensed entitlement, and those two numbers can differ in either direction, so which one your agreement measures is genuinely worth reading. Now, the wider point is more useful than the arithmetic. A block boundary makes the last few gigabytes extremely expensive. If you are sitting at twenty nine point seven blocks, then finding forty five gigabytes of savings takes you to twenty nine, and that is an entire block of licence for a very modest technical exercise.
So why does the line grow on its own? Four causes. Data accumulates: transactions, documents and logs pile up whether or not anybody planned for it, so memory rises without a decision being taken. Nothing gets deleted: retention policies exist on paper far more often than they exist in the database, and data nobody needs sits in memory costing money. Projects add footprint: every new module, extension and interface adds tables, and almost no project costs the database line in its business case. And nobody owns it: Basis owns the memory, procurement owns the licence, and the growth happens in the gap between the two of them. That fourth cause is the one that makes the first three persist for years. Let's hear it properly.
Guest analyst clip. The ownership gap on the database is the cleanest example I know of a problem that exists purely because of an organisation chart. Here is how it looks from each side. The Basis team monitor memory continuously. They see it rising. They are entirely comfortable with that, because rising memory is what a healthy growing system does, and their job is to make sure there is enough of it. So they add hardware, or request more, and everything works, and they consider the matter well handled. Which it is, technically. Meanwhile procurement holds a licence entitlement figure in a contract. They have no visibility of memory at all, they have never been sent a report about it, and they have no reason to think about it between renewals. So the entitlement sits at whatever it was when it was bought. Neither party is doing anything wrong. Neither is being negligent. And the gap between actual memory and licensed memory widens quietly for three or four years until somebody runs a measurement, and then there is a very difficult meeting in which two competent teams discover they were each solving half a problem. The fix is not a process. It is one report with both numbers on it and one name at the top.
Neither of them is wrong and the number still doubles. That is the definition of an ownership gap, and the fix is genuinely as simple as naming somebody. Not a committee and not a process: one person whose report includes both the technical memory figure and the licensed entitlement, side by side, quarterly. The moment those two numbers appear in the same document with one name at the top, the gap closes, and I have seen that single change save more money than most negotiations do.
Four levers for reducing licensed memory, and I have put them in the order I would actually run them. Table review: finds the few tables that dominate the footprint, and this is where you start, because concentration is nearly always high. Data tiering: keeps cold data on disk rather than in memory, which is a large effect and it is the most common technical answer. Archiving: moves closed and aged data out of the database entirely, also large, and it needs business agreement on retention so it takes longer to land. And housekeeping: clearing logs, temporary tables and technical debris, which is moderate and quick, and it recurs, so it needs a schedule rather than an effort. Start with the review. In most systems a small number of tables account for the majority of the memory, which turns a database wide problem into two or three specific conversations with named owners.
Five traps. Assuming the database is included: it is a separate line and on premise it always has been, and that assumption is a large part of why conversion quotes surprise people. Non SAP data in a runtime database: the most common breach in this area, technically trivial to do, contractually not, and invisible until it is measured. Sizing from today's memory: the requirement rises with data volume, so today's figure is the floor rather than the answer to a three year question. Ignoring non production: test, development and disaster recovery systems may need their own entitlement, depending entirely on what your paper says. And no archiving policy in practice: paying to hold, in memory, data the business agreed years ago it no longer needed, because the policy exists and the deletion does not.
Last knowledge check. Which single action most reduces your HANA licence requirement for the least effort? A, negotiating a better price per memory block. B, a table review, then tiering or archiving the largest two or three. C, moving to full use so the restriction stops applying. D, reducing the number of users on the system. Pause here, and think about what the metric actually is.
B. Memory is the metric and memory is concentrated, so the fastest reduction comes from finding the largest tables and dealing with those. A is worth doing, and it negotiates the price of a requirement you have not yet minimised, which is the wrong order and it is the order most organisations use. C solves a restriction problem and increases your cost rather than reducing it. And D changes nothing whatsoever, because users are not the metric here, and the fact that I need to say that out loud is exactly why the two axes from session one matter. Let's hear why the concentration point is the practical key to all of this.
Guest analyst clip. There is a piece of analysis that takes about twenty minutes and reframes this entire problem, and it is simply listing your tables by size. Here is what you will find, and I say this with some confidence because it is true almost everywhere. Your memory is not spread evenly across thousands of tables. A handful of them dominate. Very often the top five account for more than half the footprint, and they are usually predictable: change documents, application logs, an interface staging table somebody built in two thousand and sixteen, and one or two genuinely large transactional tables. Now notice what that does to the problem. Before the analysis you have a database that is too big, which is a vague and expensive sounding thing with no obvious owner. After it, you have four specific tables, each of which belongs to somebody you can name, and each of which has an obvious question attached. Does this log need seven years of history in memory? Is that staging table still fed by anything? Those are ordinary conversations, and they get resolved in weeks rather than becoming a programme. So before you commission an archiving project, before you negotiate a block price, spend twenty minutes on the list. It changes what kind of problem you are solving.
Two or three conversations rather than a programme. So, five things to run the database as a tracked line. Report memory quarterly, alongside the engine register from session nine, because it is the same kind of drift and it belongs in the same document. Track distance to the next block, because the number that triggers a purchase is the headroom to the next threshold rather than the total consumption figure. Archive on a schedule: agreed retention, actually executed, and reviewed once a year with the business rather than inside IT alone. Database line in every project: any new module, extension or interface gets a memory estimate before it is approved, in the same review that already checks everything else. And one owner across the gap: somebody accountable for both the technical memory and the licence, because the growth lives in the space between them.
Three sentences. HANA comes in two licences: runtime, restricted to the licensed application's own data and commonly priced as a percentage of that application's value, and full use, unrestricted and priced by memory block. The metric is memory, bought in whole blocks and rounded up, which makes the gigabytes just above a block boundary the most expensive ones you will ever hold. And the line grows every year without anybody deciding, so it needs the same quarterly register as the engines, and a table review is where the reduction starts. Next session we bring module four together: licence conversion to S four HANA, contract conversion against product conversion, and the credits that decide which of the two you actually want.
Homework before session nineteen, about an hour, and the first item is genuinely the most important. One, find out which licence you hold: runtime or full use, read from your paper rather than recalled, because half the people who answer this confidently turn out to be wrong. Two, check what is in the database: any non SAP source data, custom tables or standalone applications, and ask the Basis team directly and in writing. Three, get the memory figures: current licensed entitlement, current actual usage, and the gap between the two. Two numbers and a subtraction. Four, list the top ten tables by size, because the concentration will surprise you and it tells you exactly where a reduction is available and who owns it. And five, ask about archiving: what the retention policy says, and whether it has ever actually been executed. Those are two different questions and they very often have two different answers.
Five guides, all on redresscompliance dot com. HANA database licensing explained covers runtime against full use and the costs, which is this session in written form. The HANA runtime licence guide goes into the restriction in detail and the specific places organisations cross it, which is slide five expanded. The S four HANA licensing guide shows how the database line sits alongside the users and the engines, which is the whole quote in one picture. The HANA Enterprise Cloud guide covers the managed route and what it does to the database licence, which is worth reading before module five. And HANA Cloud negotiation covers where the terms move when the database is bought as a service rather than owned.
That is session eighteen. If you do one thing this week, find out which licence you hold and what is actually inside that database. Next time, conversion, and module four closes. See you then.