Why is in-memory database important to #SAP ?

Very busy these days, but wanted to share some thoughts about in-memory database and why it is so important to SAP - and the industry. All of this is just my opinion, and based only on my experience.

SAP is really a collection of business processes implemented in software. No shock there. In some cases, these processes are implemented in code. Yech. In other cases, these processes are implemented as simple or complex finite state machines dynamically driven by data or metadata; unfortunately, these state machines are written on different programming models, using sometimes very different (domain-specific) languages and technologies. Generally speaking, these state machines are integrated (or can be integrated through customization) in various ways that can be very interesting to enterprises, allowing for processes like "build to order" to function properly (which integrates "order" with "collection" with "dunning" with "schedule" with "manufacture" with "ship" with ...).

Because these processes are so diverse, and have been implemented literally over a thirty year stretch in time, there is not a lot of consistency in their underlying technologies and programming models. With all this inconsistency, it is not straightforward to produce and consume events, which makes these processes hard to configure, integrate, and extend.

Event-based systems are not foreign to SAP, but (modern) event-based technology (at least within the applications) is. Anyone who has used ARIS to do the design of business processes for SAP implementations has probably used "event-driven process chains" (EPCs) to describe processes; implementing the event connections, however, has often/mostly been a process of writing custom code. There is no publish/subscribe bus for (most important) SAP events, thus there are no (substantial) event publishers or subscribers in the SAP application suite.

If SAP were to undertake a rewrite of its applications, it would have the opportunity to implement events in a consistent way in the applications. I am not certain if this has been done with Business ByDesign ("ByD"), which was a project which undertook to rewrite some of SAP's applications, but very few mySAP Business Suite customers will be replacing their mySAP suites with ByD any time soon.

If, on the other hand, SAP were to undertake a rewrite of its application server tier to replace all calls to a database with calls to "HassoDB" (the in-memory database that got so much attention at SAPPHIRE this week), SAP would have the ability to simultaneously event-enable its product essentially with little to no additional effort. If HassoDB understands that an object is being stored, updated, or accessed, HassoDB could publish an event - and that event could be consumed by new applications that speed up integration between business processes, allow the insertion of new business processes, or that simply generate alerts for users.



SAP even has a design for such a capability: SAP Live Enterprise from SAP's Imagineering team.

How could this capability be deployed? Well, imagine that a sales person gets an alert every time their customer makes a payment, is late with a payment, submits a complaint or service request, or places an order on-line. Or that a salesperson sets up an "auto-responder" for those events, thanking the customer or asking her for feedback as appropriate. Event-based capabilities would greatly speed up and improve service.

Another example could be in integrating business processes. Rather than hard-coding the "on-boarding" process for a new employee, there could be an event-driven integration. The hiring process could generate an event when an employee's starting date is set; other processes could subscribe to that event, and do the appropriate processing, including reserving an office, preparing the HR orientation, ordering a company credit card, requesting an entry badge, or assigning and configuring a computer. Whenever the on-boarding process changes, rather than editing the process definition, taking the application down in the process, and restarting it, instead an administrator would just load a new action and subscribe it to the appropriate event.

Finally, how will customers license the in-memory database? Will they have to buy it or will it be included in maintenance? If it is the latter, and if the in-memory database can be made compatible with older versions of SAP, then this would be substantial justification for the maintenance fees SAP has charged customers over the years. Even if customers have to separately license and pay for this capability, if it is made compatible with all versions of mySAP under maintenance, that would be a huge benefit for customers. I'm looking forward to SAP bringing "HassoDB" to market. With the help of the database gurus at Sybase, I think it is possible that in-memory will finally come to "Big Data" enterprise problems.

Top 10 Reasons Why Steve Jobs and Apple Reject Adobe Flash

In the spirit of Top Ten lists, here's Steve Jobs' "Top Ten Reasons for Rejecting Adobe Flash" (for the irony-impaired, please note that this post is not based on the truth):

#10: Adobe Flash is too proprietary to run on any of Apple's beautifully open systems (except for all Macs).

#9: Adobe Flash is too much of a power hog to run on any of Apple's battery powered devices (except for all Mac laptops).

