SaaS and Non-relational Data Models Take on ERP

August 22, 2007 at 10:22 am | Posted in Uncategorized | 1 Comment

As Nicholas Carr reports:

As the founder and leader of PeopleSoft, Dave Duffield played a seminal role in establishing enterprise resource planning, or ERP, systems as the IT engines of big business. But then, in a hostile takeover, the enterprise software giant Oracle yanked PeopleSoft out of Duffield’s hands. Now, Duffield’s back in town, and he’s gunning for ERP.

…

Today, Duffield’s new company, Workday, is announcing an expansion of its suite of software-as-a-service business applications to include not only human resource management – its original offering – but also a set of financial management services, including accounts payable and receivable, general ledger, and reporting and analysis.

…

It’s an alternative to ERP, rather than a Web-delivered version of ERP, argues Nittler, because the system’s software guts are entirely different. Rather than being tightly tied to a complex relational database, with thousands of different data tables, running on a separate disk, the Workday system uses a much simpler in-memory database, running in RAM, and relies on metadata, or tags, to organize and integrate the data. Having an in-memory database means that the system can run much faster (crucial for Web-delivered software), and using metadata rather than static tables, says Nittler, gives users greater flexibility in tailoring the system to their particular needs. It solves ERP’s complexity problem – or at least it promises to. (For more on the nuts and bolts, see David Dobrin’s whitepaper and Dan Farber’s writeup.)

I’m interested to see how this works since it points to two trends that are somewhat experimental and show great promise: Software as a service (SaaS) and a movement away from relational databases. My colleague Peter O’Kelly has been working on a report on XQuery and following XML databases for sometime. What Workday is doing is not an XML database (it gets persisted to a relational database for contingency purposes), but it’s an example of an object-oriented data store. While the whitepaper mostly focuses on speed, I think advantages will emerge due to the capabilities of the new model. It is difficult for designers working with a RDBMS-enabled system to think of new ways to synthesize and connect data that are not supported in their RDBMS model. Sure, sometimes users know exactly what they want (no matter how difficult to do with JOIN statements in SQL) and force them to figure it out, but designers won’t get too creative coming up ideas on their own that don’t fit their model.

When I was a developer and doing data modeling, I often worked backwards from the data model to think of functionality the system might need (such as pieces of the CRUD matrix missing) or that could be useful to supplement what the users told us in requirements gathering. What would a developer/data modeler come up with now if working from an in-memory object model? I can’t wait to find out!