CogBlog

Reporting & Coghead

by Greg Olsen

Ever since there have been database applications they have served two roles:

• a transaction processing system: an operational system of record that manages a central information repository and that controls additions, deletions, and modifications to the repository.
• a system for reporting and analysis: a system used to examine generated data to help people understand what it means.

Sometimes these two roles overlap - e.g. simply looking at a list of sales orders sorted by date or value provides useful analytical information regarding sales activity.  Often, however, reporting and analysis needs are very different from transaction processing needs, and require separate capabilities.  The whole point of a transaction processing system is to be always 'up to date' and to support read, write, and delete access to the information.  For reporting and analysis we look at information with respect to a particular point in time or period of time, focus only on read access to the information, and often need to look at very large volumes of data all at once.

Improving and expanding the reporting and analysis capabilities of the Coghead service is a key area of focus for us over the next several months. 

Here is how people are currently using Coghead to meet their reporting and analysis needs:

• use the native form/view/collection features:  by using calculated and aggregate fields, collection linking, and customized actions people are able to merge many basic data analysis needs directly into the transactional systems they are building.  There are limits to this approach, however, as performance optimization for operational needs and reporting & analysis needs are typically at odds.
• extract data from Coghead into a desktop application:  people use the Excel and Word addins to extract data from their Coghead accounts and then use those products to display, print, or analyze the data.
• extract data from Coghead into a server-based 'business intelligence' system:  some Coghead users already use high-powered business intelligence products from vendors like Cognos or Business Objects and extract data from Coghead for use in those products.

Here is what we're planning to release in the very short term (4 to 8 weeks):

• an improved 'print from Coghead' capability: We are adding the ability to upload customized templates to Collections, and then to print reports directly from the browser.
• an improved external API:  Release of our API and the documentation will make it much easier for people to extract information from Coghead for use in various reporting solutions.

Here is what is going to start arriving in the next 2 to 4 months:

• improved query flexibility:  e.g. better ability to group and organize results.
• analysis-optimized Collections:  the ability to create separate collections specifically optimized for analysis & reporting needs
• expanded set of reporting-oriented widgets: this includes graphs and charts and other data visualization oriented widgets.
• better integration to 3rd party business intelligence products: we will be adding features to make it easier to integrate to on-premise BI products and to some of the BI services that have recently come on the market.

In summary, improving the native reporting and analysis capabilities of the Coghead platform is a very high priority on our roadmap, and many new capabilities will be arriving soon.  The general category of 'reporting and analysis' capabilities, however, is extremely large and we need your continued feedback to help us understand which features are most important to you.

Greg on GigaOm

Check out Greg's article "How Not to End Up as an Anachronism" on GigaOm.  A great read on SaaS infrastructure - particularly as it relates to Amazon's EC2 and S3.  Enjoy!

We've been busy, very very busy

by Greg Olsen

You've probably noticed we've been pretty quiet with respect to product announcements over the last several months, and it was for good reason.  The entire engineering and product management team has been heads down implementing a set of significant improvements to the Coghead service that will provide both short and long term benefits to service users (these updates will appear on the service by mid-December).  The engineers have put in an amazing effort that we're all very proud of (and soon they will be able to re-establish relationships with their friends and family members whom they haven't seen much of for months). 

The Analysis

Back in June we saw an opportunity to improve two critical aspects of the Coghead service:

- Client performance, robustness, and usability: The Coghead client (the user interface that runs in the browser) was very feature rich, which was good, but was slower for many type of interactions than it needed to be.  Sluggishness was significantly degrading usability, particularly for users on client hardware with less memory or slower cpus.  Some of these users were also experiencing timeouts on forms that were rich in content.  We were also generally unsatisfied with the speed at which we were able to make UI changes (both for performance and usability) and our ability to automatically test the UI.

- Cost effective support for very large scale expansion of the service: Interest in the platform was high and we saw that we would need to support rapid expansion in both direct users of the service and in Coghead affiliate related users.  It was also clear that many Coghead users were outside of North America, and that international growth was going to be earlier than we expected.  Our hosting infrastructure was adequate, but it would have required significant ongoing investment of resources and focus to handle our expected growth profile.

The Decisions

