December 9, 2005

SAP’s version of DBMS2

I just spent a couple of days at SAP’s analyst meeting, and realized something I’d somewhat forgotten – much of the DBMS2 concept was inspired by SAP’s technical strategy. That’s not to say that SAP’s techies necessarily agree with me on every last point. But I do think it is interesting to review SAP’s version of DBMS2, to the extent I understand it.

1. SAP’s Enterprise Services Architecture (ESA) is meant to be, among other things, an abstraction layer over relational DBMS. The mantra is that they’re moving to a “message-based architecture” as opposed to a “database architecture.” These messages are in the context of a standards-based SOA, with a strong commitment to remaining open and standards-based, at least on the data and messaging levels. (The main limitation on openness that I’ve detected is that they don’t think much of standards such as BPEL in the business process definition area, which aren’t powerful enough for them.)

2. One big benefit they see to this strategy is that it reduces the need to have grand integrated databases. If one application manages data for an entity that is also important to another application, the two applications can exchange messages about the entity. Anyhow, many of their comments make it clear that, between partner company databases (a bit of a future) and legacy app databases (a very big factor in the present day), SAP is constantly aware of situations in which a single integrated database in infeasible.

3. SAP is still deeply suspicious of redundant transactional data. They feel that with redundant data you can’t have a really clean model – unless, of course, you code up really rigorous synchronization. However, if for some reason synchronization is preferred – e.g., for performance reasons — it can be hidden from users and most developers.

4. One area where SAP definitely favors redundancy and synchronization is data warehousing. Indeed, they have an ever more elaborate staging system to move data from operational to analytic systems.

5. In general, they are far from being relational purists. For example, Shai Agassi referred to doing things that you can’t do in a pure relational approach. And Peter Zencke reminded me that this attitude is nothing new. SAP has long had complex business objects, and even done some of its own memory management to make them performant, when they were structured in a manner that RDBMS weren’t well suited for. (I presume he was referring largely to BAPI.)

6. That said, they’re of course using relational data stores today for most things. One exception is text/content, which they prefer to store in their own text indexing/management system TREX. Another example is their historical support for MOLAP, although they seem to be edging as far away from that as they can without offending the MOLAP-loving part of their customer base.

Incidentally, the whole TREX strategy is subject to considerable doubt too. It’s not a state-of-the-art product, and they currently don’t plan to make it into one. In particular, they have a prejudice against semi-automated ontology creation, and that has clearly become a requirement for top-tier text technologies.

7. One thing that Peter said which confused me a bit is when we were talking about nonrelational data retrieval. The example he used was retrieving information on all of a specific sales reps’ customers, or perhaps on several sales reps’ customers. I got the feeling he was talking about the ability to text search on multiple columns and/or multiple tables/objects/whatever at once, but I can’t honestly claim that I connected all the dots.

And of course, the memory-centric ROLAP tool BI Accelerator — technology that’s based on TREX — is just another example of how SAP is willing to go beyond passively connecting to a single RDBMS. And while their sponsorship of MaxDB isn’t really an example of that, it is another example of how SAP’s strategy is not one to gladden the hearts of the top-tier DBMS vendors.


9 Responses to “SAP’s version of DBMS2”

  1. The Monash Report»Blog Archive » SAP’s technical strategy on December 9th, 2005 2:55 pm

    […] I just posted an extensive discussion of SAP’s technical strategy over on the DBMS2 blog. Key takeaways include: […]

  2. The Ponderings of Woodrow on December 14th, 2005 12:42 am

    SAP: All Roads Lead to SOA

    Last week, SAP held their annual Analyst Summit in Las Vegas, and Shai Agassi and a team of SAP executives outlined the company’s strategy and product road map in some detail. While I was busy being pitched by myriad public

  3. DBMS2 — DataBase Management System Services»Blog Archive » Application logic in the database on December 15th, 2005 5:46 pm

    […] 4. Besides everything else, I mainly agree with SAP’s belief that the DBMS is the wrong place to look for module interfaces. • • • […]

  4. DBMS2 — DataBase Management System Services»Blog Archive » SAP on SAP on April 8th, 2006 6:29 am

    […] Basically, they claim to be reengineering their whole product line for the new services-based architcture I keep writing about. And they insist this truly is a new platform architecture. In that regard, I buy into and agree with their pitch. […]

  5. DBMS2 — DataBase Management System Services»Blog Archive » DBMS2 at IBM on May 2nd, 2006 5:41 am

    […] I had a chat a couple of weeks ago with Bob Picciano, who runs servers (i.e., DBMS) for IBM. I came away feeling that, while they don’t use that name, they’re well down the DBMS2 path. By no means is this SAP’s level of commitment; after all, they have to cater to traditional technology strategies as well. But they definitely seem to be getting there. […]

  6. Text Technologies»Blog Archive » SAP’s “search” strategy isn’t about search on February 28th, 2007 3:07 am

    […] “What,” you may ask, “is a business object? Is it a database record? A group of database records linked by metadata? A web service?” SAP’s answer to that question is an emphatic “Yes!” As I’ve long documented, SAP’s technical strategy is heavily post-relational, with a strong DBMS2 flavor. Even so, I have trouble imagining how the “finding business objects” part will soon work, other than by the standard technique of text search that includes the indexing of relational database columns. […]

  7. The Monash Report»Blog Archive » Shai Agassi – a contrarian view on March 28th, 2007 7:05 pm

    […] My two-part take on SAP’s excellent architectural vision. (December, 2005) […]

  8. The Workday architecture — a new kind of OLTP software stack | DBMS 2 : DataBase Management System Services on March 24th, 2011 10:34 am

    […] has longstanding doubts about relational dogma, although not nearly to Workday’s […]

  9. Notes on packaged applications (including SaaS) | DBMS 2 : DataBase Management System Services on October 7th, 2015 8:28 pm

    […] has built on top of quasi-objects for a long time, although the underpinnings are technically […]

Leave a Reply

Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:


Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.