How a Database Keeps Apps from Stalling
December 12, 2011
This fall Michael Marxmeier put his continued 3000 support behind the first HP3000 Reunion, one of three gatherings he’s co-sponsored along with ScreenJet since the first in 2005, when Interex canceled HP World. The creator of the Eloquence database, he migrated the internals of IMAGE with a TurboIMAGE Compatibility Extension, while including expensive tools such as replication and high-powered indexing to Eloquence, a product priced for the budget-wary 3000 market. We wanted to check back eight years after we first introduced him in a Q&A to a market which didn’t know Eloquence well, but could already see value in migration to a solution which understood the HP 3000’s database.
Our first part of this year's Q&A addressed the changes in the Itanium market for databases, especially in light of the Oracle conflicts. We spoke to him via Skype on 11-11-11, the Friday before the 10th anniversary of HP’s pullout from the 3000 marketplace.
You’ve talked about an application stalling look like to an organization?
At some customer sites, they get through the migration. But after they’ve had all this effort to move, they don’t do anything more. The application is basically frozen at the point where the migration happened, rather than evolving. However, applications don’t exist in thin air; they’re there to fulfill a business need. As the business requirements and technology are evolving, if the application is unchanged, its value is reduced over time. If you just let it stall, in a few years it’s not longer viable to run the business, you can’t change things easily anymore, people have retired — all the typical things you see as problems in a legacy environment. Although you’ve migrated, you’re forced to replace the application with something off the shelf. That’s got its own pain to endure as well.
Evolving and continuing to provide value to your company’s applications is important. Most businesses are not stalled, and the technology environment certainly hasn’t. For example, tablets are becoming extremely popular. So the questions come, “Can’t we just give tablets to some of our employees, or make it accessible from the outside?” It’s a difficult question, one that is the responsibility of the IT team to respond to — mobile needs like that. PCI is another change you need to react to, and there are more coming down the line.
You have to have somebody to think a bit ahead, and be aware of what’s the industry is moving to, and find a way of incrementally moving your platform – instead of replacing it, or waiting until there’s nothing else to be done.
To get it right, you must have a few customers playing with this stuff before it’s released. Some enhancements are available for the current release as a patch, at the moment. The idea is to make these as public as possible, because we gain quite a bit of feedback from our existing customers.
We’ve found most customers have a small team running their shop, and it’s most beneficial to make incremental changes to their applications. This is something a small team can do, and it’s easy to find immediate use for these things.
What is the most desirable target for Eloquence in 2012, now that you’re beyond the adoption by ISVs? How do you make a case for an un-migrated 3000 customer to choose this to replace IMAGE?
We want to show — with technology like the full-text indexing of release 8.20 which will be our major 2012 release — what value makes sense for applications. What’s important about this full text indexing in Eloquence is that it will look like Google, where you it gets you a million results within a fraction of a millisecond. And we’ll have another release to provide this kind of major functionality.
For a customer on the 3000, our strategy is just as it has been before: Eloquence is a problem-solver, proven technology that covers every detail of a database and application migration, and it’s working in hundreds of sites everyday. It’s inexpensive, and it’s certainly the least painful migration option for a database. In going to Eloquence you don’t have to be afraid of getting stalled — because there’s something you cannot do which you did on the 3000.
What problems does Eloquence solve for a migrating customer?
If you stay on the 3000, you’re frozen in time. Eloquence keeps evolving. Even for emulator users, there’s a good question to be answered. There might be some workarounds to implement some of the technology changes like PCI and encryption, but does it make sense? Can you afford to miss all those changes the outside world might be demanding on your business and your application?
I think it will get harder and harder to get those working sufficiently well on the 3000. You not only have a stalled application, you have a stalled environment.
What’s the magic inside the TurboIMAGE Compatibility Extension? Is it essential to deploying Eloquence in a former 3000 enterprise?
There’s no magic involved, just engineering and attention to detail. Eloquence was always designed to support IMAGE applications. Our original customers used IMAGE, too. Eloquence is a second or third-generation IMAGE, I think. In the ‘90s, everybody was talking about moving to Windows. So we canned our first IMAGE implementation and rewrote from scratch, and we made sure that it uses the same technology or similar approaches we learned from relational databases. It was critical to us that IMAGE just worked, just as it did before. The core things the 3000 customer expects are already there. Then there were more engineering enhancements, to make sure we had things that turned out to be important in the migration scope. We found a solution to move a large amount of data around, for example.
How has the relational side of Eloquence evolved since 3000 customer migrations began in earnest in 2004?
In the past, relational had its own value, although few customers could tell you what it means. It’s a way the database is structured, and completely unrelated to the technology below it. What it means in practice is that relational is a mainstream database: SQL Server or Oracle. Using that definition, we are not a relational database. We are using a similar technology to a relational database, transactions, locking, so most of what runs in Eloquence is relational. But it doesn’t make sense to have another second-tier SQL database on the market.
Fortunately perception has changed, in that not everything needs to be relational. If your current 3000 database were emulated on top of a SQL database, would there be any value to it? Most likely, the answer is no. What is important is interoperability — that our customers can access their database like they would through a relational database like Microsoft Access, or though Java. We have a major customer running Visual Basic on top of Eloquence.
We think of what our customers actually need from us. There’s a relational view for Eloquence, an ODBC and JDBC driver. We’ve seen customers enhancing their applications by making use of SQL access to their database. But that’s not the primary way our customers interact with their databases.