We decided to make two significant upgrades to the service:

- Change the underlying client-side technology infrastructure from openlaszlo to Adobe's Flex:  We'd been following Flex since its introduction, and after Adobe changed its licensing model and introduced Flex 2.0 and the Flash 9 runtime, it became very interesting.  The runtime behavior of Flex-based code in the Flash 9 plug-in was significantly better and the available development and testing tools were also better.  We determined that by changing to Flex, our UI would perform significantly better and it would be much easier to develop and maintain.  The future prospects of the Flex platform (e.g. Flex 3, Flash 10, and AIR) and the rapidly growing community of Flex developers worldwide were also compelling.  The challenge was that switching to Flex basically meant rewriting the entire UI implementation.

- Move our server-side hosting infrastructure to a service-based grid deployment using Amazon's EC2 and S3 services:  Like Adobe's Flex, we'd been watching the evolution of Amazon's Web Services offerings for a long time.  Back in February, we began experimenting with deployment of the Coghead service on an EC2 instance.  The Amazon EC2 and S3 services were appealing for multiple reasons. The cost efficiency was certainly compelling.  Our early analysis showed a significant reduction in projected costs for comparable cpu and storage.  The network infrastructure was also compelling with excellent peering and future prospects of geographic distribution.  Finally, the federated deployment architecture we could deploy on EC2/S3 would allow us to deploy a very robust service that relied much more on automated recovery and management than on data center staff or on hardware reliability.  Our service could be more agile and cost efficient as we adapt to changing needs of customers.  The challenge was that work was required to adapt our deployment architecture to a federated model that took full advantage of the EC2 and S3 services.

The Implementation

After several months and many late nights, we completed the Flex rewrite of our UI implementation.  For the most part, the new UI is a reimplementation of the old UI - although we did take the opportunity to slip in a few key improvements to usability based on feedback from our user base (details on these changes will be described in a separate post). Overall the result is even better than we expected.  UI performance is significantly improved, and our development velocity is significantly increased.  Not only are our developers more efficient, with better tools and automated test infrastructure; we've been able to more rapidly ramp up new developers and have more than doubled the size of our UI dev team. Over the next several months, we will be implementing a wide variety of new features that will further enhance the user experience for both direct users and affiliates.

The move to EC2/S3 was executed through a series of steps dating back to February.  We designed a load distribution, failover and instance management scheme that leveraged the EC2 and S3 services and that would provide high service levels for Coghead users.  The design supports dynamic failover to minimize service distruption and it allows us to allocate compute and storage resources with fine granularity to match customer usage needs.  The implementation started in late June and has gone through several iterations and through extensive simulation testing.  The result is a server infrastructure that will provide an immediate improvement in service levels (uptime and latency) and will support customer growth far into the future.

Conclusion

Very shortly next month, the Coghead service will experience two major upgrades that will provide significant benefits to Coghead users. There are certainly more improvements to be done, but our users will immediately experience a much better service that will improve much more rapidly going forward.  I'm extremely proud of our engineering team and the amazing result they've achieved in a relatively short amount of time.

Coghead and Facebook

By Paul McNamara

We've just created a new Facebook group called "Cogheads".  If you are passionate about Coghead, it's a great place to find blog content, articles, events and other resources...along with a picture gallery of "the Dude" (the man in the Coghead logo) showing up in the strangest places.   Its also a great way to meet other Cogheads to share tips, tricks and successes.  If you don't already have a Facebook page, you can create one here.  Once you have a Facebook page, then you can join the Cogheads group here.   I look forward to meeting more of you through Facebook. 

Users & Developers: Applications & Pastries

by Greg Olsen

There was a time in the world of software when application developers and application users were entirely distinct and separate groups of people.  'Developers' were a small and select sect that possessed highly specialized skills, beyond the comprehension of the much larger and more ordinary group called 'Users'.   Their relationship to each other, resembled the relationship of a professional pastry chef to the people who consumed his pastries - developers cooked, users ate.

As we all know, the world of pastries isn't just about professional chefs, bakeries, and their customers.  Few people, in fact, are pure "users" of pastries.  Nearly everyone participates in some form in the development of pastries - e.g. home-made recipes, packaged cake & brownie mixes, brown and serve rolls, easy bake ovens, bread machines, etc. 

