I got a couple of feedback items and an a couple of emails re:the prior post on SAP and Workday. One of the questions was on the relative differences in approach that SAP and Workday are using with regard to in-core/memory resident technology.
I had a lengthy conversation of this technology with SAP founder Dr. Hasso Plattner around 2005 when the company was starting work on a new application suite code-named A1S. We now know this product line by the name of Business ByDesign. Coincidentally, Workday was founded at the same time and it was using in-core database technology as part of its software design. (FYI – SAP’s Plattner has just authored a book, In-Memory Data Management. I just got a copy of the book this week but haven’t read it due to time constraints and client demands.)
SAP’s got a million things going with their in-memory technology and it is definitely not limited to just Business ByDesign. HANA, Business Objects (BOBJ), …. Some of their in-memory technology is self-developed and some purchased. While BOBJ had quite a legacy of using this technology prior to the SAP acquisition (and SAP had its own development efforts using it, too), they have continued to invest in and exploit both firms’ expertise and products.
At Sapphire 2011, SAP had a great contest event that showcased the best twelve in-memory apps built by SAP people globally after just 30 hours of development. I have no doubt that they’re making in-core db solutions a major priority for the company and see these as a way to drive value for customers. I saw lots of examples of this.
Workday has made in-memory db technology their primary database technology. This was a conscious decision of theirs from the beginning. Relational database technology is used predominately as a backup storage media for them. Because of this, Workday doesn’t utilize, to my understanding, subledgers in their in-core database. They keep source transactions in memory and can sort, parse, and restate the data in almost infinite combinations without any real effort. Moving relational database content to solid state memory without eliminating all of the redundancies is not only inefficient but it cuts down on how easily data can be re-stated into different views (for example, creating a daily set of books out of monthly subledger data can be hard unless the software goes all the way back to source transaction data and picks up adjustments made to all other subsystems along the way.)
Both firms are using the data in these systems to do amazingly fast inquiries and analysis. Of that, there is no doubt. Previous inquiries and analysis in other systems were either too time consuming to complete, infeasible or not technically possible. Workday’s inquiries can chase data throughout the system almost like a drill-around capability on steroids. I believe this is enabled mostly due to the in-core memory database being the principle data store.
Going forward, any vendor using in-core/memory resident database technology will have to address a new challenge: petabytes of data. Currently, most in-core systems must work within a 2TB (terabyte) limit. SAP specifically addressed this point on Tuesday. A SAP executive indicated that they can network 100 servers together and achieve a 200TB sized in-core database to search. That huge virtual server was still returning results in just a few seconds.
Moore’s Law will undoubtedly raise the 2TB limit soon to 4TB, 8TB, 16TB, and so on very soon. Petabyte data searching is key to processing mass data feeds from weather inputs, sensors, geographic coordinates, machine tools, energy consumption readings and many more non-accounting data feeds.
Is this a key technology? yes. Is this something that should be part of an ERP vendor’s solution set? yes. Have vendors figured all the potential uses of this new technology? not yet but the path will undoubtedly lead to some interesting results.