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.

Continue Reading

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.

Continue Reading

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?

Continue Reading

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.

Continue Reading

It’s time to wrap up our long-running series about moving information. We’ve managed to take the sting out of Locating and Versioning documents within your enterprise through clever application of web tools. This is the final part of the series, where we talk about how to fix the tracking problem.

Our basic premise is that the most obvious place to find something is where you left it. Since you created the item on your PC, that’s where it should live. Your coworkers know you drafted the document, created the slideshow, or assembled the spreadsheet, so they’ll expect to find it somewhere on your PC, too. It matches the paradigm we use every day in the physical world.

Jimmy the photographer was working on the layout for page three. Lois wanted to have a look at it, so she dropped by his desk. What about the front page? Clark was working on the cover story. Oh, there it is, still in Kent’s typewriter. Where’s that Clark gone now? He’s never around when you need him…

The tracking problem is driven by three needs. The first need is to locate the current version of an item. We’ve largely mitigated that problem by applying version control to the information at the point where it was created and giving the information a unique address on your organization’s network so that your coworkers can find it.

Since you generally know what sorts of things your coworkers do, you’ve got a pretty good idea of what business information they’ll have on their machines. For cases where you might not know the right person, you can navigate links in the social network to find the right stuff. And in the worst case scenario, you can always run an off-the-shelf search engine over all of the documents. Since we’ve done the hard work of making them addressable and versionable, creating a full text index of their contents is no problem.

The second tracking need is to monitor the status of a work in progress. Based on what we’ve seen during our time as management and technology consultants, this is the item that generates the most email traffic in a typical enterprise. This is the reason why most knowledge workers spend a significant chunk of their time asking for or filling out status reports. I like to call it “Management by Magic 8-Ball“.

Manager: “Is it done yet?”
Employee: “Ask again later.”
Manager: “When will it be done?”
Employee: “Cannot predict now.”
Manager: “Will we meet the deadline?”
Employee: “My sources say no.”
Manager: “Will a week’s extension be enough to finish?”
Employee: “Signs point to yes.”
Manager: “OK. I’ll see what I can do.”

Not the most efficient use of time and resources, is it? The exchange above is another symptom of the way enterprise software works today. Each knowledge worker is a black box as far as most office productivity tools are concerned. According to this school of thought, a manager assigns a task, the employee disappears into a cubicle for a while, and some time later the employee emerges with the task complete. In the abstract, it seems like a decent way to organize things. How the employee gets the job done should be irrelevant, so long as the job gets done, right?

In practice, it’s a disaster. What happens inside that cubicle is vital to the operation of an innovative, collaborative business. Coworkers need to know that information, as do managers. And in today’s fast-paced business world, they need to know in real-time. Hence the endless requests for status updates in email, or the tried-but-true “Management by Walking Around.”

Wouldn’t it be easier for everyone involved if the there were more visibility into what happens inside that cubicle? An architect can see the progress being made on a construction site without having to deluge the foreman with requests for status updates. What we need is a way to publish updates as they happen. Let’s call it workstreaming for now, since I can’t think of a better term.

Knowledge workers interact with their computers to get most things done. In theory, that means the computer should be able to notify managers or coworkers when work product is updated. Rather than reading endless status reports, a manager could subscribe to his employee’s RSS feeds. A coworker can monitor a document of interest on her friend’s computer. Most importantly, these things can be done silently, without interrupting the knowledge worker’s train of thought. They can concentrate more on getting their tasks done and less on responding to requests for information.

But what about…

Then there’s the third tracking need: Auditing. Sometimes it’s important to know how information flowed through an organization. One example is process improvement; You might want to figure out how to improve response time for calls received by your customer support line. Another example is for an audit or an investigation; You might need to prove that sensitive financial data was protected during the sales and order fulfillment process. Most solutions to this problem advocate centralized management schemes, intensive processes, and strict governance. There’s a large market for discovery and compliance tools to address this need, because the problem is complex and expensive.

It’s also — thankfully — rare. Fortunately, only a few industries and government labor under the sort of onerous rules that make compliance tools worthwhile. For the rest of us, it’s overkill. Unfortunately, it’s the compliance-laden parts of knowledge work that have so far driven the development of new tools and technologies. ERM, EDM, ECM, BPM… the mere fact that these tools sell themselves by acronym should be a tip-off that they were designed to appeal to industry analysts and can only be deployed by a small army of specialists.

Yes, auditing and compliance are tough problems. A web-centric approach to enterprise software might have little to offer organizations that have risk management as a key strategic objective, beyond increased transparency. But most businesses would rather boost productivity and improve the bottom line.

The Enterprise 2.0 vibe is about improving collaboration by bringing simple, successful, scalable tools from the Web 2.0 generation of consumer technologies into the workplace. Enterprise 2.0 tools are about making a knowledge worker’s daily tasks easier and more fun. And making things fun and easy spurs creativity, cooperation, and innovation — the only durable sources of competitive advantage.

Continue Reading