Infovark

Brad Feld at Feld Thoughts posted a slide by Adam Smith relating the Southpark underpants gnomes to pitching venture capitalists. The slides were meant to demonstrate how not to sell an idea to a venture capitalist. I understand the point, but I think if venture capitalists find themselves listening to gnome-like business plans they themselves are partly to blame.

Brad’s posted the clip from the Southpark episode, so I’ll just give a quick recap of the gnomes’ three phase plan:

1. Collect underpants
2. ???
3. Profit!

The hardest part of any startup is figuring out Phase 2. Phase 1 is easy; it’s doing what you do best. For a software company, that means making software. For an author, it’s writing a book. For an artist, it’s creating art. Phase 3 is the goal: Making money, achieving fame, winning awards, etc. Phase 2 is the trick: finding a way to get from doing what you do best to the ultimate goal.

Often, someone starting out has only the talent and the dream. Figuring out how to make the dream a reality is a combination of hard work and dumb luck.

The idea behind venture capital is not simply to give new startups access to seed money. There are plenty of ways to raise funds. You could take out a business loan, put a second mortgage on the house, or hit up friends and family for cash. Part of the reason why startups turn to a venture capitalists is to get the benefit of their experience with other startups. In other words, it’s to get help with Phase 2.

Many of the current Web 2.0 darlings succeeded without any sort of business plan at all. YouTube was losing money hand over fist and had several copyright infringement lawsuits pending when Google rescued them. Google themselves nearly went broke before they hit upon the advertising formula that powers the attention economy. Facebook hasn’t figured out their model yet. Twitter has no means of visible support beyond VC backing. With these examples in mind, it’s hard to blame startup founders for glossing over Phase 2.

Yes, build it and they will come is the call of hopeful idealists everywhere. But boundless optimism is a necessary requirement for an entrepreneur. It goes with the territory. Venture capitalists, of all people, should appreciate that.

In network diagrams, the Internet is often represented by a cloud symbol. The term “Cloud” has, as a result, been adopted to refer to things that happen on the Internet. Google popularized the phrase “Cloud Computing”, which is essentially applications and software that reside exclusively within the Internet. Flickr or Gmail are great examples — no server, no software, no setup wizards — and you can access these cloud-based computing resources with whatever portable device you happen to have handy — your PC, your iPhone — even your Chumby. The reason for the cloud as a symbol is because it’s an amorphous, hard-to-define collection of computers… somewhere out there.

When we analyze the cloud, we can see that while the term “The Internet” is often used as a singular noun, it is in fact,very plural. The Internet is made up of thousands of other networks. That’s what the word Internet means — a network of networks. The cloud is itself a cloud of clouds.

If we look at a map of the Internet, we see a cloud made up of thousands of connected clouds. Each cloud represents a cluster of IP addresses owned by various different organizations. And if we zoom in on those smaller clouds, we find a repeating pattern of nodes connected to other nodes. Some nodes are highly connected within the cloud; some nodes have just a few connections. Zooming in further, we eventually find web servers publishing information within particular organizations. And if we zoom in at the highest resolution, we find each of those web servers connected to still another cloud of nodes: the workstations that access those servers.

At each level of magnification, the Internet appears the same: It’s a loose collection of nodes, a few of which are highly connected hubs, but the vast majority of which are spokes with very few connections. In mathematical terms, it’s called a scale-free network.

Scale-free networks are a hot topic right now, and not only because of the Internet. Social networks are also believed to be scale-scale free networks, as is the human brain. Scale-free networks also exhibit some interesting properties, in that they are highly resistant to random failures but somewhat susceptible to epidemics. The distribution of highly connected nodes to nodes with few connections is a power law distribution, which generates that famous long tail graph.

Those small clouds we see at the lowest level of magnification are the main source of activity on the Internet. This is where all the work gets done. I’m typing this on a PC connected to the VarkNet in the infovark Burrow. You’re probably reading it on a PC that’s connected to your own organization’s network. All of the information on all of the web servers across the entire Internet is ultimately authored by people on personal computers connected via their local networks. Everything on the Big Cloud started on a Small Cloud.

Here’s another interesting thing about a scale-free network: Its rules operate the same way at a macro level as at the micro level. It’s fractal in nature. The same patterns hold, no matter at what resolution you view the system. That’s why the same technology that allowed a handful of academics to send doctoral theses to each other can scale to the point where millions of users can share video with each other. There’s no magical point where Small Cloud architecture becomes Big Cloud architecture. The Small Cloud is the Big Cloud.

The output of all our collective activity on the Internet is information. It’s policies, email discussions and contracts. It’s blog posts, and wiki pages, and accounting spreadsheets and customer service records. Where should that information belong?

As far as the Internet — the network of networks — is concerned, it’s all just a bunch of ones and zeros. It doesn’t really matter where the bits go. Anywhere in the Cloud will do. One network is just as good as another.

We’re a little late to the party, but there’s a wonderful comment thread over on Shel Israel’s blog about all things social media, and particularly around Sharepoint and Microsoft’s attitude to the emerging Enterprise 2.0 contestants like Jive Software.

All this stems from a quite inspired piece of writing from Dennis Howlett, where he discusses the difference between the established “mega” vendors, and the emerging Enterprise 2.0/Social media products:

In other words they (the “mega” vendors) are transaction based. They are not people based. I’d go further and say they are departmentally constrained, reflecting the internal power structures they were designed to support.

Naturally, this led to something of a flame war, where Microsoft and the SharePoint zealots were out in force, defending the innate awesomeness of SharePoint, and the newer more agile folk were perhaps taunting them a bit more than was polite. All in all, it makes for highly charged and extremely interesting debate.

