Enterprise applications. Apps. Whatever is happening in front of the user, the odds are good that a database is behind it. And if you get the database wrong, it's highly unlikely that any application will be good enough to make up for the problem.
It's easy to lose sight of this in the flash and dazzle of the latest UX theory, but a recent experience brought the power of the database home to me.
It was a Sunday morning and I had made plans to meet a friend for breakfast. We were going to meet in a town a couple of hours from my house. When I got close to his city I pulled over, pulled up the address he had texted to my while I was en route, and plugged it into Apple Maps. When the app told me I had a 90-minute drive to the restaurant I dug into the directions and found that the map indicated a spot 70 miles from the area where I knew the restaurant had to be.
Next, I put the address into a third-party navigation app, and it suggested the same destination. I was about to decide that my friend had fumbled the address. Before I called him to check, I decided to try one more app. I pulled up Google Maps.
When I put the address into Google Maps, it gave me a time-to-destination of 12 minutes. That was more like it. The directions were good, but that's not where the story ends. It gets better.
When I drove into the parking lot of the restaurant (12 minutes later) the display on my phone changed from a map to the menu of the restaurant. Now, here's the good part: I hadn't put the name of the restaurant into the app. Just the street address. Now, what could have given the app builders the ability to integrate all those things? Oh, yes -- the database.
I've worked with -- and around -- databases for my entire career (going back to coding ISAM and VSAM on IBM mainframes). I know that databases are approximately the least sexy pieces of software on the system. They're a pain to set up properly, a pain to maintain, and the component most likely to get the blame for poor performance -- while being the least likely to be recognized as the foundation for great performance. Making sure that the database piece is right is a more certain path to a great application experience than any shiny interface or focus group study.
[ Your next database could be a service. Read IBM Buys Database-as-a-Service Startup Compose. ]
Databases have had a moment in the sun with the Big Data discussion, but the databases that hold and serve classic structured data are important, too. Accounting, transaction, and even navigation applications are based on the same basic type of database that has underpinned enterprise applications for the last three decades or more. So why aren't we paying more attention to these databases?
Part of the reason is their essential anonymity: In most cases, those who use an app will never know which database sits behind it. There is, therefore, little "glory" in the database world. Much more internal political power will often accrue to someone who chooses the cloud partner or development methodology. Still, it's nice when we're reminded of just how important the database can be.
A new day is coming for the database. SAP is banking quite a lot on HANA. (If you want to know why, in great detail, read The In-Memory Revolution: How SAP HANA Enables Business of the Future by Hasso Plattner and Berndt Leukert.) Oracle and Microsoft are promoting in-memory variants of their flagship database managers. Speed matters. With great speed comes new application possibilities, and in-memory databases can be very fast, indeed.
Those fast database managers (and ever-faster databases that still rely on traditional storage) will make your applications and apps more useful and more attractive. Don't ignore the configuration and management: Getting the database right is as important as getting the right database when it comes to making sure you've got the right foundation for applications big and small.