Mapping a New Harbor for 3000 Data

You recently took back some operations from HP early this year. How much effort did your company have to deploy to get everything transferred? What was it like to regain control of the sales operations?

In real life it was not that much of a difference. Eloquence used to be a channel product, so there was little marketing and sales activity (stealth marketing at its best). We actually took responsibility for the sales and distribution in 1997 and provided that as a service to HP. There was little change for us or our partners.

It is a different story to market a product to new customers rather than existing customers. We are now addressing HP 3000 customers and ISVs who likely have not been not aware of Eloquence in the past.

It has been difficult to purge 15 years of HP history from the product and documentation. We enjoyed a unique relationship with HP Germany in the past, and it’s been part of our mindset. It felt a bit odd to remove it. Those of your readers that have been working with HP for ages might be able to relate to this.

How much of the Eloquence customer base is using the product as an ISV, embedding the database into their applications?

Close to 100 percent. There are few customers who either wrote their own application or ended up with a customized package and went from there.

Besides migration, we consider it difficult to market an IMAGE database as a general tool. From my point of view IMAGE has its best value as part of a business solution. It works nicely for our existing partners.

IMAGE gets used because it is an efficient and effective solution and does not cause administrative headaches. An Eloquence-based solution often ends up sitting in a corner, working for years without an administrator. It takes care of its own.

Is your database a better match with Itanium than SQL Server, or Oracle?

It’s the same as on other platforms. Itanium might look different to us, but so did PA-RISC 20 years ago. We consider the Itanium an interesting new architecture that all applications and databases will benefit from.

Is Itanium ready for software developers to start deploying and developing against today?

We found HP-UX 11i version 1.6 was pretty complete and stable. With the release of HP-UX 11i version 2 (B.11.23) HP-UX on Itanium now matches the functionality of the PA-RISC platform. HP did a great job to make sure the PA-RISC and the Itanium platform are virtually identical, and we found few problems.

Porting Eloquence to the Itanium platform was almost trivial. A lot has been said about the importance of optimizing your applications on Itanium. We found the HP compiler did a good job out of the box. Eloquence on Itanium actually got faster than on PA-RISC by just recompiling. Optimizing for Itanium has the potential to gain additional performance, and we will be able to integrate Itanium specific optimizations over time.

HP-UX has the advantage of supporting both 32-bit and 64-bit applications on Itanium. The data format is binary compatible to PA-RISC. Judging from our experience I would assume a port to the Itanium architecture should not involve much difficulties and is worth having a serious look at.

HP-UX also includes a PA-RISC emulator that allows to execute PA-RISC binaries on Itanium. While there is a noticeable performance impact, it is helpful to get you started and usually good enough to run the odd tool which has not yet been ported to Itanium.

As PA-RISC is slowly phased out and with the new HP-UX release coming up it is now easily possible to tap the long time benefits of the Itanium platform.

How much of your business growth in the last year has come from 3000 sites? What do the newer converts to Eloquence have to say about how the software compares to IMAGE?

Until now we have seen very little revenue from HP 3000 customers. Most end-users are in an evaluation stage and we do not expect Eloquence sales to HP 3000 customers to become significant before 2004. This is different from ISVs, who are now in an advanced stage of porting their own applications.

We have worked with a number of ISVs and customers and have received very positive feedback. Once people get started with Eloquence they appreciate its ease of use and compatibility.

We haven’t reported much yet about the Business Basic inside Eloquence. What do you think the customers are likely to do with this language? How is it integrated with the database?

On the HP 250, Business Basic was the only supported programming language and it was an outstanding implementation at that time. The IMAGE database is fully integrated into the programming language. Eloquence retained all its strength and improved on it. We added a graphical development environment on Windows (IDE), multiple user interface options (including Terminal support, a Java based GUI and the Web) and remote debugging options. The Eloquence implementation is cross platform and provides binary compatibility between platforms.

Being a descendant of the famous HP Business Basic it should be familiar for people who have used Business Basic previously. You get a powerful yet easy to use programming language with the database.

What was the hardest part so far of emulating TurboIMAGE?

Well, it is important to understand that Eloquence is not an IMAGE emulation. IMAGE functionality is implemented at the database core and we only emulate the TurboIMAGE specifics. The technological foundation of the Eloquence database uses relational database concepts.

A number of applications rely on specific behavior beyond the documentation. Eloquence already supports most of the specific behavior, and we will implement whatever is required. Taking care of all the details is important for us.

Have you found TurboIMAGE functionality that was technically sophisticated, but virtually unused in the customer base? How did you make decisions about which IMAGE functions to emulate?

Actually one of the virtues of the HP 3000 is the high level of integration and experience people have gathered over time. Instead of looking at a single piece of functionality, it is worth noticing the value the platform offered for its market.

One thing that comes to my mind is dynamic transactions. From our experience the majority of IMAGE applications make limited use of dynamic transactions like DBXBEGIN, DBEXND and DBXUNDO. I assume most applications have their roots with MPE/V, where dynamic transactions did not exist. Eloquence supports and extends on dynamic transactions while removing most of the restrictions.

Where do think your product can compare favorably with offerings from larger companies, and in what areas can you see room for improvement?

Eloquence serves a different purpose than Oracle and SQL Server. Eloquence was designed with IMAGE applications in mind. Its main purpose is to run IMAGE efficiently.

While Oracle and SQL Server are good general databases they are not particularly strong at implementing IMAGE. For the purpose of replacing IMAGE, Eloquence is often a number of times faster. It is also less expensive and more compatible.

Even if your strategy is to eventually move to a mainstream relational database, Eloquence enables you to move to the new platform quickly and continue to run your business. At that point it’s up to you to evaluate further steps. The relational side of the Eloquence database has traditionally received less attention. We will focus there in the future and intend to combine the strength of IMAGE and SQL.

How long do you think HP 3000 customers will be adopting Eloquence?

If you look at our history, probably for some time to come. Eloquence was initially intended as a temporary solution to move quickly to HP-UX and then allow VARs to re-write their software.

Well, it turned out that it worked very well for everyone and there was little need to look for alternatives. So we eventually became a permanent temporary solution. We are now close into 15 years of Eloquence and we expect to do well 10 years from now.

How much of a factor will price of the target database be in deciding where to move HP 3000 databases? How does your product compare on support costs?

We expect that price is a differentiator. Eloquence is attractively priced for small to medium sized businesses.

We have a range of different support offerings which cover different requirements. Product patches are free and there are support resources on the Eloquence Web site. Software updates are at 10 percent of the list price, call level support prices depend on coverage, starting at $50 per month for end users.

In addition we started to create a network of partners to provide worldwide support. In the US we have recently closed an agreement with Allegro Consultants in Cupertino to provide support and R&D services.

Can your smaller firm win the hearts of the 3000’s smaller and midsize customers, because you’re more like them than Oracle or Microsoft?

Customers consider using Eloquence if it provides a value for their business. Dealing with a smaller company could add some unique value on top of that.

We have earned good experience through a close cooperation with our customers and partners. We believe this to be a win-win situation and will continue to work this way.

In the long term, we intend to adopt some of the open source benefits and release parts of the Eloquence source code (subject to our contractual obligations that remain with HP). This will enable easier customer modifications, and in turn we hope to benefit from contributions of the community.