Mirrored from http://www.cadence.com/features/vol3No3/mc_nealy for stability.

Do We Worry Too Much About Protecting IP?

Scott McNealy

It seems as if everyone's always worried about intellectual property, or IP. We worry about its proprietary nature and how to protect it. But let's take a different angle on IP and also intellectual capital inside a company, because I think we all worry way too much about protecting it.

IP has the shelf life of a banana. It just doesn't last, yet we're all worried about protecting it, hiding it, securing it, storing it in a vault. As a result, we absolutely prevent our competitors from getting ahold of it, but we also prevent our employees from getting ahold of it. We prevent our customers — and our suppliers and our partners — from getting access to it. As a result, by the time the people who need access to it get that access, it's so old that it is effectively a banana we wouldn't want to eat.

I think a large part of the problem we face with our IP is that a lot of it is in the form of unstructured data — things such as memos, e-mails, beeps, pages, and just general conversations that occur in large organizations, which tend to be quite diverse and wide. Engineers are, of course, used to thinking about structured data — whether they're thinking about CAD designs or business processes — but most of the information that gives a company its absolute edge is, in fact, unstructured. The last thing you would want to do with all this information is lock it up in formats that are unusable, unreachable, and unmanageable. Yet that is what many organizations do!

Keeping It Simple

Instead, we need to make sure our information is accessible to every computer on the planet. To ensure availability and access, reliability, and security, we need to use open interfaces and standard protocols. We can start by transferring our data through TCP/IP, the Internet protocol. Most companies today are on an IP network or will soon be. Why? Because every computer on the planet can speak IP and therefore can communicate with any other.

The next major format we need to concentrate on is one that actually preceded the Internet protocol: ASCII. Yes, ASCII. There's not one computer, not one device anywhere that can't create and read ASCII.

And look, the “ASCII authoring tool” is a keyboard! We don't have to boot it up, there's no on/off switch, there's no programming required, there's no manual. There is a slight learning curve, but these keyboards all look about the same. We know that the Q key is right next to the W key, which is right next to the E key.

This is how we should create information. Because in addition to being ubiquitous, ASCII is incredibly efficient. It's creatable and readable by every computer on the planet, and we can send a message from anywhere to anywhere.

For example, let's say I want to send the word attack from my workstation to 25,000 Sun Microsystems employees worldwide. To do this, I just type in six letters and send. I've now created a very important document that contains just six characters times 8 bits, or 48 bits of bandwidth I need to send through my network. Even when it's going slow, it can send these 48 incremental bits to all 25,000 employees in a flash.

Another text format I might want to use for important documents is HTML, HyperText Markup Language, which enables the World Wide Web to exist. Maybe I don't want to send my document to everybody but instead just have it available for them to come and get it. Once again, there's not a computer in the world that can't view and handle an HTML document. The word attack has “ballooned” to 256 bits in HTML, five times as much data and no more information than in ASCII, but that's still not bad and it might be more efficient than sending out an e-mail to thousands of people.

Let's say I create my message in a Word document, however. I've now jumped to 90,000 bits of data. The worst-possible scenario is for me to send it out as a PowerPoint document; the word attack requires 258,048 bits in this format. That's more than 5,000 times the data for the same single word of information. This would be guaranteed to bring anyone's network to its knees. Whatever data we decide to put in this program is now unavailable, unusable, and very inefficient compared to ASCII and HTML.

Anywhere, with Anything

We have to create information quickly and get it out to our employees, partners, and customers immediately, wherever they are, on whatever device they're using. For example, I probably read 5 to 10 percent of my e-mail at my office. The rest I read on any available computer I can find. It has to be this way. Giving our employees access to information any place quickly enables us to take cycle time out of our business practices.

We don't want to lock it up in a single-vendor, proprietary environment, so we should use TCP/IP for networking, ASCII and HTML for publishing and messaging, and IMAP4 as our messaging protocol for managing e-mail. I think we should use SQL for our databases, so we don't get locked into a single database vendor, and we should use Java to run our applications. Because once again, every computer handles every one of those interfaces, so you can write it once, run it anywhere, view it anywhere, and send a message and get access to it from anywhere. These are Web-based, ubiquitous environments.

