It takes a former IBMer to design his own home systems like an IBM mainframe. But, although the concept may initially seem 22nd century, once you give it a bit of thought, designing a home system the way you’d design Big Iron might not so far fetched. I realized this when I visited John Patrick, who retired from running IBM’s Internet business several years ago. He gave me a tour of his suburban home earlier this month. It opened my eyes as to the challenges and opportunities that home systems VARs will face in the coming years as more people demand these sorts of technologies. Not to mention the challenges that all of us face when we try to implement advanced technologies in our homes.

VARs face three big hurdles in delivering well-executed home systems. First, people don’t know what they want, and what they do want isn’t something that most VARs know how to provide. Second, the skill sets that most VARs face are enormous, and finding the right mix of people to deliver a solid solution isn’t easy. Third, the problems aren’t technology, but all about usability and execution. Let’s look at each of these.

What I have seen is that most of us don’t really know what we want when it comes to high tech homes. As an example, people have only a vague notion of what a ‘smart home’ truly is. Some people want their computers located in strategic places, sharing an Internet connection. But then we that is implemented, they realize that they don’t want to be running around their homes trying to find a document on a particular PC or being able to share printers too. So the home network becomes more than just sharing broad-bandwidth. Some people want a house that they can control via a Web browser. But then they want to be notified when something goes wrong, and have some insight into what is happening in their house when they are geographically distant. And many of us want more sophisticated entertainment delivery or ways to interact with our TVs to save favorite programs, which is why Tivo is so popular. But then you realize when you have Tivo that you need to be able to program the unit remotely, when you aren’t home, for example.

Part of this is just human nature: You get better at defining your needs when you see what the high-tech toys really do. But some of it is because the high tech doesn’t really work out of the box.

The issue in deploying this stuff is that the skill sets are enormous, especially as you demand increasingly smarter homes that bridge multiple needs. I learned from my tour of chez Patrick that you have to segregate your services into the separate components. But before you can segregate them, you have to identify them. This gets back to my first point, and more importantly, this identification process isn’t something that most VARs can deliver.

Let me give you an example. At first blush, electric power seems like a simple system: There is a circuit breaker box in your basement, and each breaker is attached to a series of outlets or switches in a room or a collection of rooms that it controls. But that isn’t enough for a truly smart home. You have power to particular systems that you want to run 24/7, such as your refrigerator and heating systems, and power to other places that isn’t that critical or isn’t even 110 volts, such as portable phones, security sensors and touch panels that can run at lower voltages.

What Patrick did was to segregate his systems into many different discreet categories. Let’s take audio services as another example. The speakers that deliver music are placed in the walls of various rooms. Those speakers are connected to a music delivery system that can play multiple channels, and from multiple sources, including a Linux-based MP3 server that is located in his basement. But you may not want to go to the basement to find the right track to play with dinner: so you have a touch panel in the dining room that you can scroll through your tunes and pick out just the right song to match your mood. But to do this properly, you need to write some code so that your touch panel can access the music library and understand the ID tags of the files stored therein. All of a sudden, you need to have someone who understands:

• how to rip and encode your entire music library;
• how to display the ID tags of the songs on various displays, including your PCs and touch panels around the house;
• how this information gets updated when you add new music to your library;
• how to access the programming interfaces of your touch panels, music delivery system, and music servers, which all might be running different operating systems and code basis (and may not have programming interfaces either)

And that is just music. The harder ones are security, heating and cooling, propane delivery, computer networks, video, and signaling for various house operations.

Here is where the mainframer came out of the closet, so to speak. Actually, several different closets. The common practice of home systems design is to stick everything that has a wire into a single closet, so that you can access everything from a central place. The problem with that is that you need distributed locations around your home that have some control function. As an example, if you have all your music services in a single closet, you may not want to go to that closet when you want to play a CD or a DVD.

When you hark back to the old Systems/360 days, this is exactly what IBM did with its Systems Network Architecture: distribute some control function, but keep some central processing. For Patrick’s home, he set up separate areas in his basement that would handle each service: his propane gas pipes, for example, all terminate in one area, so he can shut off service to the outdoor barbeque from the same place that he can shut the valve for his stove or water heater. Sure, you spend a bit more for all the pipes to get “home runs” of propane delivery, but it makes for a cleaner and more manageable installation.

This brings us to our final issue, namely that most problems are all about usability and execution, not technology. What Patrick did to improve usability was to define a set of scenarios about how he lives in his home, and what systems “events” need to happen as part of his daily routines. For example, watching a movie in the living room means dimming the lights, bringing down the screen, bringing up the projector and turning on the sound system. What was genius was the way he designed for overrides and controls (you want to shut off everything at night when you go to bed, for example) but still making everything somewhat consistent and logical so you can change stuff on the fly (say if Letterman is actually interested and worth staying up later).

Patrick was most proud of the solutions that he cobbled together himself out of common parts that are available from Radio Shack. While his home integrator was quite experienced, there were some things that he wanted to do differently and the integrator couldn’t quite handle. The various technologies had to be easy enough to operate and debug, and present uniform interfaces so they could be operated from various interfaces, including the omni-present touch panels on the walls, a Web browser, and the video screens that are located around the house.

Even the best designed mainframe needs a little customization. And maybe others will pick up on Patrick’s architectural innovations when they design other smart homes in the future.