#8: Very few applications are affected by Apple's rejection of Adobe Flash (except for just about all social games, just about all enterprise software packages with modern interfaces, and just about all financial services and health and education web site applications).

#7: Very few web sites are authored using Adobe Flash, as compared to HTML5 (except for 85 of the top 100 web sites in the world).

#6: Very few iPhone, iPod, and iPad users would like Apple to support Adobe Flash (except for an overwhelming majority, including my son).

#5: The Apple community has, over the years, benefited very little from Adobe's support (except for just about every graphic designer in the world, who generally use Adobe products on Macs).

#4: HTML5 will someday (in several years) be able to do just about everything Adobe Flash does today.

#3: Someone managed to hack up a very old game to be able to run in HTML5 (in a lab experiment).

#2: Adobe has not backdated any stock options to any Apple executives.

#1: Apple does not need to provide reasons for its decisions about what software they will allow you to run on a device you own.

The BI recession?

Bob Evans described a customer claim that we are in "The SAP Recession" (quoting from an article from Reuters). According to his opinion piece:

Timken Co. CEO Jim Griffith said, "I call this the SAP recession" (and Timken's an SAP customer!). But despite how it bad that sounds, Griffith intended it as a compliment. (I think).

...

"I call this the SAP recession," Griffith is quoted as saying, "because companies have a much better control over their inventories and so our customers did a much better job of reducing inventories immediately when they saw the demand go. And the further back you were on the supply chain, the more that hit you."

There is a lot to be said for this point of view. I was at a major consumer products manufacturer in an earlier decade, when tough times hit our business. The tough times hit the company hard, because we did not have the systems (or standard agreements!) in place to cut hard and quickly - on discretionary spending, capital outlays, supplier contracts, or employee hours. As a result, our suppliers and employees were buffered from the effects of the downturn. They could see the hits to our earnings and thus predict the arrival of the "rainy days" ahead - they were able to adjust their spending and expectations, softening the blow of our customers' hard times throughout our supply chain. Given that we were not lagging other large companies at the time in our IT systems, it is likely that similar scenarios played out across the economy, leading to a much softer, slower, and economically more efficient deflation of the economy.

Jim Griffith has a good point, although I think he is misplacing the beginning point of this new era. Due to Y2K concerns (and good marketing on the part of SAP, other ERP vendors, and their systems integration partners), many companies implemented integrated enterprise systems for employee management, budget control, financial controlling and reporting, purchase order management, supplier contracts, and other enterprise spending vehicles in the period leading up to January 1, 2000.

Shortly thereafter, the global economy (and the US economy in particular) faced a significant downturn. For the first time in a recession, companies had the tools to clamp down hard on spending - tools including ERP systems (including purchasing, travel, budgeting), reporting and BI systems (for visibility and transparency), collaboration tools (such as e-mail and workflow approval), and business processes (for adjusting budgets, approving capex and opex spending, stopping all hiring and travel, and much more). Companies used these tools, and it seemed to me that the result was a much steeper decline into recession than ever before. I remember months that went by after 9/11 when there were zero jobs posted on job bulletin boards, no consulting contracts issued, and no employee travel approved.


2001 was the first cyclical downturn where most large companies had pretty good expense control capabilities, pretty good ability to adjust budgets on the fly, and pretty good ability to manage supplier contracts via ERP. In previous downturns, expense control was haphazard, but with SAP you could shut off employee travel (for example) in an instant. As a result, the downturn was more abrupt - the economic equivalent of program trading, but without a regulator that could turn off the program.

Every recession (and upturn!) after Y2K can be thought of as being accelerated by ERP systems like SAP. What has changed since 2001 is a pervasive use of business intelligence (BI) tools in most leading companies. Now, companies can not only shut off transactions, but they can analyze business performance such that they can identify (and efficiently/brutally execute) strategic business opportunities including facility consolidations and shutdowns, offshoring and outsourcing efficiencies, supplier consolidation, and even exits and shutdowns of poorly performing business units.

Perhaps this recession, rather than being called "The SAP Recession," should be called "The BI Recession" ...