One problem my salespeople have with this view is that it means that you don't have to buy a computer from Sun Microsystems if you don't want to. You don't have to buy from IBM either, or Microsoft, or anyone else. In the open, network computing environment, you can make your decisions based on price/performance, availability, and reliability, rather than get locked into a proprietary environment.

In fact, a computer is not the only device you can use to create and access data. You should be able to get access to your IP from any device you can imagine. Think about the four places we're at most of the time: at a desk, in the car, on the phone, or in front of the TV. Why not be able to retrieve the information we want in any of those four places? Why not put Java, for example, into any type of device? We've done this with Nokia cellular telephones, for example. We've also created what I call the ultimate thin client, the smart card. The card can become our identification, our ID. It becomes our electronic digital authentication, encryption preferences ID card for any device. Put it into an available computer, and that computer becomes our personal computer.

That's right. Think of getting an available parking spot, then an available office, and finally an available computer. We put the card into this computer, and it becomes our personal computer (which can take us to our personal Web site).

I've always thought the whole concept of having a personal computer is like the notion of having a personal telephone switch. A dumb idea. The phone company figured that out a long time ago, and power companies figured out that having our own personal power plant was also a dumb idea. The personal computer is an equally dumb idea.

We can also put a smart card into an available phone, and it becomes our personal phone. And someday every TV, every set-top box, every game machine will be a Java computer running ASCII, HTML, and TCP/IP in a Java Virtual Machine (JVM) environment. We can get access to our unstructured data from anywhere through any device.

My security chief told me once that we lose a couple of laptops per day to theft. Well, just try to steal my e-mail. I don't even care where my server is. I just use my smart card and enter my password, and there is a secure TCP/IP tunnel set up that lets me read it. The information stays behind the firewall going into Sun; it's not on a proprietary, theft-prone personal computer I have to carry around with me.

Whether I'm reading my mail, looking at my calendar, or using any other application, I just want to download a little Java applet from a Web phone, from a set-top box, from a Nokia phone, or from a Java car. I want to do it from anyplace that has a computer: a hotel room, an airplane — you name it.

Wearable Java

This is the way computing is going. I really think people underestimate the importance of unstructured data, this intellectual property and capital we all have. In fact, much of this data concerns us so closely that I think we can wear it. We can arrive at wearable computing. I wear my Java ring, for example. It has a microprocessor, a battery, and a JVM in it. It can do everything the smart card can do: create one-time passwords, sort content, and so on. It's a very simple device to program.

I think there are some very important ideas behind wearable computing. In a Java car, a ring could open our doors, adjust the seats, tune the radio. Any available car could become our personal car, just as any available computer becomes our personal computer.

Wearable computing resides in a very powerful, scalable environment that I think is going to change the world significantly. In the military, for example, the ring can identify soldiers to touch-control panels and other devices that need a single-lead contact. In universities, it can get students into the library, register them for classes, let them check out books, and get them into the cafeteria. In the hospital, it can replace that little plastic bracelet and enable printouts and handle insurance procedures.

Even with ASCII, we'll always be able to use more bandwidth. But we'll see smaller and smaller devices instead of watching them get bigger and bigger. We need to focus on how to be productive, not just active. We should not become slaves to clip art and color and multiple fonts. We must not emphasize form over function. To drive out business cycles, to leverage our IP, to take advantage of what we have, we must keep things simple and open. Take advantage of simple stuff that will help you succeed.

This article is excerpted from a speech presented by Scott McNealy at the Converging on Opportunity seminar in San Francisco in June. McNealy is chairman, CEO, and one of the cofounders of Sun Microsystems.

© 1998 Cadence Design Systems, Inc. Cadence and Vampire are registered trademarks, and the Cadence logo is a trademark of Cadence Design Systems, Inc. All others are properties of their holders.