Today, the world of software is very comparable to the world of pastries.  Few people are exclusively pure end-users of applications.  Very basic forms of 'more than end user' activity include:  application skinning; the use of application add-ins, plug-ins, or extensions; dashboard/desktop configuration with widgets or gadgets; and custom map creation for games.   Between these relatively simple forms of application development and 'hard-core' software development performed by professional programmers, there exists an ever richer continuum of application development options to match an ever more diverse set of developer skill levels and needs.

Podcast: Coghead and Going Bedouin

By Sarah Franklin

Not only did Greg Olsen, our founder and CTO, coin the phrase "Going Bedouin", he has also instilled the culture into the essence of Coghead.  What is "Going Bedouin" you may ask?  In Greg's own words, the workforce of a Bedouin company are a "roaming nomadic tribe carrying laptops & cell phones and able to set up shop wherever there is an Internet connection, chairs, tables, and sources of caffeine."

Coghead delivers a service which allows a company to adopt a Bedouin culture, and continue to collaborate effectively through business applications.  As part of our launch at the Office 2.0 conference, Greg conducted a podcast focused on how Coghead makes "Going Bedouin" possible. 

Click below to play the podcast, or you can download the mp3 directly.

 

P-waves in the CAD Market

Milt Capsimalis, an Autodesk veteran, sent me a great email relating his experiences in the trenches of the CAD industry.  With his permission, I've re-printed his email below:

It's interesting to see what happens to the incumbent vendors as a p-wave comes through...

Take the example of AutoCAD’s competitors in the 80s and 90s.  AutoCAD was a classic p-wave in the CAD market. 

Before AutoCAD, CAD ran on high-end (often bundled) workstations and could cost nearly $100k for a seat - more if hardware was bundled.  It was sold by Armani wearing direct sales reps, often in conjunction with equally slick consulting providers like IBM or EDS. Deal sizes were in the millions and warranted press releases and launch parties with lots of jumbo shrimp.

Autodesk released AutoCAD in 1982, a drafting package that ran on the PC and cost a few thousand dollars (plus some set-up help by a local value added reseller).  Customers bought it in exactly the way you describe p-wave adoption.  Individual users, or perhaps the manager of a team that couldn't afford CATIA seats, would go out and get AutoCAD.  Third parties sprung up to develop vertical applications, training, books, file translators and everything else needed to support these users.  Very little of this was controlled or even understood by Autodesk.  Copies of AutoCAD began to populate small companies that never would have bought CATIA or CADAM, but it also showed up on the PCs of almost every licensed user of these high-end products - just because it was so cheap and easy.

