There's been a lot of analysis lately about the death of the PC and the death of the enterprise. So introducing the possibility of the death of middleware makes for a good segue into SAP's March 9, 2011 announcement of a new road map of in-memory applications.
This is the stuff Hasso Plattner's been working on at his Institute since his retirement instead of playing golf. This is the stuff Hasso was going to hand to Shai Agassi on a platter before Shai went off to build electric-car charging stations and thereby become the twenty seventh most influential person in the world. (Oh Shai, what might have been.)
But I digress. There is some meaning to my "death of middleware" headline even though I don't believe it. Middleware basically exists because computers used to have 8KB of memory, kids. (Right, that's KB, not MB.) So, early programmers had to figure out how to get just the data and instructions that were needed into memory just when they were needed. At first these instructions were on punched paper tape, then cards, then magnetic tape 3/4" wide, then... well you get the picture. Eventually someone figured out that the paper, cards, tape, etc. didn't even have to be in the same room... or on the same continent. Along the way, someone cutely called the software that coordinated all this to and fro "middleware," the stuff in the middle between the hardware and application. (Email me if you want to argue that it means in the middle between the user interface and the database. You can probably even find where I wrote that somewhere.)
But what if the size of memory was not a restriction? Programmers would have written the applications in an entirely different way. Big ERP systems would work like Intuit (INTU) Quicken. Welcome to the new SAP R/3 or whatever SAP is calling it these days. SAP says the roadmap consists of:
- New analytics that analyze massive amounts of data in real-time (the whole idea of data marts instead of data warehouses was a result of the same memory limitation described above viz a viz transactional apps).
- New transactional applications and rewrites of SAP's existing solutions that also take advantage of real timeness.
In theory, this will reduce redundant layers and let SAP in-memory-technology customers do operations, planning and analytics at the same time. SAP claims that it
"... eliminates the need for data caches, aggregations or (even) batch processing. Eventually, in-memory computing technology will help customers reduce their database usage and reliance on disks (or paper tapes or punched cards or magnetic tapes so heavy it took two operators to mount them), leading to a (sic) fewer layers and a simpler architecture." (parenthetical phrases added by Byron)
There are a lot of implications in this for virtualization, mobility and even -- I hate to promote the term -- cloud computing.
As per the press release linked to above, SAP announced some instantiations of this approach as well. Interestingly the list mirrors the first analytical/optimization applications announced by SAP in 1998 or so. There is some logic to this because such things as planning and optimization of business processes are exactly the sorts of things that you want the actual line managers and professionals working on in real time... with no IT people or business analysts in between. There's no real demand for running receivables against the ledger this way (although you will be able to).
So not only is middleware really not dead (I just wanted to suck you in), neither is ERP.
-- Dennis Byron