Web 2.0 by Tim O'Reilly

Thanks to Nina Govan for sending me an excellent article from Tim O'Reilly in 2005, "What is Web 2.0?" The term is so over-used that I had forgotten that it was created as a well-considered definition of the post-dot-com era. If you don't have time to read 5 pages, here are two parts that really stuck out in my mind.

Netscape vs. Google

Quoting from O'Reilly:

"If Netscape was the standard bearer for Web 1.0, Google is most certainly the standard bearer for Web 2.0, if only because their respective IPOs were defining events for each era. So let's start with a comparison of these two companies and their positioning.

Netscape framed "the web as platform" in terms of the old software paradigm: their flagship product was the web browser, a desktop application, and their strategy was to use their dominance in the browser market to establish a market for high-priced server products. Control over standards for displaying content and applications in the browser would, in theory, give Netscape the kind of market power enjoyed by Microsoft in the PC market. Much like the "horseless carriage" framed the automobile as an extension of the familiar, Netscape promoted a "webtop" to replace the desktop, and planned to populate that webtop with information updates and applets pushed to the webtop by information providers who would purchase Netscape servers.

In the end, both web browsers and web servers turned out to be commodities, and value moved "up the stack" to services delivered over the web platform.

Google, by contrast, began its life as a native web application, never sold or packaged, but delivered as a service, with customers paying, directly or indirectly, for the use of that service. None of the trappings of the old software industry are present. No scheduled software releases, just continuous improvement. No licensing or sale, just usage. No porting to different platforms so that customers can run the software on their own equipment, just a massively scalable collection of commodity PCs running open source operating systems plus homegrown applications and utilities that no one outside the company ever gets to see."

Who owns the data?

Again from O'Reilly, page 3:

"In the internet era, one can already see a number of cases where control over the database has led to market control and outsized financial returns. The monopoly on domain name registry initially granted by government fiat to Network Solutions (later purchased by Verisign) was one of the first great moneymakers of the internet. While we've argued that business advantage via controlling software APIs is much more difficult in the age of the internet, control of key data sources is not, especially if those data sources are expensive to create or amenable to increasing returns via network effects.

Look at the copyright notices at the base of every map served by MapQuest, maps.yahoo.com, maps.msn.com, or maps.google.com, and you'll see the line "Maps copyright NavTeq, TeleAtlas," or with the new satellite imagery services, "Images copyright Digital Globe." These companies made substantial investments in their databases (NavTeq alone reportedly invested $750 million to build their database of street addresses and directions. Digital Globe spent $500 million to launch their own satellite to improve on government-supplied imagery.) NavTeq has gone so far as to imitate Intel's familiar Intel Inside logo: Cars with navigation systems bear the imprint, "NavTeq Onboard." Data is indeed the Intel Inside of these applications, a sole source component in systems whose software infrastructure is largely open source or otherwise commodified.

The now hotly contested web mapping arena demonstrates how a failure to understand the importance of owning an application's core data will eventually undercut its competitive position. MapQuest pioneered the web mapping category in 1995, yet when Yahoo!, and then Microsoft, and most recently Google, decided to enter the market, they were easily able to offer a competing application simply by licensing the same data.

Contrast, however, the position of Amazon.com. Like competitors such as Barnesandnoble.com, its original database came from ISBN registry provider R.R. Bowker. But unlike MapQuest, Amazon relentlessly enhanced the data, adding publisher-supplied data such as cover images, table of contents, index, and sample material. Even more importantly, they harnessed their users to annotate the data, such that after ten years, Amazon, not Bowker, is the primary source for bibliographic data on books, a reference source for scholars and librarians as well as consumers. Amazon also introduced their own proprietary identifier, the ASIN, which corresponds to the ISBN where one is present, and creates an equivalent namespace for products without one. Effectively, Amazon "embraced and extended" their data suppliers.

Imagine if MapQuest had done the same thing, harnessing their users to annotate maps and directions, adding layers of value. It would have been much more difficult for competitors to enter the market just by licensing the base data."

The tools of customer care in a Web-based business

Ryan Manville pointed me to a form-builder application called Wufoo. The application is great for simple forms – but check out the "Welcome" email they sent me when I created a free account. It is like a checklist of the tools that you need to run a modern Web-based business.





Compared to this checklist, how are we doing at Certain Software?