There is a famous story (I think it's even true) that one day a large automobile company's IT department did a company-wide software audit and turned up thousands of seats of AutoCAD.  Interestingly, AutoCAD was not their approved CAD solution and they didn't have any official relationship with Autodesk.  No volume license agreement, no support contract, no room full of services people billing them monthly...nothin'. Just thousand's of draftsmen creating the companies most important intellectual property without any support from IT.  This was clearly a p-wave moment.

There isn't anything surprising about the fact that a new, disruptive technology made life miserable for an old guard technology provider.  It happens all the time.  The interesting nuances are in the old guard's response to the p-wave.

The conventional wisdom is that the incumbent vendors are either:

1. asleep at the switch and didn't even see the train coming, or
2. full of stupid people who couldn't have responded to the new technology anyway

In fact, nothing could be further from the truth. During the 80s and 90s the high-end CAD vendors were full of capable engineers, managers, marketeers and sales folks.  The demographic of these companies tended toward people in their 30s and 40s at the height of their games. What's more, the companies could afford to do things like train their engineers in new programming languages and new development techniques and send them to industry conferences where they stayed up on the "buzz".

It wasn't that the people in these companies didn't see AutoCAD coming...it was worse.  The companies were wired down to their DNA to resist the kinds of changes that would allow them to compete effectively.

Take the automotive example.  How did the approved CAD vendor respond?  As it turns out, their engineers had long since developed a package for the PC.  It was probably even better than AutoCAD for automotive design.

So, did they release it to the market at a competitive price point? 

Did they recruit value added resellers to handle the smaller deal sizes that PC products bring? 

Did they ditch their Armani for Birkenstocks and hire more engineers to work on making the installer easier to use or support Windows?

Uh, well, no...

They did release the PC product.  I think they even recruited some VARs.  Then a funny thing happened.

Every time they tried to sell the product to their current customers (the ones that Autodesk was stealing) the direct sales organization would block them by claiming it was cannibalizing their own sales.  Since sales of their high-end products were still the bread and butter of the company, they usually carried the day.  It's tough to argue that you should sell a $3,000 product against a $30,000 one.  Of course many of those $30,000 per seat sales never materialized because of competition with someone else's $3,000 product.  But, none of the executives were willing to tell Wall Street that their 3rd quarter miss was attributed to migrating their customer base from products with huge margins to low margin ones in response to a threat from a still smallish company that Wall Street didn't know.

The competitive products essentially died of fratricide.   

The s-wave can take a long time.  That vendor soldiered on for years as their deal pipeline slowly dried up and their customers used Autodesk and other vendors as a lever to drive down prices.  After twenty-five years there are only really two of these high-end CAD companies remaining.  They primarily sell to a couple of dozen automotive and aerospace companies and their first tier suppliers.  The rest have either been acquired or gone away.  The remaining companies still have real businesses, but they have been forced into more and more boutique markets and rely more heavily on services to make their numbers.  Meanwhile there are more than 7 million AutoCAD users and a new crop of low end competitors that don't have a legacy beast to feed...

What’s gonna happen when Microsoft tries to respond to Google saying that you don’t need to buy applications anymore?  Is Oracle really going to be interested in renting their application and databases for a very small percentage of what they make on selling the software? They all see the writing on the wall and all say the right things, but what happens in that meeting where some smart-ass application engineer (ignoring deal size and commission structure) says, “Hey, XYZ Corp. doesn’t really need $6M worth of Siebel, they can get started with 200 seats of OnDemand!”????   Maybe Larry is visionary enough to see these things, but that sales rep is gonna stomp on that kids foot under the table hard enough to break bones.  I know, I was that guy once….

Part 5: Software Simplified -- The Next Technology P-wave

By Paul McNamara

Technology p-waves happen whenever there is a shift in the technology landscape.  The magnitude of the shift determines the magnitude of the p-wave.  The p-wave is the first big buying wave consisting of a large number of small-scale decision makers (biz-summers) acting quickly. 

Another technology p-wave is about to happen, and I think its going to be a large one.  The shift in the landscape will be toward using the Web as a Platform for creating new kinds of collaborative application.

The success of Software-as-a-Service (SaaS) applications is a proof point for the upcoming transition. 

So far, most SaaS applications have been simple re-implementations of the types of applications that exist in the packaged software world.   For example, Sales Automation applications have been available as packaged software for many years.  Salesforce.com reimplemented this type of application as an on-line application and is having great success.

I think that the reason that Salesforce.com is having success is not that it's a radically better sales automation application; rather it's because the solution is good enough and can be implemented quickly by autonomous decision makers.  Someone can make a decision to implement Salesforce.com and get it up and running in a matter of hours.  It allows people to solve their own problems without having to go through a long bureaucratic process. 

But today's on-line applications are just the beginning of a major shift in the information technology industry.  It's the small earthquake that often precedes the Big One. 

Part 4: Technology P-Waves -- 'Biz-sumers' Jolt the Market

By Paul McNamara

In the previous two articles, I've discussed prior technology p-waves.  But what do these two seemingly disparate examples have in common?  Plenty:

1. A critical need develops at the grass roots level that is not fully understood at the executive level.

2. Individual contributors and first line managers independently discover a practical solution, enabled by new technology, that can solve the problem quickly.

3. The nature of the solution is such that an individual contributor or first line manager can autonomously make the decision to adopt the new technology.  This invariably means that the solution is relatively low in price and in risk, is easily implemented, and doesn’t require the approval of higher-ups.

4. The solution is generally compatible with existing methods.  The PC hooked into the wall (the network) just like a 3270 terminal (and, because it was from IBM, it was considered safe to do this) and you could use it just like a 3270 terminal.  In the case of Linux, it worked just like Unix.  Someone who understood Unix felt right at home using Linux.

So there you have it: a small decision gets made to try a new approach.  If the approach works, other people notice it and replicate it.  Soon a cascade happens – the p-wave thunders across the landscape.  Lots of people start making the same small scale decisions, but in aggregate, it represents a huge tectonic shift in the very essence of how people use technology.  Only after the cascade is fully underway and the p-wave is felt do large scale decision makers become aware of it and begin adopting it.

The prevailing wisdom is that consumer purchasing behavior and business purchasing behavior are completely separate and distinct.  Consumers make fast, autonomous decisions.  They use cash, check or credit cards.  They buy from retail outlets. 

On the other hand, traditional business buyers take longer to buy, and make collective decisions.  They use purchase orders or sometimes Letters of Credit.  They buy directly from the manufacturer or through commercial distribution.

P-wave buyers don't fit into either of these descriptions.  They are more a hybrid, somewhere between a consumer and a traditional business buyer.  We call them 'biz-sumers'.

P-wave biz-sumers are nearly always, to use Bryce Ryan's and Neal Gross' term, "early adopters".  They make decisions fast, in a semi-autonomous fashion.  They pay with credit cards.  They buy from anywhere -- retail, direct, commercial distribution -- whichever is easiest and fastest.  Web-purchasing is the preferred method.  Biz-sumers don't like to talk to salesmen, but they do require a level of technical information that goes beyond what a consumer requires.  Bis-sumers want to do their research and get all of their questions answered on the web and want to be able to find all of the pertinent info quickly. 

I've drawn an analogy between a technology shift and an earthquake.  And I've described how earthquakes happen in two phases -- the p-wave (a short powerful impulse) and the s-wave (the sustained shaking).  In reality, the p-wave and the s-wave emanate from the same spot.  The reason we experience them as two different events is because they travel at different speeds.  The p-wave travels much faster than the s-wave.  How far you are from the epicenter will determine the time interval between when you experience the p-wave and when you experience the s-wave. 

A technology shift happens the same way.  The p-wave of a technology shift is characterized by large numbers of smaller-scale decision makers (individual contributors and first line managers) nearly simultaneously deciding to adopt a new approach.  The technology p-wave travels fast because biz-sumers decide and act faster than larger-scale decision makers.  They are closer to the problem and their decisions carry less risk.

By contrast, larger-scale decision makers (like VPs and CxOs) make decisions more slowly.  They are farther from the problem, take longer to become convinced that there is a problem and since their decisions carry more risk, they require a more careful and deliberate decision making process.

But it is the p-wave that often determines the fortunes of technology companies.  Those technology companies that win during the p-wave usually go on to dominate the new landscape: IBM, Microsoft, Intel, Red Hat.  And those that miss the p-wave, invariably come in a distant second, if at all: Apple (in the PC wars of the late 1980s), Motorola, Caldera.

Part 3: Linux Displaces Unix and the Myth of the Basement Hacker

By Paul McNamara

Linux (and open source software in general) is another example of the p-wave phenomenon. 

There’s a myth that the early sales of Linux were to hobbyist who were using it to hack the kernel in their basements.  In reality most of Red Hat's early sales were to business users.

In the late 1990’s, corporate hunger for Internet infrastructure was voracious.  But most companies dramatically underestimated the growth of the Internet and their corresponding needs for supporting infrastructure.

In the mid-90s, Unix was the natural choice for Internet Infrastructure.  But, buying a Unix server required planning.  It was a capital purchase and needed to be run through a careful, deliberate purchasing process.  Faced with a difficult and time consuming procurement process, enterprising people at the individual contributor level discovered Linux.  Linux was free or nearly free, worked with the Internet just as well as Unix, and (most importantly) could be loaded onto a surplus PC (and there were lots of them sitting in closets).  So people started setting up Linux boxes as web servers, proxy servers, caching servers – all manner of infrastructure edge servers as a quick and easy fix to satisfy the unbounded need for more Internet capacity.

Linux was a immediate solution to an acute problem.  Individuals and first line managers could autonomously make a decision to deploy a Linux box without needing to ask their boss, or for that matter, get approval from anyone.  Everything needed was within the decision making authority of an individual or first line manager. 

Interestingly, the executives at major companies didn’t know that this was going on.  In 1999, I spoke at an industry event where a CIO (who I won’t name) of a major bank was also speaking.  This particular bank was a dyed-in-the-wool Sun shop.  In response to a question about Linux from the audience, the CIO said, with no small measure of self-righteousness, “I can tell you with absolute certainty that we have no Linux running on my network”. 

I had to smile to myself because I knew that this particular bank had more than 400 Red Hat installations on their network, almost all of them deployed by different individual contributors within the CIO’s vast organization.

As with the PC revolution that I described in the prior article, Linux made its way into the business world not as the result of large, centralized decisions, but rather as the result of a large number of small decentralized decisions.

It's interesting to note that we at Red Hat didn't understand at first that most orders were coming from business people.  We also bought into the myth that it was hobbyist buying our stuff.  And why not -- the orders just seemed to come in from a flood of seemingly random people.  That's not how businesses buy.  Businesses issue purchase orders for large quantities.  We weren't getting any purchase orders.  Everything was coming in as credit card orders.

The Linux p-wave hit in 1998/1999.  It wasn't until halfway through the p-wave that we even realized what was going on.  The way we found out was a story in itself.  Our engineers had put a signature deep inside the OS that enabled a web-server to respond to a network query by saying "I'm an Apache web server that is running on Red Hat Linux".  Mike Prettejohn had formed a business called Netcraft which routinely pinged millions of web servers to gather statistics about the Internet and had figured out a way to read these signatures.  Mike called me in late 1998 and said, "are you guys aware that Red Hat is about to overtake Microsoft in the number of web servers on the Internet?" 

What?!? 

Bang! P-wave.

Part 2: The PC Revolution and the Forgotten Killer App

By Paul McNamara

I joined IBM (in their mainframe division) fresh out of college in 1984. The IBM PC was introduced in 1981, but by 1984 it was just really starting to take off.

It was a bit of a strange year inside of IBM. The company was hiring lots of people while simultaneously cutting the equipment budget of department managers. Back then, new hires would have a 3270 terminal on their desks that they would use to connect to the mainframe.

My boss had a dilemma. He was authorized to hire four new engineers into the group that year, but he didn’t have enough money to get four 3270 terminals (at the time a fully loaded 3270 terminal cost $8,000). So he pulled the department together for an impromptu meeting to present (with as much enthusiasm as he could muster) his plan -- that we all start sharing terminals.

At that meeting one of the more senior guys said, “I know this guy a few hallways over who's using an emulator to make a PC work like a 3270 terminal. He says it works just fine, all you've got to do is plug the coax into the wall. And, a PC only costs $3,000”.

Right then and there we decided to start using PCs rather than 3270 terminals. And at the very same time, department managers from the vast four corners of IBM were coming to the exact same decision. Information that PCs could replace expensive 3270 terminals spread like wildfire through the halls of IBM (much to the chagrin of the 3270 Terminal Product Manager!).

Conventional wisdom holds that the spreadsheet (Visicalc for Apple and Lotus 1-2-3 for the IBM PC) was the killer app that got PCs into big companies. It's true that lots of PCs got sold into the Financial Services sector because of the spreadsheet. But this explanation is somewhat incomplete. Outside of the Financial Services sector, a less recognized force was also at work. A small spark had ignited big sales of PCs to Fortune 500 businesses: it was the introduction of the lowly 3270 emulator. In 1983 IBM started selling a kit to make a PC emulate a 3270 and then in October of that year, IBM bundled the emulator with the PC and called it the PC3270. Sales of PCs to Fortune 500 companies exploded in the forth quarter of 1983. IBM was already selling hundreds of thousands of 3270s into the Enterprise space and the PC found a ready replacement market.

Department managers at nearly every Fortune 500 company realized at about the same time that PCs could replace terminals at a much lower cost.

This also helps to explain why IBM was able to beat Apple in the Enterprise – Apple, despite having a better personal computer with a better spreadsheet much earlier than IBM, didn’t have a 3270 emulator until 1987/1988. And, I suspect that even if they had one earlier, people weren’t at all comfortable connecting an Apple to a mainframe. The famous 1984 Apple TV commercial, while brilliant and perfect for building Apple's rebel brand, actually re-enforced the notion that Apple didn't want to play nice with the mainframe. So, with only a spreadsheet and a better product as a selling point, Apple simply wasn’t able to get any traction in the Enterprise market.

But here's the really important point: the PC initially took hold in big business not as the outcome of large centralized decisions made by executives but rather as a result of a large number of small, decentralized decisions made by department managers. It wasn’t the outcome of a grand strategy, but rather the need to just get something done within a restrictive set of boundary conditions.

Once the PC found a place on people's desks, the stage was set for the introduction of a whole new generation of applications. And whereas IBM later lost the PC hardware game to the clones, their early leadership in PCs (and in particular, PCs attached to networks) allowed them to capture the much larger integration, services, middleware and infrastructure business (the s-wave) that grew from this new generation of applications.

The PC p-wave took place in late 1983 and 1984. The sucessful adoption of the PC by a large number of individuals acting independently proved that the technology was safe for business use. The landscape shifted dramatically. Of course the energy of this technology earthquake continues to shake the ground to this day; but it was that critical juncture in history, that momentary impulse in 1983 and 1984 that signaled the start of a new era in technology.

Part 1: An Introduction to P-Waves

By Paul McNamara

These days, consumer technology seems to come at us in ever more frequent waves: cell phones, iPods, GPS receivers, in-car DVD players. The pattern is familiar -- a new technology comes to market, a few intrepid souls start to use the technology, these 'Early Adopters' demonstrate success, and others see their success and decide to adopt the new technology.

Technology waves also sweep through the business world.  But the adoption patterns of new technology by business users are subtly different from those of consumers.  As I hope to show in this series of articles, these subtle differences have far reaching consequences.

In the business world, technology waves often have two distinct components. The first part of the wave occurs when small-scale decision makers choose to adopt a new technology to solve an immediate and practical problem. Each of these individual decisions is small but, in aggregate, can represent a major trend. These small-scale, semi-autonomous decision makers act in some ways like consumers and in other ways like business buyers (Greg calls them 'Biz-sumers'). The second part of the wave occurs when larger-scale decision makers choose to adopt the new technology.

The two components of the business technology adoption wave are similar to the two components of a seismic wave -- the so-called p-wave and the s-wave.

Anyone who has ever experienced an earthquake knows what a p-wave is -- although they might not know it by its technical name. It's the initial jolt felt after a fracture occurs. It's a sudden shock that seems to come out of nowhere, without warning, and in the case of a large earthquake, feels like someone is trying to knock you off your feet.  The actual shaking that most people associate with an earthquake happens several seconds (or 10s of seconds) after the p-wave and is known as the s-wave.

Shifts in technology use in the business world often happen like earthquakes. At first, they are felt suddenly, like a p-wave.  After the technology p-wave, things continue to shake in the industry -- often for several years -- like an s-wave. But it's what happens during the p-wave that can determine winners and losers.

In this six part series of articles I'll examine technology p-waves. I'll cite some prior examples, pull together the common elements of technology p-waves to create a generalized model, look at the potential for a new and major technology p-wave in the near future, and finally, explore the implications to start-ups of a new p-wave.

Software’s Glorious Revolution

by Greg Olsen

After many months of reading, I finally finished Neal Stephenson’s System of the World  (the last volume in the Baroque Cycle trilogy), and I discovered an unexpected reward - the realization that we are in the midst of a profound revolution in the software industry and that we are witnessing the establishment of a New System of the Software World.

The Baroque Cycle explores the economic, political, & religious structures of Europe around the end of the 17^th century and the profound changes that led to a transition from a land-based economy ruled by monarchs and anointed nobles and steeped in superstition, to a system governed (to a much greater degree) by capitalism, democracy, and rationalism.  The “Old System of the Software World” that I grew to be familiar with was ruled by its own monarchs and nobles, and had its own superstitions. The Powers carried names like IBM, Oracle, Microsoft, Sun, and OMG and the nobles carried the title “architect” (see Joel’s discussion). We possessed hope and faith that the directives of the architect nobles would protect us from the plagues of instability, unscalability, and inextensibility.