An Interview with Christof Wittig: CEO db4objects and President ODBMS.org

In the continuing series of interviews focused on databases, Christof Wittig contatced TxtEdMacs describing revived effort to set new specifications for Object databases. Soon afterwards Christof accepted an offer to be interviewed on the topic and TxtEdMacs, who had tired of the usual set of resultant evasive, market speak jumped fully into the effort. Unfortunately for Txt., instead of being able to show off he was used by Christof to mop the floor. To say the interview was refreshing and direct is an understatement. So read on.

Reader Introduction

In our continuing series of interviews pertaining to database products, we are widening our view to include an organization that might deliver the next important advance in database functionality and power. Christof Wittig, our interviewee, is the CEO of db4objects and is the president of ODBMS.org. He brought to our attention the setting up of a group: "Object Database Technology Working Group" within the Object Management Group [OMG] that has taken over the work of a disbanded: Object Data Management Group. The goal of the present effort is develop a new set of specifications for databased systems that use object oriented methods for the OMG [ see announcement]. It should be recognized that this effort itself will produce no specific database product either free or commercial; this is a standards specification effort.

LXer Having given Christof a short explanation of the standards we employee in these interviews with Database vendors provided some additional information:

Christof I appreciate your intro to your methodology.

Perhaps you allow me to point out, that we're not proclaiming the next big thing (and then disappear after 1 year), but actually work on one of the most fundamental problems in the IT industry (more below), in a quiet and problem-oriented manner, picking up the threat where the 1st gen ODBMS vendor have stopped after they burst together with the Web bubble in 2001. [LXer: His role in ODBMS.org.]

Being open source, we don't have a marketing department or PR firm. What we do is to build product in close collaboration with users and thus build a *massive* user and usage base (in 15 months, we have won 11,000 registered developers to join our community and many more undisclosed ones that are behind the 300,000+ downloads). >From this user base, we as a company, capitalize on providing complementary licensing options and services that make the platform useful to a broader audience. [LXer: As CEO of db4objects.]

LXer With that introduction behind use, lets begin our questioning.

Interview Questions:

In my reading about databases, I learned the relational model cannot solve the product breakdown problem where a complex product uses identical components, however, differing in physical location. I also noted on your site that the goal now is to enhance the relational model by taking care of what is called "... the object-relational (O-R) impedance mismatch ...", by having the object databases supplement the relational database systems.

Could you explain in essentially layman's terms what exactly and an "impedance mismatch" might be? [Please do not use electrical engineering terms if they can be avoided.]

Christof I think, Esther Dyson gave the best explanation, so I open with her words:

"Using tables to store objects is like driving your car home and then disassembling it to put it in the garage. It can be assembled again in the morning, but one eventually asks whether this is the most efficient way to park a car."

In an object-oriented programming language environment like Java or Microsoft's C#, you work with data structured in objects. When it comes to storing this data e.g. on a server's disk drive, you are usually forced to "map" these objects into relational database tables of SQL-based products such as from Oracle, MySQL, or Microsoft. This mapping process is extremely tedious, adds many lines of code without adding any value to the application. The O/R mapping increases development cost and decreases software maintainability through added complexity and sheer volume.

Apart from this technical mismatch, there is also a "cultural impedance mismatch", as formulated by Scott Ambler and other proponents of Agile and eXtreme Programming. Developers start to design their (relational) database model first and consequently fail to capitalize on the benefits of truly object-oriented data processing, which is particularly suited for distributed and web-based applications in agile, evolutionary environments.

LXer Could you provide other "real world" instances where an object database can solve a problem that is impossible to an unenhanced relational database?

Christof Yes. As a general rule of thumb you can say: The more complex the object model, the more you are driven into either writing your own database solution (and 50% of the developers do that in the embedded space, according to VDC research: see this) or into looking at persistence solutions beyond relational databases, such as XML or object databases.

Let me again use a quote, this time from a customer, Altana Pharma, a global-40 pharmaceutical company:

"We were experimenting a long time with relational databases, XML serialization, Castor, and with Hibernate to get the job done, but didn't see the results in response time and flexibility we expected for our native Java environment. We selected db4o because it meets our needs exactly for native persistence of complex objects. I wish we had discovered db4o 2 years ago, because we would have easily shaved 6 months off our project time." (Martin Kraus, project lead)