• Account Information: YES – We can give you a dedicated URL for your account


• Documentation: YES – We have documentation and a Knowledge Base, but only accessible to customers


• Blog: KIND OF – We recently opened a company blog, but don’t yet have any posts about development or upcoming releases


• Feedback: YES – We have a general inbox for customer comments


• Forums: NO – We are currently investigating a Forum application, but we haven’t published one yet


• Founders Blog: YES – We have one founder Blog, but it would be nice to have a couple more.

Welcome back Rod Marymor!

Rod Marymor was the founder of RegWeb, probably the first online registration application for event planners, which he sold to Starcite in 2002. He is now getting back into event planning software with ScheduleFlex, a scheduling tool for large multi-session events (>50 sessions), which he will offer to both event planners and registration company resellers.

Background

They build ScheduleFlex for an enterprise software company that hosted a 4-day conference recently with about 4000 customer attendees, 700 employees, and 800 sessions. Rod's company Cardinal Communications worked with Mike Graves and Brad Neuman at metroConnections of Minneapolis to develop the application, which was written by the original RegWeb architect Stephen Chang.


"Flex" Architecture

The application was built using Adobe Flex, which produces a "Rich Internet Application" with a Flash-based front end. This allows users to have an experience more like a conventional desktop application (drag & drop text, select one option and dynamically update other options, etc.) compared to traditional web-based HTML forms. Cardinal uses a conventional configuration of Adobe ColdFusion MX as their middle tier and Microsoft SQL Server 2005 as the database.

Here are some screenshots showing the application. You really need to click on each image and view the full-size photo in order to appreciate the beauty of the Flex platform.

1. Attendee view of session scheduler, with filter-select-drag-drop capability to build your personal agenda.


2. After building your schedule, print a personal agenda as a PDF document.





3. The admin-side (for event planners) of the application uses Flex's features really well to manage the huge amount of information inherent in multi-session conferences.

Flex Performance

With the pilot event, several thousand attendees logged on simultaneously when the sessions opened, and Stephen Chang didn't notice an appreciable load on the web server running the application. This processing efficiency results from much of the processing occuring on the user's Web browser, which makes small, infrequent requests to the web server for data updates.

Integration with Registration Systems

Stephen built batch import routines to upload tab-separated values as text files for both attendee lists and session lists. For example, after the event completes preliminary registration, they transfer attendee data to the session scheduler and then begin the session management phase. Stephen also built an API to allow transactional import of attendee information, e.g., as each registration completes, the registration system passes that data to the session scheduler so that the attendee can immediately begin to manage their sessions. If any sessions have associated fees, then the session should be selected in the registration system and paid along with other fees.


Final Word

For more information about ScheduleFlex, contact Rod at Cardinal. They did a nice job building a simple interface for a complex problem in event planning, and I expect to see more use of Rich Internet Applications in the future.

Can you achieve 100% up-time?

As an online registration provider, we strive for 100% availability of our event management software. This is very difficult to achieve in practice, and we occasionally have outages ranging from a few minutes on all servers to intermittent performance for hours affecting only specific customers. Our customers' reaction to these hopefully infrequent episodes ranges from understanding ("oh well, I have a lot of other things to do right now - I'll check back later.") to complete outrage ("I'm losing paid registrations! I have to get this report to the hotel now!").

The "New Normal"?

This article, On-Demand Outages the "New Normal"?, takes the interesting view that as people become more familiar with daily usage of Software as a Service (SaaS) such as our online registration technology, users will realize that these outages are inevitable and they will adjust their expectations and actions during the occasional downtime. No one is immune to the problem - the article references recent and period performance troubles at major SaaS companies such as Salesforce, Blackberry, and Google Apps.

My Old Friend, Who I Dearly Do Not Miss

I remember the early days of Windows when the "blue screen of death" was an unwelcomed part of my daily routine. Reboot, stand up and stretch, login, get some water, wait for the programs to open, pick back up where I left off. The blue screen probably did me more benefit ergonimcally by interrupting long sessions slouched over at my PC than they caused me harm - that is, once I learned to control my temper.

Getting Better, but We're Not There Yet

I'm not excusing poor performance or saying that we won't get better (as we have in the past). But maybe we as users need to begin to consider intermittent outages of SaaS as unavoidable and expected, and thus we should create contingency plans for what we will do when they happen (besides freaking out).