Great ideas often come from the most commonplace occurrences. Take the story of Sir Issac Newton's "discovery" of gravity. According to the legend, he was sitting under an apple tree minding his own business when - bonk! - an apple dropped onto his head, and suddenly all the complex mathematical formulae he'd been considering became crystal clear. It's what's known as an "Aha!" moment.

There's a similar "Aha!" moment waiting for you right in your office kitchen, holding the energy drinks you suck down in mass quantities to keep you going through long, late-night hours of intensive programming. Yes, it's the simple refrigerator. Whether a little college dorm cube-type or a full-on Sub Zero stainless steel unit with a port that hooks into your PC, the refrigerator has but one mission: keep things cold.

The nice thing is you didn't have to buy the outer metal casing and then figure out how to make it keep things cold rather than cook food, grind garbage, or make coffee. You didn't have to install an operating system, and then download instructions that tell it how to maintain a temperature of 47 degrees to keep your energy drinks just the way you like them. And you didn't have to worry about it causing conflicts with the toaster oven. All you had to do was pull it out of the shipping carton, put it in place, plug it in, set the temperature dial, and load it up with goodies.

Here's the "Aha!" moment for you. Rather than delivering your Java-based software application as a box full of CDs or an electronic software download (ESD) that needs to be installed, configured, and tweaked, you can use that same appliance model to provide a simpler, more complete package for your application.

Not only does providing software as part of an appliance make installation and use easier for the customer, it also simplifies product development and makes after-sale services such as support a whole lot easier on your end. If you're using open source software as part of the application, delivering the final product as an appliance even helps get it approved by enterprise gatekeepers who have a bias against open source. It may not be the discovery of gravity, but it certainly has a big impact on your business.

What Is an Appliance?
In the technology sense, an appliance is a device that delivers the software you've created, the hardware it runs on, and the operating system that connects the two, all in a single, hardened package. When it arrives, the customer unpacks it, places it in the rack (after checking power and cooling requirements), connects the power, connects the appliance to their network, and presses, flips, or toggles the "on" button. At that point the appliance fires up, configures itself, and is ready to get to work. All of this occurs in less time than it normally takes to load the software from CDs or a downloaded executable alone.

Traditionally appliances have tended to be used more to deliver smaller, single-focused, back office applications, such as DNS management, firewall services, or video streaming. Now, though, they are also being looked at for more complex front-end applications, such as customer relationship management (CRM) and enterprise resource planning (ERP). And for good reason.

There are a number of advantages to the appliance model - some more evident than others. These advantages tend to fall into two categories: experiential and technical. Both are important, as they have a direct impact on the total customer experience. Let's look at each category to see how they affect both immediate customer satisfaction and future opportunities.

The Appliance Experience
One of the most significant impressions an appliance makes right out of the box, so to speak, is the perceived value of delivering a complete, ready-to-go product rather than a set of CDs or downloads that are just the starting point. Software is somewhat ethereal, even to those who work with it every day, and Java can be intimidating to the non-expert. But a metal box you can hold in your hands that makes a loud noise if dropped - now that has substance!

An appliance also provides an opportunity for branding and visibility within the technical organization that often isn't there with software alone. Consider that with many software packages, especially for back-end functions, such as spam filtering or security applications, if all goes well it just runs in the background. Out of sight, out of mind. The only time anyone sees your company's name is when something goes wrong, which is not exactly when you want them to be thinking of you. With an appliance, though, your brand identity is very visible right in the rack. Network administrators or other IT types pass by it on their way to solve some other crisis. Or when they go for their own energy drinks. And the more appliances you sell to that customer, the more visible you are to them, which keeps you at the top of the mind for future sales.

Delivering software as an appliance solves logistics problems for the customer as well. They no longer have to make room on an existing server, or even worse have to try to coordinate software and hardware delivery from two separate sources, using two separate purchase orders. One call, fax, or e-mail does it all, with a guarantee that everything arrives at the same time.

Finally, if a problem does arise with your application, there is none of the usual "it's a hardware problem"/ "No it's a software problem"/ "I knew we shouldn't have used open source products"/ "Is there anyone else we can blame?" fingerpointing. Customers have one call to make to resolve any issues, no matter what the cause. That's a benefit that can't be overestimated, especially at the enterprise level.

Technically Speaking
Because they are hardened system - i.e., no outside software or hardware is required to run them - appliances offer certain technical advantages over software users install themselves.

An obvious one is that they are far easier to deploy. Normally, the most difficult part of deploying an appliance is pulling it out of the shipping carton. A few connections, a little self-configuration, maybe a couple of manual steps, and the customer is up and running. Depending on the nature and complexity of the software, users may need to perform certain operations from a master console. But even then, they can get to that part a lot faster if they're not first trying to load it onto a separate server or seek out additional components on a Web site.

On the development end, one of the most serious complexities is trying to anticipate the hardware platform and operating system the customer will be using. Much of the development time, in fact, is actually spent testing the software with various common configurations. Of course it never fails that some important customer has created some proprietary nightmare, and then your development team becomes your tech support for that important customer instead.