Personally, I’m not sure either way about SharePoint’s capabilities in this space. I do know that Lawrence’s original comment on Sam’s blog really irked me, and it’s not the first time I’ve encountered him in the blogosphere.

My experience is that I’ve met lots of people who use SharePoint, but very few who really like it. On the other side of the fence, there are converts to the more dedicated social software - (like EMC’s Chuck Hollis), who do seem to have good things to say about the new emerging platforms.

As Dennis says, these are indeed interesting times. And good healthy debate amongst vendors has to be healthy for customers, right?

Those of you with a technical background may have noticed a close correspondence between the Web 2.0 principles I described in our design series and Representational State Transfer, or REST. This is no coincidence. Gordon’s been a backer of RESTful approaches to web application design for some time now; I’m a more recent convert. More importantly, the REST architectural pattern fit what we were trying to do with our infovark project.

REST is a design pattern used to create Internet applications. It’s been growing in popularity, but hasn’t been fully adopted by any of the major vendors yet. (Microsoft’s efforts to lump REST into the Windows Communication Framework notwithstanding.) This is probably due to the fact that the World Wide Web Consortium, or W3C, put its weight behind an earlier, competing design philosophy called SOAP. (SOAP used to stand for Simple Object Access Protocol, but the “simple” part was dropped long ago.)

SOAP was designed to help loosely connected computer systems communicate with each other. Many previous frameworks and standards had attempted to do the same thing, but with so many different hardware and software vendors building systems, most were doomed to fail. SOAP is likely to stick around for a while due to its close association with with Web Services and Service Oriented Architectures. As a practical matter, however, the class of problems that SOAP solves are actually rather limited. Strike that; the class of problems that only SOAP can solve are rather limited. For most applications, there’s an easier web services alternative: REST.

An Illustration

Pardon me while I geek out for a moment.

When I was a kid, me and my friend Rajeev would dial each other up — yes, literally dial each other — with our 300 baud modems. I know, I know, you young ‘uns are thinking, “What’s baud? What’s a modem?” Suffice it to say that it was a slow way to get two computers to talk with each other. And when I say slow, I mean S… L… O… W. You could literally watch the letters appear one by one in your monochrome terminal window. If you can imagine sending a message via Twitter one letter at a time, you’ve got the idea.

It was so painfully slow that there really wasn’t much point in sending messages back and forth. Other than the nerd-cool factor of making two computers located in different parts of town communicate, there wasn’t much to do. So Rajeev and I hit upon an idea. We’d play a game online. Being nerds, we naturally picked Chess.

Chess was actually a great application for modem-to-modem communication. There was a well-known initial starting state in the traditional arrangement of the pieces. There was an established protocol: white moves, then black moves. And there was even a short messaging format: chess notation.

So we started playing Chess online. Each of us kept a small chess board by the computer. We slowly took turns typing out our moves to each other and updating our game boards: “P-K4″, “P-K4″, “Kt-KB3″, “Kt-QB3″ and so on. Not exactly riveting entertainment, but hey, we were doing something new and different.

Every now and then, we’d run into a problem. I’d get a message from Rajeev with a nonsensical move, or he’d get a message from me that moved a nonexistent piece. Then one or the other of us would see these letters slowly print across the screen: P… I… C… K… U… P… T… H… E… P… H… O… N… E.

We’d then try to figure out what had happened, based on the log of all the messages that went back and forth and the current position of the pieces on each of our game boards. Sometimes we were able to figure out the mistake. Sometimes we agreed to go back to the last time we picked up the phone to reconcile our respective chess boards. Sometimes we started over.

As you can imagine, this sort of troubleshooting got old fast. And it happened all the time. Eventually we gave up on trying to play by computer, and we just bugged our Moms to drive us over so we could play using the same board.

REST in a Nutshell

The point of the story above is not to establish my geek cred, but to offer an analogy.

In the early days of network computing, bandwidth was low, latency was high, and it was vitally important to make your messages as concise as possible. A wide variety of message formats and protocols evolved to respect the limits of early computers and networking technologies, all designed to get as much useful data packed into as little space as possible. It’s exactly like the chess notation Rajeev and I used. We could have sent snapshots of the chess board after each turn, but it would have taken hours to transmit a single move that way. All we really needed to know was which piece needed to move where. Using the shorthand, a single move — one procedure — could be described in just a few letters.

Though network computing technology has come a long way since then, the most common way for computers to talk with each other is still via Remote Procedure Calls, or RPC. Rather than describe the entire gameboard, computers just tell each other how to move the pieces.

If you’re wondering how computers handle mistakes or lost transmissions, well, a staggering amount of effort in computer science has focused on error detection and correction algorithms and secure transaction processing. Believe me, the last thing your credit card company and your bank want to do is pick up the phone to work out whose set of accounts is more accurate.

This is why data replication is such a huge problem. If you only transmit the moves to each other, you have to start from a known initial state. The chessboard at Rajeev’s house and my house had to match at the start of the game. It’s also why synchronization is a big deal. If the moves are sent out of order, all sorts of problems occur.

If, on the other hand, you could send pictures of the game board back and forth, a seasoned player could probably reassemble the images in something close to the right order. Better yet, if both players could look at the same board at the same time, then you’d never get out of synch.

This is the essence of the REST architectural pattern. It’s a little less respectful of network resources, but by transmitting the current state of the game at any point in time, you can simplify the amount of work you need to do to get two players to agree. Most of the transaction issues and handshaking protocols become unnecessary. The World Wide Web — hypertext over HTTP — works in a RESTful way, and it’s the most successful computer application ever built.

Enterprise 2.0 is about applying the lessons from the Web to the enterprise, so it makes sense that we should start with the core design principles.