SAP as a Platform (SaaP?)

If you were wondering why I hadn't posted my thoughts on last week's ASUG Annual Conference/SAPPHIRE  Now, it's because I gave them over at ASUGNews.

http://www.asugnews.com/2012/05/22/saps-platform-play-why-bi-pros-should-be-bullish/

Thanks so much to Tom Wailgum for looking past all of the swear words in my first draft and removing this link from the Ricky Bobby quote (NSFW)

Speeding up

I've recently reviewed a paper called Accelerating the Speed of Intelligence for Fast and Flexible Forecasting, put out by CFO Research Services* and it really got me thinking about how quickly do people really need their data and whether I'd want to speed mine up. Based on the observations of myself and others, I think it's pretty clear that at least some of our data does need to be real-time (and having the rest of it real-time would, at the very least, not be a bad thing). The questions left on the table then -- assuming you don't already have a rock-solid use case -- are what does super-fast data look like, and how do we reasonably get there?

What does the real-time enterprise look like?

It looks like HANA, obviously. :)

While that answer is half-tongue in cheek, half-serious, and half-covered in Kool-Aid (being in-memory allows 3 halves to be processed simultaneously -- that's just good science) HANA (or at least something like it) really does need to be the answer going forward if a truly real-time enterprise is ever going to happen on a massive scale.

• Existing relational database providers can't support real-time reporting because even in very small deployments people don't want to run reports (especially non-operational analytical reports). They don't want anything to impact the performance of their transactional systems. 
• Existing data warehouse appliances can get you (at least very close to) real-time, but without a specific use case they are out of reach for small to medium enterprises who can't afford the licensing, hardware, and expertise required of having multiple database technologies. These systems can't support OLTP so they are and will remain a luxury of sorts for most customers.
• Some applications (think Workday) are doing great things with in-memory technology, allowing reporting and transactions to occur on the same system. Unfortunately, those great things are largely limited in what data you can pull, how you can pull it, and what you can do with it once it is pulled. It's just too proprietary and silo-ed to branch out beyond its own application.

That leaves us looking for something like HANA, and once it becomes an actual database option for building applications (and some think it is already there), there won't be a reason to not choose it over an existing competitor. It runs on (admittedly beefy) commodity hardware, it will be application agnostic, and it is very reasonably priced (Seriously, pay attention to this announcement and then ask your account rep. You'll be shocked.). If someone were starting truly carte blanche, why wouldn't they pick a database like HANA?

How do we get there?

Assuming you can't start carte blanche, the path to HANA isn't necessarily easy. You've got legacy systems you still need to pay maintenance on, a couple of DBAs who will fight tooth and nail to keep whatever you've got, and a host of applications that you aren't quite ready to rewrite to take advantage of HANA, regardless of your tolerance for pain. So how do we get started?

Small. If you feel like going the very reasonable route, I'd recommend inquiring with some of the hardware partners about "borrowing" a box for a POC (if that hardware partner is also a services provider, even better). Because of the way the software is licensed, you can buy a tiny little chunk to get started. The size of that tiny little chunk is relative to your organization, but you can always add more. Next, buy an appliance that can hold at least twice the storage capability you've licensed software for (and maybe more). Why buy more hardware than software? Because the transaction cost of the hardware is higher, silly, and because the price doesn't grow linearly like it does with the software. As a bonus? With compression, you'll still be able to put more in there than you ever thought.

Once you've made your purchase you'll want to start chucking some "fun" data in there to practice on. This would be a very good time to get some of your other "nice-to-have" initiatives rolling. Exception based reporting? HANA can support that. Predictive Analytics? SAP will sell you that. Mobile? These technologies were meant for each other. Build your next small in-house app with HANA as the database. Once you start using it, you'll see the potential beyond a data warehouse appliance.

Where are we? 

Assuming you don't have a full-fledged, custom built HANA use case and you are willing to follow the plan I've just outlined for you, you are still way ahead of the game. Some swaths of your reporting will hum, you'll be able to do things in your applications that you've never done, and you will have spent a bunch of money (that you would have spent on extra CPUs of a relational database anyway) on something far newer, sexier, and ultimately better than the old tech.

Are any of these "fun" use cases "game-changing"? Probably not on their own. But the next time your current DB vendor shows up with their hand out, you may just be comfortable enough with the technology to tell them you don't need to expand their footprint in your organization. And you'll be ahead of your competition in taking advantage of the next paradigm shift in enterprise computing.

* Thanks to the SAP Office of the Finance team for providing this report to me as a member of their CFO Intellectual Exchange Network program. To learn more about improving financial performance, efficiency and overall financial transformation visit their CFO and Finance Leadership Center. 
**I feel compelled to say "like HANA" because someone will eventually compete with SAP on an in-memory database that can support operations and analytics once they understand the vision***. 
*** Sorry Oracle, but your Exa-... series is just an appliance at this point, and, as far as I can tell, has no interest in being anything else.

Of hope and databases

About this time 2 years ago the former GBN was pulled into the broader ASUG user group, and I was selected into the SAP Mentor program. This was really the first time I had been exposed to the broader SAP community (sorry in advance, broader SAP community) and since that time there has been one common theme in every executive keynote that SAP has been involved in. That theme has been HANA.

It isn't that I don't like HANA. I actually really do. I think it has a ton of potential to create real customer value and to eventually substantially lower the total cost of ownership for many companies. Unfortunately for most companies, eventually isn't quite here yet (and hasn't been on any given day for the last couple of years). Has HANA changed some games? Yes. Has it changed the game? Not quite yet.

Wondering why I care so much about discussions surrounding a database technology that I may well never use? Because it comes at the expense of discussing some fantastic, ready-to-use and reasonably-affordable database technologies that I may use. Everyone knows SAP bought Sybase for mobility, but the real jewel of the deal, at least to me, was the opportunity to hurt Oracle where it hurt -- by turning off Oracle database licenses and turning on Sybase database licenses. Unfortunately, it's been very tough to get an SAP executive to talk about Sybase data solutions (except for the occasional throwaway comment) during a keynote since the acquisition. That all changed this morning during BI2012 when the keynote given by Steve Lucas and Timo Elliott included a demo of data being held virtually and in the cloud by Sybase IQ. That in fact carried over to a HANA-specific microforum where Lucas spoke candidly about how the HANA/ASE/IQ technologies fit together into a unified portfolio.

I think SAP did a brilliant thing by finally folding some Sybase products (ASE, IQ, Replication Server, SQL Anywhere) under an umbrella that really genuinely included a product that was developed in-house (HANA). That meant that the people in one database sales organization aren't trying to sell their SAP database products against different SAP database products that happened to fall under a different part of the field sales organization. This gives an SAP account representative the flexibility to actual provide their customer with an optimal solution. Crazy, I know.

SAP stated that it would be the #2 spot in the database market by 2015. HANA alone wasn't going to do that. With an integrated portfolio that includes relational, columnar, mobile, and in-memory options -- and some work in truly integrating them with each other and into their full analytics stack -- I think they may actually have a chance.