It takes a former IBMer to design their own home systems like an IBM mainframe. But while the concept may initially seem 22nd century, once he gives it some thought, designing a home system the way he would design Big Iron might not be 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. He opened my eyes to the challenges and opportunities home system VARs will face in the coming years as more people demand these types of technologies. Not to mention the challenges we all face when trying to implement advanced technologies in our homes.
VARs face three major hurdles in delivering well-executed home systems. First of all, people don’t know what they want, and what they want is not something most VARs know how to deliver. Second, the skill sets most VARs face are vast, and finding the right mix of people to deliver a robust solution is not easy. Third, the problems are not with technology, but with usability and execution. Let’s look at each of these.
What I’ve seen is that most of us don’t really know what we want when it comes to high-tech homes. As an example, people only have a vague notion of what a ‘smart home’ really is. Some people want their computers to be located in strategic places, sharing an Internet connection. But after it’s implemented, they realize they don’t want to run around their houses trying to find a document on a particular PC or to be able to share printers as well. So the home network becomes more than just sharing broadband. Some people want a house that they can control through a web browser. But then they want to be notified when something goes wrong and have an idea of what’s going on at home when they’re geographically distant. And many of us want more sophisticated entertainment delivery or ways to interact with our TVs to save our favorite shows, which is why Tivo is so popular. But then you realize when you have Tivo that you need to be able to program the drive remotely, when you’re not at home, for example.
Part of this is simply human nature: You get better at defining your needs when you see what high-tech toys really do. But part of this is because high-tech doesn’t really work out of the box.
The problem with implementing these things is that the skill sets are huge, especially when you demand increasingly smart homes that cover multiple needs. I learned from my tour of chez Patrick that you have to segregate your services into separate components. But before you can segregate them, you need to identify them. This goes back to my first point, and more importantly, this identification process is not something most VARs can offer.
Let me give you an example. At first glance, electrical power looks like a simple system: There’s a breaker box in your basement, and each breaker is connected to a series of outlets or switches in a room or set of rooms that it controls. But that’s not enough for a truly smart home. You have power for particular systems that you want to run 24/7, like your refrigerator and heating systems, and power for other places that aren’t as critical or even 110 volts, like portable phones, security sensors, and touch panels that can operate at lower voltages.
What Patrick did was segregate his systems into many different discrete categories. Let’s take audio services as another example. Speakers that broadcast the music are placed on 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 in his basement. But you might not want to go down to the basement to find the right track to play with dinner: so you have a touchpad in the dining room that you can scroll through your songs and choose the right song to suit your mood. But to do this correctly, you need to write some code so that your touchpad can access the music library and understand the ID tags of the files stored there. Suddenly, you need to have someone who understands:
* how to rip and encode your entire music library;
* how to display song ID tags on various screens, including your PCs and touchpads at home;
* how this information is 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 may be running different operating systems and code (and may not have programming interfaces either)
And that’s just music. The most difficult are security, heating and cooling, propane supply, computer networking, video, and signage for various household operations.
This is where the mainframer came out of the closet, so to speak. Actually several different cabinets. Common home system design practice is to put everything with a cord in a single closet, so you can access everything from one central location. The problem with that is that you need locations distributed around your home that have some control function. For example, if you have all your music services in one cabinet, you may not want to go to that cabinet when you want to play a CD or DVD.
When we go back to the old days of Systems/360, this is exactly what IBM did with its systems network architecture: distribute some control functions, but keep some central processing. For Patrick’s house, he set up separate areas in his basement that would handle each service: his propane lines, for example, all terminate in one area, so you can turn off service to the outdoor barbecue from the same place where you can turn off the valve on your stove or water heater. Sure, you spend a bit more on all the plumbing to get “home runs” of propane supply, but it makes for a cleaner, more manageable setup.
This brings us to our final problem, namely that most problems are about usability and execution, not technology. What Patrick did to improve usability was to define a set of scenarios for how he lives in his home and what system “events” should occur as part of his daily routines. For example, watching a movie in the living room means dimming the lights, lowering the screen, turning up the projector, and turning on the sound system. What was great was the way he designed the overrides and controls (you want to turn everything off at night when you go to bed for example) but still make everything consistent and logical so you can change things on the fly (for example , if Letterman is really interested and it’s worth staying up later).
Patrick was most proud of the solutions that he cobbled together with common parts that are available at Radio Shack. Although his home integrator was quite experienced, there were some things he wanted to do differently that the integrator couldn’t handle. The various technologies had to be easy enough to operate and debug, and present uniform interfaces so that they could be operated from various interfaces, including the ubiquitous touch panels on walls, a web browser, and video screens found around the house.
Even the best designed mainframe needs a bit of customization. And perhaps others will take notice of Patrick’s architectural innovations when they design other smart homes in the future.