LXer In my reading again, Ellison intervened to veto early adoption of OO into the series 8 Oracle RDBMS. However, in one of the 9 series it was openly proclaimed that Oracle was object oriented. Now with the more recent release of the Oracle 10g, much note is made of its support for Java and scripting connections with no obvious mention of its OO capabilities.

Christof Sorry, if I do not answer all of your questions myself, but Oracle gave such a nice quote about the gravity of the problem, that I cannot stop myself sharing it with you...

"Building Java applications that use relational databases is perhaps the single most underestimated challenge in enterprise development today. More projects are delayed, under-featured and difficult to maintain because of this underestimation. The problem lies with the use of fundamentally different technologies - The object world and the relational world do not match up." ( See)

LXer Hey, Chris slow down - you are going too fast. That was just the lead in to my question!

My question is: are the main stream commercial vendors using OO as another marketing buzz word without full recognition of its power?

Christof Yes.

Object-oriented features in relational databases are just a gimmick. No serious developer uses them.

[LXer:(Editor: Christof's words here, Txt. is lost)] So what do people use to overcome the object/relational mismatch today?

Christof The only serious, widely used solution for the O/R mismatch other than object databases are object-relational mapper (ORM) products such as Hibernate (JBoss), Toplink (Oracle) and Castor. That's where the quote above comes from - Oracle stated this when they acquired Toplink. And apparently they now need to buy JBoss for something like $500M to get hold of Hibernate, the leading O/R mapper, an open source product, that has outcompeted Oracle in this very hot market. (Why would they buy Toplink and Hibernate, if Oracle itself was OO?)

However, the ORM's additional layers add new costs for developing and maintaining software. They add complexity and cost performance. They are no option in many zero-admin environments, e.g. for applications that run on a PDA, where neither Hibernate or Toplink provide a solution to this "single most underestimated challenge". db4o, the leading open source object database, is up to 44x faster than a Hibernate/MySQL stack, as recent benchmarks have shown: see benchmarks.

As an example, Boeing embeds db4o into their aircraft. They just cannot put an Oracle 10g, an OR-mapper and a DBA on board of each one of their planes. And why would they? For less then $100 per instance, they get exactly the right persistence solution for this classical zero-admin environment.

LXer If I am correct in holding that impression, how (or can) that use be molded to become more forthright and informative to the customer's advantage?

Christof Oracle is strong with CIOs and their DBAs. They sell top-down.

But they are not so strong with developers. Developers are at the receiving end of Oracle's sales process. Developers accept Oracle like they accept bad weather, but they don't love their products. Why? Because using Oracle in a Java environment, for instance, makes your life harder, not easier.

Developers have to learn and use *two* languages to use Oracle's products: Java/.NET (the object-oriented programming language) and SQL (a language designed for DBAs). SQL is string-based and alien to Java/.NET development environments, which makes it very cumbersome to do software changes, automatic refactorings and use all the tools that make the life of a developer easier.

Just compare this to yourself, Txt.: Would you be a better journalist when writing in two languages, English and Chinese, constantly switching forth and back in the same sentence? Your spell checker wouldn't work. Your keyboard would not be optimized. And, above all, the elegance and power of your words would probably deteriorate, assuming that you are stronger in one language than the other.

LXer Hey, I am not even good at English. No, no please don't mention a spell checker not working.

Christof Object databases speak to the heart of the developers. With a native object database, developers remain in one language and one paradigm - the OO programming language. With an object-oriented persistence solution, OO developers can do their job better and faster. They can go home to their children earlier.

Marlon Machado, Senior Enablement Architect at IBM (a relational database giant, producing DB/2) writes: "I am really impressed with db4o. The database is so easy to use - especially for embedded applications. db4o doesn't require any administration. It just works! And db4o's native object support makes it very easy to integrate with my Java applications"

[LXer:(Ed: well it's Christof again with his lips hardly moving and Txt? ... forget Txt.)] So it's "War of the Worlds" between corporate IT and developers?

Christof No, but it is a clash of cultures and stakeholders - and the developers are gaining ground in an increasingly complex technical environment! The entire, developer-driven open source movement is only the tip of the iceberg.

LXer Why is there little obvious interest then for object databases within the groups producing the increasingly competitive free relational database products?

Christof Relational databases and object databases target different markets, different applications, provide different benefits and speak to a different audience.

Relational databases are ideal for server-centric persistence. In the data center, there is one abstracted data storage, and many applications work against them (often mitigating the O/R mismatch problem by adding ORMs). The database is *above* the application. The decision maker to select and "own" the database is corporate IT, represented by CIOs and the DBAs. It is not the application developer.

Oracle "owns" the CIOs and locks in the DBAs by securing excessive renumeration and increased job security for them. In fact, even ERP-giant SAP is forced to support Oracle databases, and 65% of their systems run on databases of their fiercest competitor. They don't do that voluntarily, I can tell you!

So why would Oracle & Co. give up what makes them successful, by putting the application developers in charge?

[LXer: (Chris, is your hobby ventriloquism?)] So how do object databases differ from RDBMS today?

Christof Modern, 2nd generation object databases are ideal for client-centric or "embedded" persistence. They are made for developers. They are actually more of a developer component and get embedded into their products or applications. They are invisible to the end user, which shifts the decision power into the hands of the developers. Do you know what RTOS or database product is embedded in your car's control system?

Other areas, where object databases excel, are vertical markets such as RFID/realtime systems (Progress' ObjectStore is strong here) and financial applications with large data feeds of very complex object models (GemStone brings a lot to the table here). The database decision is ruled by hard technical feasibility tests, run by developers, not "brand", FUD and free golf courses for CIOs.

[LXer: (only the attribution changed)] And how is that different from the 1st generation object databases of the 1990s?

Christof IMO, the biggest mistake of the 1st generation object database makers in the 1990s was, that they thought, they would become the "next Oracle" and replace RDBMS in the data center (admittedly, this is the jackpot with more than 80% of the total, $15BN market). But they didn't have the power with the CIOs nor the compelling benefits to make enterprises switch their core data architecture.

Christof 2nd generation object databases like db4o target developer first, effectively leveraging the open source community (which is a developer community) to create a massive user base in grassroot, hidden applications, invisible to the Fortune 500 CIOs.

Now, with fast growing user adoption, the OMG starts to standardize object database technology as we see it *used* today. This again will benefit developers, making their lives easier by providing interoperability and fostering the adoption of object databases even further.

[LXer:(another attribution switch)] What's the role of ODBMS.ORG in this process?

Christof We, at ODBMS.ORG, work to educate a new breed of OO young developers to think out of the box. We help them to recognize how they can differentiate themselves from the legacy herd by employing more efficient persistence strategies, that truly fit the object-oriented paradigms.

That's what you read from this new breed of empowered developers in Microsoft's own forums: "db4o, a great, open source, OODB that can beat SQL Server anytime when it comes to persisting native objects. No mapping, no nothing, store your object model, not a flat, relational model. It supports native queries (query in native C#). Anyways, MS is still too hung up on the old RDBMS product and it shows. So 80's"

Or in short: "You're developing the future, guys!"

Specifically, the ODBMS.ORG association, a non-profit backed by Progress, GemStone, Versant and db4objects has build the educational and research portal ODBMS.ORG, where free resources are provided through a panel of 75 internationally recognizable experts.

Philippe Kahn, the founding CEO of Borland, calls the "ODBMS.ORG portal a mission-critical resource for any serious 21st century software professional. It is indispensable, and a key element in promoting state-of-the-art software craftsmanship."

I have nothing to add to that!

LXer(This time in his own words)] Wow, give me some time to think and I will be back with a few more questions. My head is spinning.

Follow up Questions:

Lets begin with my public admission of bias: I am one of those old, data centric types who tends to think in a linear fashion, hence, I have some problems with both RAD and OO on both a practical and theoretical levels.

Viewing your response to the first question asked in the previous set, you cited [ http://www.odbms.org/experts.html#article3 ] where the techniques of Xtreme (or RAD) programming were the basis of much of the criticism of the relational database mind set. While I find some of the techniques employed in RAD programming attractive, e.g. the team approach where one types the code while the other reads with near immediate testing of every change and then trading roles to avoid fatigue seems potentially smart way to generate code rapidly that works. Moreover, coding errors are more likely to be caught sooner than where individual programmers code, load change and retests full application. However, again from my reading RAD has not worked well when the project is large and the path has been unclear.

Now wait for the real question:

Christof I am not in a position to answer this in a general statement, and I think this would lead to a whole different interview (another one!).

LXer I accept your generous offer of a second interview. Thank you.

Christof I am in a position, though, to measure the benefits from RAD vs. waterfall comparing the way, we at db4objects work (RAD combined with distributed, open source processes, more here with the way, my first start-up delivered specialized ERP applications with a conventional software development model.

The productivity gains from RAD/XP were enormous.

I think, the development model has to match the requirements from the markets. If you work for large corporate IT, you often don't need quantum leaps in innovation, but rather predictable, incremental improvements or integration works. Those are often a good fit for the waterfall model.

If you develop an entirely new breed of products and change paradigms all over, and/or need to adapt software to customer requests, changing markets or rapidly evolving feature lists due to heavy competition, XP is a great fit, because it contains costs and shortens time to market.

So I'm not claiming, that we all should do RAD and XP. But I say: You should have a choice and not be constrained by your database. Adding constraints to an optimization can *never* improve the outcome.

LXer Hey, you're going too fast, here's the question:

Can you cite a project where the OO database combined with RAD has worked well on a large project that was not fully designed and/or obvious at the onset?

Christof Yes, I can give you a very good example, one where RAD is simply the only choice:

BOSCH Sigpack, world market leader in packaging robots (packaging cookies, semiconductors, cosmetics etc.), has to customize every single installation to the specific customer's needs - apparently, all customers package different products, don't they? So, from the time the order comes in to the time of the start of the system (called "the commissioning time"), the engineers have to rapidly adapt the very complex system (39,000 objects in memory) to customer needs - in a way that just cannot be specified ad ante.

You have to use RAD. And BOSCH chose db4o as their embedded database.

The result? "The use of db4o on the data-backend has helped us to achieve a time-saving effect of at least 10% on each project." says Sebastian Hubrich, the implementation manager.

Now, did you believe that your database choice would potentially put you in an advantageous (or disadvantageous) position to deliver 10% faster than your competition?

Back to my point above: In corporate IT, this might not be the #1 criteria. At BOSCH, the "biggest concern is shortening our commissioning time, and db4o gives us the ability to do that."

LXer [Question text removed, don't want to give him time to study up to get the perfect answer. This one is a tough one, notice he skipped it?]

Christof, come back you shot by this question. Damn, we will catch it on the next interview anyway. Back to the questioning.

As mentioned above, my background experiences are as a data type developer where I have a hard time seeing the advantage of an OO database as the key support for the applications of the type I have worked. For example, I do not think most clients would be too happy seeing an evolving unpredictable return each day when they are placing financial bets on equity performance. Hence, a design of a structure to provide a stable, predictable storage location with agreed upon processing parameters using a relational design does not strike me as wasted efforts. Moreover, beside the equity trading markets there are external, independent parameters that must be revised aperiodically, e.g. base currency loan rates. Furthermore, I do not see the advantage an OO holds over a relational database when the incoming data arrives within several differing formats (text, spreadsheet, custom format, etc.) where new clients invariably refused to conform to agreed upon formats for trade code ids. So too do relational model data evolve in time solving those problems. Finally, SQL is simple compared to even the scripting languages and works well returning correct, stable result sets.

Christof Object databases are not meant to replace server-centric, multi-tier architecture with lots of legacy. However, a new generation of OO products come to market, and with it, a new breed of developers emerges, that understands how to work with OOP in order to slash cost and development time. These products can be stand-alone or complements to legacy systems.

LXer No, no that's not ...

Christof Without being defensive, let me rephrase what you say: "It is quite good that I am so constrained by SQL, so I cannot make so much errors." But shouldn't your architecture and your development model take care of your errors rather than your database forbidding you to use the full benefits of object-oriented programming, such as inheritance and polymorphism?

But before we argue over this - and since I am only a vendor, not a user - let me just give you the quote from a senior software architect of a major UK equity house: "The technology from db4objects has dramatically shortened the development time, as mapping from domain models to persistence is now one single step instead of three. I believe I shaved at least four months worth of development using the object database approach, as I know how long it takes to engineer the equivalent solution using traditional technology... Before I settled for db4o, I evaluated Apache Derby, MySQL, Daffodil One$DB, Sqlite, and Berkeley."

LXer Argue? I don't even get a word in edgewise, ah let's get back to the question:

Given this type of an application where financial exposure and risk is high:

Do you think that the separation of design of the data storage based upon the reporting requirements can be easily bypassed by OO technological methods? If there is a quibble regarding easy, lets say would it be worth the risk?

Christof From OO, you can always pipe your data out to XML and use a wealth of tools to work from there. And lately, Crystal Reports has announced to develop true object-oriented reporting tools, too.

LXer Now I know you are Not a developer - you would not have mentioned Crystal Reports with a straight face ...

Christof But in general, I would concur: If ad-hoc reporting is important, SQL is better. SQL was designed for ad-hoc reporting.

And SQL was not designed for software developers, that find SQL a non-native alien to their OO programming language. SQL decreases their productivity and makes their software more difficult to maintain. Proof of that is Microsoft, the world's #3 database maker, just announcing the LINQ Project to provide "language-integrated queries", abolishing SQL strings.

LXer Would you recommend an OO database as part of such a large system that pools date sent by investors, including hedgefunds, that trade rapidly in a wide array of financial equities and in differing equity markets?

Christof I don't recommend anything. I am not a salesperson.

I am just here to help all these 1,000s of developers, that turn to object databases every month, and that desperately need a persistence solution that fits their OO environment.

The members of this fast growing community have much smarter and more innovative approaches using OO to the fullest extent possible than I have. I shared some of their stories with you. Here is another one:

"Our projects do not involve millions of records, but need complex and flexible objects. Anything with SQL writing would be a nightmare to use. We looked at object to relational database mapping. It did not save us much time and required us to derive all objects from their model. It was not good! We then found db4o. We don't see anything else we would want to use." Dominique Toppani, Lawrence Livermore National Labs, Biotech division

And I could go on forever.

By using an object database, you can slash development cost, go to market faster, use less memory resources (think of PDAs), and create better maintainable software code.

If those are not the key criteria for your database decision, then you might as well use SQL, which will continue to do a great job in many - but not all use cases out there in the industry.

LXer Now drifting away from our main topic, I would like to spend a little time asking questions about your GPL product: DB40. Having gone to the DB4O site, I noticed several things: the supported languages are sparse, two of which I suspect are derivatives of Microsoft's C# that supports only their proprietary web frame work and mono, which is by design meant to support that same framework, albeit in an open manner. Moreover, in the case of mono one is watching an evolving language. The only other choice was Java, while easier to read and code than either C or C++, is not for the faint of heart programmer such as myself. So these questions come to my mind:

Could DB4O be used as part of a LAMP project? That is, would you recommend it?

Christof No. db4o is native to Java and .NET. That's where db4objects has identified the biggest demand for an embeddable, native persistence solution. LAMP provides a great stack for web-oriented development with the wonderful MySQL database product. But Boeing would not use LAxP to run their aircraft control systems, would they?

As for C and C++: That is the past, not the future. There are 100 vendors to provide persistence for them, no need to invent something new here. The future is OO. And commercially, that is Java and .NET today. Java is ultimately backed by IBM and .NET by Microsoft. I would not count out those players when looking at the future of IT. And if you look at Eclipse and JBoss, Java is moving more and more into the open source space, making it compelling for a broader set of developers who might still choose LAMP today.

LXer Somewhat apropos to the last question, as part of this series of interviews that included the CEO of MySQL AB [ http://lxer.com/module/newswire/view/47359/index.html ] Marten Mickos said he did not see his product in competition with Oracle per se, since essentially his product fit in well with new applications. Here is the salient quote: "... most of our deployments [are] in areas where there was no database before. Either the application didn't use a database earlier, or the application is new...". Now from the comments above and what I have read on your site:

Why isn't your database displacing MySQL in the same application space?

Christof MySQL is strong in the LAMP stack and has always been especially popular with website developers. It now moves upmarket and is, at least at the low end of the enterprise market, a threat to Oracle -- why else would Oracle have bought Innobase, if MySQL wasn't a threat to them?

db4o is geared towards the Java and .NET stacks, and focuses on embeddable, zero-admin environments.

That is not the space where MySQL is strong, and where MySQL is moving into. To really work properly with MySQL in a Java or .NET environment, you need an object-relational mapper like Hibernate, because MySQL and OOP are inherently incompatible to each other, such as any other relational database.

As a result, Marten and I are good friends. We work together to refine the open source business model to compete against the complacent, closed-source giants out there, that charge excessive license fees for their DBMSs. This is a $15BN market, so I think there's room for the two of us.

LXer I have plied you with enough questions that we might consider this to be a complete interview. However, since the project you cited is an on going effort that has been recently started, can I get your promise for a second round about the time the Object Database Technology Working Group is ready to make a statement of their status/progess/final report? [Since I am certain you have had fun with this, I will pencil you into our schedule - OK?]

Christof Sure.

Summary

When last seen TxtEdMacs was seen wandering into a nearby woods mumbling about the need to learn Java and some claim hearing a plaintive wail about him not being a good script coder in either Perl or Python. However, the latter were known to be unreliable sources. Hence, we look forward to the next bout ... I mean interview with Christof Wittig our guest covering Object Databases.