Below is an new core visual -- which is itself a work-in-progress -- for thinking about social business models.  It's part an ongoing strategic line of thinking that I've been developing lately to do some direction finding on strategic uses of social computing.  It's also part of a new book contribution that I completed today on the underlying future of the Web and business, which I'll publicly announce as soon as I can.  For a while now, I've been trying hard to really dive deep down into the macro conditions that are remaking the enterprise landscape and society as a whole since the downturn.  There are some really fascinating moving parts here, though the full picture is still unclear yet.

So for now this is my best take yet on the subject but it's far from done and I'll revise it again soon: There are still some "weak signals" of some very interesting new trends that I'd like to try to isolate and amplify, including 100% borderless enterprises, emerging relationship capital markets, unified social communications, and a few others.  I'll be exploring these here and elsewhere in the coming months.

This visual captures the fundamental shifts that are happening in the global marketplace today, in particular social business, including the following fundamental transitions:

Note: I get a lot of comments about the resource constraints item in the above list.  The criticism is usually around how we won't face such constraints in the 21st century, at least in terms of human resources.  I don't think that's the case however.  It's clear that in the 21st century that all resources used in business will have a much higher perceived cost than they do today.  This is more than just the growth of green sensibilities or concerns about renewable resources and sustainability. Rather, it's likely that as the world gets more developed that even human capacity, which is profoundly tapped into by social business models, may ultimately be constrained like they are in so many advanced countries today by factors such as low birthrates.  This has major consequences for developing nations, which might be able to use social business models for a huge catch-up effort in 10-20 years.  However, my actual point is the that resource abundant environments in today's businesses will inevitably become strapped when faced over time with economic deflation from non-commercial and highly competitive social business communities which can do so much more with less.  This has happened with commercial software/open source and traditional media/social media, and it's starting to happen to other industries as well.

I believe the shifts above are being driven by the following forces:

• Ambient communication - Today, everyone can talk to anyone, just about anywhere for nearly (thought not at) at zero cost.
• Global information flows - The largest, fastest growing, and most freely flowing source of information available is the Internet.  This trend will only continue into the future as all information platforms move online.
• Social computing - Social models for communication, collaboration, and business are proving to be more effective and fundamentally better than non-social ones.
• Market discontinuity - There is both space and demand for major changes in the way we do things in business today.
  

It originally came from my piece on ZDNet about the twenty-two power laws of the emerging social economy, though I've updated it a fair amount here.  I'll be exploring social business and Enterprise 2.0 much more in the near future.  In the meantime, it's worth taking a look at these recent pieces as well for more background:

12 Rules For Bringing 'Social' To Your Business

Top Ten Issues In Adopting Enterprise Social Computing

The Emerging Case for Open Business Models

Social Business and Next-Generation CIOs - Exploring The Macro Conditions

As always, I greatly value comments below on your thoughts on this and where social business is heading.

Recently for some work that I'm doing I had to revisit the techniques for creating successful online social environments.  This is a surprisingly deep and nuanced topic that we as Web application architects or enterprise social computing practitioners are just now fully beginning to grasp.  The subject matter itself runs the gamut from key conceptual underpinnings -- esoteric topics like systems theory and network effects -- to the daily grind of understanding and managing the needs/expectations of an often difficult-to-control community of actual, live people.

In general, I've found that the ideas behind social systems themselves are clean and elegant while dealing with their practical realities can definitely be messier and many find them annoyingly unpredictable as well.  In the end, online social ecosystems are invariably a fascinating mix of the classic vagaries of technology and people.  However, despite the apparent science, making them grow into something undeniably successful is still very much an art form. 

Interestingly, there's no real name for this skill yet and it's an important -- even vitally strategic one -- for any organization that has to engage with a lot of people over a network. And that's increasingly most of us in these days of the ever-present Facebook news feed, Twitter microblog, and workplace Enterprise 2.0 environment.  It also means that creating a workable online community requires a good dose of hard-nosed engineering as well as highly effective "soft" skills in UX design, social architecture, and community management. For it to really work -- to have a vibrant and growing community -- you have to seamlessly connect both of these worlds: a well-crafted social environment together with the people that will use it. The rewards for doing it successfully speak for themselves: Ultimately, businesses and communities are groups of people, and if they produce more value for each other together than they can individually, then there is something in it for everyone. And the online world lets us create these entities far easier, more quickly, and with larger populations than ever before in history.

Related: Network effects are just one of several dozen "power laws" that social architects must know today.

We used to call this process "founding a business" or "creating an organization".  We would call the people that did this entrepreneurs or occasionally philanthropists if their goal was non-commercial. But this terminology doesn't seem to apply as much to what's happening now.  For one thing, communities are organized differently and frequently have other motivations for participation than the usual one for traditional businesses: the worker/employer relationship.  Second, the output of large distributed online communities -- especially when focused on discrete outcomes -- can greatly exceed the results produced by densely concentrated single institutions.  While we are certainly in the very early days of this phenomenon, I've frequently pointed to numerous examples of these new models for creating shared value. 

So putting aside the socialism vs. capitalism arguments for now (they are increasingly brought up in this discussion, though why they don't seem to apply here is the subject of a future post) the 21st century networked economy -- powered by people and knowledge connected together globally at virtually no cost -- has set free fundamentally new ways of innovating and collaborating for mutual benefit.  Specifically, it's the rules for how these new mechanisms thrive and create value that is the object of discussion here.

For my own part, I've been fortunate to encounter ways to reduce the concepts for creating growing social ecosystems to a short list, the key ones which I'll present here. Please be warned, some jargon is necessary, but I will explain it along the way.

How To Create Self-Sustaining Social Ecosystems: The K-factor Lesson

Like my 50 Essential Strategies for Web 2.0 Products, this overview cannot possibly be exhaustive.  It does however highlight the central idea behind all successful communities: They are either busy growing or they're busy dying.  Gaining critical mass early on is another important lesson that we've garnered from the early Web 2.0 pioneers.  Finally, the aforementioned and mysterious K-factor is introduced and explained below.  

• Fiat and network effects are the two primary ways that social ecosystems grow.  The first is based on an explicit or implicit mandate of some kind.  An example of a fiat is when an organization requires participation in a particular social group, perhaps a committee or online community.  The second, a network effect, is when a social group has more value the more that other people are involved in it too (which is usually, but not always the case.) Keep in mind that the degree of value in each new member, or their contributions, is based on the structure or design of the social system and will vary greatly.  Also note that the fiat approach that is common in business today is a top down effort to "push" participation, while network effects are a "pull" method and tend to be more bottom-up and organic.  Background: Read more about push vs. pull systems. Critically, the degree to which a network effect is realized can be influenced by many factors not the least including the intrinsic nature of the social ecosystem itself and how it is connected to the rest of the network (the Web or your intranet.)  In general, network effects will ultimately be more successful than fiat for most purposes, especially since the use of social systems are so often made optional, even in business environments.
• Network effects can be encouraged by promoting self-sustaining growth via feedback loops (aka virality).  One of the myths of the online world is that viral growth can't be engineered. While it's sometimes not straightforward, it can indeed be created intentionally. While cynical uses of virtuous growth cycles won't produce results for long, the basics work best: letting any user improve the community by contributing knowledge, often to a lightly structured data set or encouraging them to invite their friends and colleagues.  In fact, any good social ecosystem will make it easy and rewarding to do so, such as allowing users to discuss, converse, jointly edit, or otherwise work together on common goals.  Stated another way, the future of software applications that don't provide more value when more people are present in an interaction is probably going to be fairly short. A good place for more background on the lifecycles of systems (social or otherwise) is William Varey's Unlimited Growth.
• Measure your K-factor and keep it above 1.  The K-factor of an ecosystem is a statement of whether your network effect is self-sustaining or not.  A K-factor of less than one means that your organic growth level is falling (exponentially) and a K-factor of greater than one means that it's growing naturally and again, exponentially.  How to increase your community's K-factor? There are literally countless ways but allowing users to contribute to hard-to-recreate data set, adding user distributable widgets that provide useful offsite functionality, as well as integrating meaningfully with 3rd party social networks through their application model are a few of the more popular and effective ones.  I explored some of these distribution approaches in more detail a while back in my overview of the new distribution models of the Web.
• The higher the social feedback loop intensity, the higher the breakthrough factor.  Feedback loops are created for example when a user invites another user to the community and then that user invites their friends and so on.  However, the quality of the feedback loop is a measure of how often it reaches outside of the community and how effective that outreach is (often stated as  k = e * i, where “e” is the efficiency of the feedback loop and “i” is the average number of invites per user.)  An individual user's ability to affect the quality and intensity of the feedback loop is usually a measure of their social surface area, which I generally consider to be the size of their social graph x the number of online channels they use x the frequency of participation x the amount of influence they exert. If you have a social ecosystem with a lot of influencers or users that are very active online, they will clearly fuel the response to your feedback loops more effectively. The design of the social environment itself also has a major effect depending on whether it makes it easy to invite others or otherwise create feedback loops.  A breakthrough factor is achieved when the feedback loops rise above a certain threshold of attention, such as when multiple invites come from multiple persons over a short interval of time.  When this threshold is crossed for a prolonged period, the K-factor increases much more rapidly.  This rise can be self-sustaining (the so-called virtuous cycle) and can lead to a permanent and dramatic growth climb as evidenced by many of the popular social networks early on, such as MySpace and Facebook.
• External "high impulse events" can be used in the short term as a catalyst to reach the breakthrough factor.  This was famously the case with MySpace which used a database of 50 million e-mail addresses to drive initial users to the site, whereupon their feedback loops soon created a particulary strong breakthrough factor.  Traditional marketing is often used as the seed to drive the initial population of communities, but unless the K-factor soon rises above 1, the long-term cost of this approach is usually prohibitive.  It's worth noting that it all my research, I've never encountered a community that was successful long-term without naturally self-sustaining growth.  This is the K-factor lesson of this post's title: You can grow any community in the short term using artificial means but it will only last and continue to grow on its own because of the inherent quality of the people and the knowledge that has accumulated.  That said, you must get your community growth primed in some way.  High impulse events can include (by no means exhaustive) traditional marketing, paid incentives (expensive but Paypal was very successful with this model in its early days), and -- particularly for business communities -- seeding initial high value content.
• Growth in a social ecosystem is not endlessly exponential and eventually hits a ceiling. Plan for it.  Typically described by the S-curve, it is encountered when you either fight an existing network effect or when resources are exhausted on the network.  While hitting the upper bound of the S-curve is desirable and denotes a successful system (Facebook is just hitting this now), it can also be an indicator of a failure or a bottle-neck in the feedback loop design.  A false S-curve is most often evident in my research when a community undergoes a major UX redesign and users have to find their way again, often unable to find and use the features that drive growth and sustain the commuity. Be aware of this and guard against the potential causes of premature S-curves.
  

I've written in the past about deliberately creating emergent phenomenon and then capturing some kind of value from it.  Like most efforts on a fixed scale of zero to the maximum possible result, there is a reverse bell curve effect, meaning that most people will get middling results, some will get very poor, and some will hit it out of the park.  From the projects I've been involved in, I find that the most successful social efforts are ones that are highly agile and willing to capture lessons learned early and often and then make changes quickly and do it all over again the next week.  The Web favors those who experiment, adapt, and evolve and thus should go your social ecosystems.

Good luck with your social media and Enterprise 2.0 efforts.  Please don't hesitate to ask questions below or contribute your own wisdom.

The inimitable Fred Wilson concluded yesterday in "Why Social Beats Search", that "[m]achines can help us find what is good. But with the help of machines, our friends and trusted sources can and will do that even better."  This statement capped off a fresh debate over the weekend about automated, keyword-driven "McContent" creation that started when Michael Arrington posted about "the end of hand crafted content". Richard MacManus also explored the same issues in "Content Farms: Why Media, Blogs, and Google Should Be Worried".

I find this discussion very intriguing because it's nearly a mirror-image to the still-unfolding story of the last big change in this space: How the volume and timeliness of social media has disrupted traditional media.  I explored this subject in-depth recently on ZDNet about how this same transformation is now happening more broadly to other industries as well.  Now we're full circle already: What went around with social media is coming around again rather quickly with McContent. The machines are in the upstart role this time and have the potential to displace social media "moms and pops" who might not be able to match the volume and speed at which automated content can be created.  That of course, depends on if you believe that machines can match the quality of handmade content.  And indeed, if quality ultimately matters as much as volume and timeliness. There's a balance here that I'm not sure we fully understand yet but I'm betting there's probably room for the full spectrum.  This will only be true, however, if we are prepared to accept that the online landscape and current ways of doing business are going to continue to evolve rapidly.

The premise of today's information abundance reaching an unsustainable place isn't a new one. Information overload is a  rapidly growing subject that a lot of smart folks are talking about these days.  One bright area however, and this is the point that Fred Wilson touches on, is that social systems might actually provide an effective filter that will separate the wheat from the chaff by decentralizing the expertise and work of content curation into a sort of crowdsourced collaborative process (an increasingly widespread approach.)  This could make it both scalable and sustainable and I do believe that social content curation is an important trend.  But it's only one step in the right direction as we head into the future dominated by truly vast information abundance. 

One holy grail of search is "search that finds you" just as and when you actually need it.  Encouragingly, I'm now starting to see this happen with social environments like Twitter where I've received more and more tweets lately in the vein of "@dhinchcliffe Thanks for the link, was just looking for this 10 mins ago!" This is the seed of a trend that could be exploited by a very smart company that created the right product design that systematically optimized social recommendations and content referrals into something so much more than it is today: ad hoc serendipity.  Will the company that does this be the ones with the largest active social networks, such as Twitter or Facebook?  Or perhaps Google will figure it out as a component of real-time search?  Or will it just as likely be someone that no one has heard of yet? If the history of the Web is any guide, it will come from a place we won't anticipate.

I also suspect that other forces are in the running and may end up limiting the impact of distributed social curation, or more likely co-opting it.  Emerging trends like Web Squared and its autonomic filters and recommendation systems powered by data shadows as well as advanced forms of Enterprise 2.0 BI are just as likely to provide the solution in the medium to long-term.  Either way, search is only going to get better and social will certainly improve it.  That's not to say social won't disrupt search, but it may only complement the changes happening more broadly.  One big question is whether social can be made to scale enough to be routinely effective for most users.  In the end, that's the big question in my mind: The output of machines can always exceed that of people and that's not necessarily a bad thing as long as we still get access to both results when we need them.

The signs are pointing to next year being a banner one when it comes to mainstream adoption of the latest digital business models.  With half a decade under the belt of the Web 2.0 phenomenon and almost as long for Enterprise 2.0, we're just now seeing the ideas spread to more traditional corners of large enterprises, medium-sized firms, and especially the public sector with Government 2.0.

That's not to say that there hasn't been a rather impressive run-up already when it comes to what some organizations have already accomplished.  Indeed, some efforts have knocked it out of the park, such as the Netflix Prize competition, Booz Allen with its new award-winning Hello portal, or the distributed digitization of the New York Times by reCAPTCHA.  But new modes of value creation based on user generated content, open supply chains, and social computing -- to name just three of the major trends involved -- really are fundamental game changers that require as much cultural adaptation and shifting of the business mindset as they do real on-the-ground technology deployment.

Sidebar: What's the difference between Web 2.0 and Enterprise 2.0? This is always a point of confusion and to be clear, I define Web 2.0 to be the eight core principles as originally defined while Enterprise 2.0 is much more focused on enterprise social computing to the exclusion of broader digital business models like strategic data control, market size segmentation (The Long Tail), or innovation in assembly.

The good news: There has been broad behavior change across the globe -- particularly when it comes to consumer adoption of Web 2.0 -- and increasing acceptance of social models for carrying out personal and business activities both.  Not sure about this, just check out the more than 350 million active social networking users on Facebook, just one of many important data points about how fast we've changed our own social behaviors.  This has set the stage for serious and sustained growth and revenue opportunities for organizations that are prepared to adopt next-generation business models that can tap into and make positive use of these trends.

Related: The Top Must-Read New Topics in 2009 for Enterprise Social Computing

But if many organizations aren't quite ready to engage in truly transformative Web 2.0 and Enterprise 2.0 activities yet, what then are the first steps to start adopting these models? The implications themselves are increasingly clear: Organizations that want to make the transition to the 2st century successfully must 1) engage more socially internally and externally, 2) strategically open up business data and processes online, and 3) use new community-based power structures to tap into large online pools of productive capacity, innovation, and new types of customer relationships.

All of this can seem foreign and unnatural to the uninitiated at first.  Yet it's often key executives that have little immersion in the high impact, rapidly-evolving landscape of digital business that often hold the purse strings and make the go-head decisions.

But delay is no longer a viable option now that global adoption rates are as high as they are.  The potential for disruption and dislocation increases the longer that competencies in this area aren't developed and only a few industries have first-mover advantage remaining. What then are good ways to get started down the road without fully scrapping the way you do business?

Related: 50 Essential Strategies For Creating A Successful Web 2.0 Product

Fortunately, there are some increasingly appealing ways to apply Web 2.0 and Enterprise 2.0 ideas to your organization that will help you get a great start to the year in acquiring the full competitive advantage that these vital new approaches bring to the businesses that adopt them.  Some of these are specific while others are ones that you can apply just about anywhere.  Your mileage may vary and change often will not happen overnight.  The usual virtues work here: Persistence, patience, and responding by learning quickly from rapid feedback loops from the marketplace.  All of these factors will help you get the most out of the strategies below.

12 Adoption Strategies for Web 2.0 and Enterprise 2.0

1. Learn: Educate - Brown bags, internal Webcasts, strategy white papers, innovation unconferences. Digital business models are evolving so quickly that keeping up can be a real challenge.  Hot new topics such as Social CRM and online customer communities have become major new subject areas in the last 18 months, but most traditional businesses don't know about them yet.  There are many other emerging topics now and getting a steady flow of information into your organization about what's happening will greatly assist your efforts.  Lunch presentations, Webinars (great for large and/or distributed organizations), reports, social media, and internal events to share ideas about the possibilities are all good ways to break ground and get fresh ideas into heads. Use the attendees of these to identify like-minded change champions for some of the strategies below.
2. Learn: Find out what leaders in your industry or related industries are doing.  While the adoption of Web 2.0 and Enterprise 2.0 is often very industry specific (either a big player gets way ahead or consensus is reached and adoption suddenly happens broadly within an industry), you can often find great examples of approaches in industries that are different yet closely related.  Find case studies that have good measurements and data and use this to extrapolate to others.  
3. Learn: Discover and coordinate with what other internal Web 2.0 and Enterprise 2.0 change champions are doing already.  Use the people you met in the first strategy to find other pilot projects and resources that can be pooled.  Internal success stories are always the most convincing, even if turf concerns and not-invented-here continues to be problematic.  Often you can join in or combine efforts, particularly since Web 2.0 and Enterprise 2.0 are so driven by participation that it's virtually required by definition to get any sort of success, internally or externally.
   
4. Prepare: Identify the likely areas where Web 2.0 and Enterprise 2.0 can grow and/or improve your business.  I covered this topic late last year as the recession began to hit.  There are major areas where growth, cost reduction, innovation, and business transformation can be achieved.  Understand clearly how these approaches work and provide value, what growth/cost factors they consist of, and get specific with likely approaches in your organization matched to hard data to support the strategy in the next bullet.  If you're still not sure then explore these ways to use Web 2.0 to reinvent your business for the economic downturn.
5. Prepare: Build a compelling business case. If you can't explain the benefits clearly to the business, you don't get to do it.  But this can sometimes be hard with Web 2.0 and Enterprise 2.0 because there are on occasion long cause-and-effect chains.  But more likely there is just what I like to call the "digital DNA" problem.  Most businesses are far enough away from the technology itself that they have a hard time grasping exactly how these ideas actually work and can be made successful in their organization.  It's the ultimate not-invented-here problem.  So don't make decision makers figure it out themselves, provide step-by-step explanation of the specific whys and hows of your social computing strategy, open API division, or whatever it is that you've decided that presents the best opportunity.
6. Prepare: Solicit senior sponsors for advocacy, budget, and pilots.  This one is fairly obvious except that a sponsor in this case must be personally involved both in the up-front support as well as actual participation.  One of the single most important adoption factors is executive involvement through personal interaction.  This works best if it's a social computing approach, but can affect most Web 2.0 and Enterprise 2.0 efforts positively and significantly. Here are some specific tips for CIOs and CTOs.
7. Prepare: Broadly socialize the potential benefits in clear, lingo-free business terms.  Transmit the message loudly and clearly.  Don't become overly zealous.  The bigger the organization, the longer it will take to change.  Often, by the time you're just about ready to give up, things will begin to happen.  Use social tools to spread this message by example.  You can try using one of the freely available enterprise microblogging tools to do this..
8. Act: Initiate social media internally to drive forward internal change, under the radar if necessary.  Walk the walk and start a blog or internal community that discusses innovation or otherwise drives change.  Use this to support the previous strategy but if it's done right it will broaden and can easily become viral.  Worst case the change champions have a place to work together, best case it forms an early basis for an enterprise social computing strategy. It can also provide an initial demonstration of results and adoption statistics. Only do this under the radar if necessary and even so be ready to accept the consequences if this is the first of these strategies you start with (the ground not yet being fully prepared.)
9. Act: Create a targeted customer community. Engagement with real customers is the only way to trigger some of the larger benefits of Web 2.0 and Enterprise 2.0.  This can be tricky since it frequently requires much more support and approval to go outside the company.  So start targeted and highly focused.  Trusted customers and pre-identified loyalty groups or even trading partners are good places to begin and usually offer friendly audiences to try many of these techniques with until you learn the ropes and gain deeper understanding of the issues.
10. Act: Launch a pilot that is likely to produce noticeable returns in the medium-term.  Use all the strategies above to get started with a pilot that proves the ideas out.  Critical mass is a frequent issue with the pilot approach however and many recommend going as big as possible (but no bigger) to ensure there is enough participation.  Document everything and don't set expectations too high or too low.  I say medium term since social systems in particular are generally  less deterministic and are not as predictable (though far more rewarding) than traditional mandatory engagement models.
11. Act: Measure the results of any local Web 2.0 or Enterprise 2.0 effort, even if it's not yours.  Get the numbers and try to make sure they are accurate, they are ultimately hard to ignore.  I've seen a number of otherwise terrific efforts derailed by not backing up what was done with good measurement.
    
12. Act: Proactively manage and promulgate upsides as well as having a ready-to-present mitigation plan for any perceived risks.  In the end, business leaders want something that will move the business forward but they don't want the risk.  Have answers ready for them, though you don't necessarily need to broadcast this unless asked.  There are often unstated risk, control, and trust issues with Web 2.0 and Enterprise 2.0 and you must proactively defuse them.

While some of these may seem obvious and will be true of almost any business initiative heading into the unknown wilds of something new, there are important nuances for the Web 2.0 and Enterprise 2.0 arena for each one of these. I've left out a few good strategies including acquiring your way to Web 2.0 competency, it's just not going to work for most organizations at the moment, until there are richer targets.

While certain industries, particularly technology and media, have had a head start with these ideas, there is still a surprisingly large opportunity for the majority of businesses today to glean significant benefits and greatly improved competitive stance. Good luck putting your strategy together and have a great 2010 implementing them.  Please contact me to tell me your story or if need help realizing them.

Also see my 18 Emerging Topics at the Interaction of IT and Business for 2009 to see what other areas you should be focused on in your strategic planning for 2010.

What adoption strategies do you find the most effective? Please put your thoughts in comments below.

Those who follow my work know that I've been attempting to identifying the success factors for enterprise social computing as well as trying to clearly understand the potential issues.  What we've learned as a whole over the last year is that social computing, whether that is blogs, wikis, social networks, end-user mashups, social messaging, crowdsourcing, etc, is still a new discipline for which most organizations are just now learning the basics.

That there are many business benefits to social software is also increasingly evident if you keep up with the case studies, but there are also some very real challenges to getting there as well.  These challenges are mostly not technical in nature and while good social tools are a prerequisite, real success lies in creating genuine change in the way that workers, partners, and even customers engage with each other in a more open, collaborative, discoverable way.  We've found that, despite about half of all companies having the tools, how to get value out of them is still not generally well understood.  It might even be said that there is tool myopia, and that most organizations don't realize most of the process of moving to social computing is cultural.  Even the strategies to avoid potential risks and concerns with social media is currently ad hoc at best and missing almost completely at worst.  It's time for some positive change.  And as an industry, I think we now have enough knowledge to now do considerably better with Enterprise 2.0.

Introducing Pragmatic Enterprise 2.0

Today marks the culmination of several years of personal effort combined with some important collaboration over the last several months with two business partners that I value very highly.  This morning I'm very pleased to report that we've announced something that we're calling Pragmatic Enterprise 2.0, a service designed by experts in both enterprise IT and social computing.  It is aimed specifically for use by businesses that want the benefits of social media via access to a mature approach that truly addresses the needs and concerns of enterprise customers today.

Our partners are Asuret, a leader in strategic project intelligence, headed up by my good friend Michael Krigsman, and Socialtext, one of the most recognized names in Enterprise 2.0 and who provides the default toolset for Pragmatic Enterprise 2.0.  Although we always use the best tool for the job, we benefit greatly from having a standard toolset that is mature, has a broad range of functionality, best-of-breed capabilities, and with which we have a strategic relationship to drive unique customer requirements. You can read Ross Mayfield's announcement post here. For reasons that I will explain below, I truly believe this partnership will genuinely change what's possible and will fundamentally improve the outcomes of social computing efforts in enterprises around the world.

As I've discussed in the past, there's a lot more to effective enterprise social media than bringing a Facebook, Twitter, or Wikipedia clone into an organization and setting it loose, although that's a common pattern that can generate issues down the road.  Getting engagement and creating vibrant communities that drive business objectives forward in meaningful ways while minimizing exposure to unwanted outcomes is what real, effective social business is about.

How To Improve Enterprise Social Computing

You can find more about Pragmatic Enterprise 2.0 here or in the the Slideshare presentation below, but the key ideas are:

1. Consumer social media must have enterprise context added to it to fully function in the business world.  A straight 100% transplant of a consumer approach won't work for most organizations.  Neither will a rigid or heavyweight enterprise reinvention succeed either.  There must be an effective combination of the two that reflects modern business requirements yet retains the full spirit and potency of consumer social media.  We have brought together recognized experts with deep experience in both worlds to create a framework for delivering capable enterprise-class social computing.
2. Most organizations are just climbing the social computing competency ladder and need access to expertise.  Social computing is a new discipline that requires skills in building and managing communities and integrating their activities across lines of business.  Everything from community management to dealing with security and control worries represents a new domain for many companies. We are now at a point where there is a lot the Enterprise 2.0 industry has learned and we can proactively capitalize on this knowledge for creating better outcomes.
3. Understanding the actual state of a social computing effort must be easier.  Online communities, either internal or external, have a life of their own and when Enterprise 2.0 represents persistent, open collaboration, that means the right things must be in place to handle both positive and negative outcomes.  While negative outcomes are in a very distinct minority, they must be actively managed as much as the more desirable result.  This has been true of traditional IT projects as well, not because they spread information so quickly, but because it's very hard to understand what's really going on.  We have put together a unique approach that can address both sides of the coin and proactively guide projects based on a clear and updated collective intelligence based model of what is actually taking place in a social computing effort.  This gives intellectual control like never before to those who are running their Enterprise 2.0 initiatives and lets key issues like risk, trust, and control be dealt with transparently, something that has been relatively neglected up until this point.
4. There is no one-size-fits-all when it comes to Enterprise 2.0.  Every organization is unique in some aspects of their needs.  Some organizations need very good security while others are more concerned about cost-effective community management. Others need to bring workers up to speed quickly on social media literacy or need to create effective policy and governance around enterprise computing to ensure regulatory and compliance needs are met.  By using lean and agile approaches, we've cut the fat out of social computing adoption and avoided a fixed template that would drive up costs and complexity.  In total, we've integrated 70 best practices and approaches to social computing that are tailored to an organization's real needs.
5. Social computing is a journey, not a deliverable, and any approach must reflect this.  Though some aspects of a social computing effort are project-like and have a discrete delivery date, the real work takes place weeks, months, and even years later.  Managing enterprise communities and keeping them vibrant is still more of an art form than a science, although that is also improving rapidly.  And it's where much of the ROI comes in as well as it drives participation, a growing knowledge ecosystem, and deep, meaningful integration with the business. Pragmatic Enterprise 2.0 reflects this at its core and manages to the fact that a social computing effort often isn't "completed" until some hard-to-define moment in the future.  We now believe that moment won't be so hard to define or to reach.

Overview of Pragmatic Enterprise 2.0

I rarely use this blog to comment on my business work but I do truly believe that this is an important advance for Enterprise 2.0. I'm pleased to say that our early previews to analysts and customers has been favorable so far, though certainly we are not positioning this as a silver bullet, just the highest quality approach that we could put together with our best effort.  I would also like to solicit input and questions in comments from all of you below for additional feedback and discussion.  After all, it's about the community in the end.  I'll be adding links and news coverage of this story below as it emerges.

Resources | Press Coverage | Analysis:

Initial Pragmatic Enterprise 2.0 Site

Pragmatic Enterprise 2.0 Presentation

Ross Mayfield's Post on PE2.0

Sameer Patel's Analysis of Pragmatic Enterprise 2.0

Paul Greenberg's  Finally! A Three-Cornered Consulting Service for Enterprise 2.0

destinationCRM: Time To Get Pragmatic About Enterprise 2.0

IDC Analyst Mike Fauscette on Pragmatic Enterprise 2.0

Video Interview on October 22nd with Dion Hinchcliffe and Björn Negelman

Please join Michael Krigsman and myself for an in-depth Webcast on Pragmatic Enterprise 2.0 on November 11th at 1pm EDT.

Do you think enterprise social computing needs well-defined methods and approaches? Why or why not?

I spent the early part of this week in Oslo, Norway, a guest of Bouvet and the Norwegian Computer Society, there to help them drive forward some discussions on next-generation subjects in IT and business.  Specifically I was asked to present our latest findings on social collaboration and enterprise architecture, two of my favorite topics as many of you know. 

We also brought our Enterprise 2.0 Masterclass from Web 2.0 University  -- the next one is in Munich in October -- which I delivered on the first day. For the second day I gave the opening keynote on the subject of Enterprise 2.0 to the Kunnskapstinget 2009 conference in the morning. Then in the afternoon I presented our new findings on the evolution of software architecture to Bouvet's enterprise architecture coucil.

As I spoke about and discussed a wide variety of technology and business topics in Oslo with dozens of people, I was keen on learning the state of both social computing and enterprise architecture in Norway, a country that is small (only about 4 million residents) but has often had an outsized impact on technology and computer science in particular.  For example, Turing Award laureates Kristen Nygaard and Ole-Johan Dahl are Norwegians that are credited with inventing object-oriented programming, an approach that's become the foundation of most modern programming languages -- and consequently Web development -- including JavaScript and Ruby.  There are many other similar examples of Norway's advanced state of technological adoption.

I was consequently fascinated to see if the latest developments in Web 2.0 have had a broader impact this far north and I was gratified that I was able to get a pretty detailed picture as you'll see.

The State of Social Collaboration & Enterprise 2.0

My keynote on the second day was less than an hour and I had a lot to share.  The real challenge in presenting these ideas is that so much is going on in the social computing space right now that it's hard to keep up with the latest developments and sort out what's really important.  I'd already presented the previous day on the latest developments in Enterprise 2.0 including subjects like community management, top cultural challenges, a review of 70+ social software platforms, and patterns and best practices in general, but that took an entire day.  So I kept focused mainly on key points:

• About half of all companies have social tools now, but are just now grappling with how to use them.
• It's not only a new way to communicate and collaborate, but a fundamentally different one that can deeply change the way we work.
• That many issues surrounding social tool adoption break down into the issues of risk, control, and trust.
• There are a number increasingly well-understood reasons why Enterprise 2.0 will work better than older tools.  One of them, the Enterprise 2.0 communication continuum was particularly well tweeted during the conference.
• Often we have a failure of imagination when it comes to using social tools.  I cited the famous KatrinaList example of the power of emergent systems that naturally derive from social media to provide the solutions to critical human problems.  I made the point that we have many opportunities like this passing us by routinely in our enterprises but we don't have the mindset to take advantage of them.  We must transform our thinking, but this will take time.

You can view a video of the keynote itself captured via Qik as well, I start speaking about 5 minutes into it.  I also got to meet Leif Henrik Husom, who presented some fascinating new findings in an afternoon session from a major survey of social media adoption in Norway that was formally unveiled at the conference.  He generously offered to translate the slides on the fly into English before he got up to speak and I present them to you here for the first time.  The key data is on slide nine. In particular the datum that 6 out of 10 enterprises have decided to adopt social media in Norway, while only 1 out of 4 believe that management really supports it.  Lots more data for those that are interested below:

Improving the Practice of Software Architecture

My last session in Oslo was a 3 hour meeting with local enterprise architects that was sponsored by Bouvet.  Listening to many of the challenges and concerns I heard made me realize that that it's much the same around the world: Aligning IT with the business side is very hard and more and more time these days is spent on the technology treadmill keeping the business operating instead of focusing on new opportunities.  We are sometimes too reactive instead of proactive when it comes to software architecture, but now I'm beginning to think that is opportunity in disguise.

Related: My Top 10 List of Topics Software Architects Must Know About in 2009

I've been exploring in detail how to "fix" the challenges we have with enterprise architecture recently and writing up what I'm finding in terms of new possibilities. Many of the new approaches are ones we're seeing coming from the living laboratory of the Web, such as the move from traditional SOA to open Web APIs and their associated business models. You can find my thoughts both in Fixing Enterprise Architecture: Balancing the Forces of Change in the Modern Organization on ebizQ and Pragmatic new models for enterprise architecture take shape on ZDNet. I summarized this and much more in my presentation, which you can find below.  Overall it's starting to become clear that just as with social collaboration, enterprise architecture is about to be transformed by the significant business, cultural, technical, and societal changes at the edge of our networks.

All in all it was an informative and interesting trip and I'd like to especially thank Åsmund Mæhle from Bouvet and Renny Amundsen, CEO of EUCIP in Norway (European Certification of Informatics Professionals), for their excellent hosting. 

I'll continue to be traveling extensively across North America and Europe this fall to talk about these subjects. You can find a complete list of my upcoming presentations and talks, both online and offline on my updated speaking schedule. I'd also love to get feedback on these topics and hear about what your seeing in these areas.

The announcement this afternoon that URL shortener tr.im would stop service immediately and eventually get rid of all its data sparked widespread discussion in the blogosphere today, as evidenced by all the stories about it clustered on Techmeme.  URL shorteners provide a surprising amount of convenience to the average Internet user including links that don't break in e-mails, are friendly to microblogging services like Twitter, can be read easily over the phone, or sent via SMS.  And if a microblog service lets users create accounts, it even aggregates all the links that are shortened forming both an activity archive and social bookmarking service, though it increases long-term reliance on the service as well.

To see how embedded into the Web ecosystem that URL shorteners have already become, just read about the impact that tr.im's demise had to Robert Scoble, including the (eventual) loss of the majority of his historical tweets. For his part, Dan Frommers says that you just shouldn't rely on URL shorteners to preserve your data. But increasingly, that's just not an option.  As microblogging gets more and more important and widely used, and even starts moving into businesses with tools like Yammer and SocialText Signals, URL shorteners will be required to get the most out of these platforms.  This is true beyond microblogging as well: On the modern social Web, long URLs are just messy, inconvenient, and clutter up the conversation.  So increasingly, you'll have to find a way to pick a service that you can do business with and which will stick around.

For example, Frommer recommends using a URL shortener service that lets you take your data with you if you decide to leave (or if the service goes out of business.)  This is a smart recommendation, but one that is extremely hard to follow because incredibly, almost no service today provides this option, despite many years of talking about the need for data portability to head off these issues.

For example, one of the most popular, feature rich, and in my opinion best URL shorteners, Bit.ly, offers no data export option (at least that I can find after 15 minutes of looking).  The data can go into the app, but it can't get back out unless you arduously scrape it.  This is extremely poor Web application policy in mid-2009 where data portability has become a major issue.   This happens every time sites like tr.im that haven't figured out how to monetize or stay in business despite some popularity. I've been talking about an online software "Bill of Rights" for years now and it boils down to this: We as users of these services which are so integrated into our lives must stand up and demand that our online applications get rid of their "roach motel" data policies.

But the bigger issue surrounding cloud applications that 1) we don't pay for, 2) don't run on our infrastructure, and 3) which we have little control over as users, is that we need to sort out where our true priorities lie.  In general, this means voting with our pocketbooks, and paying in proportion for how valuable the service is to us.  This also means not using applications that lock us out of our own data by not letting us export it when we want to.

For my part, the tr.im story is a too-often repeated parable that we can't ignore.  In fact, because of this we are moving from Bit.ly -- which unlike services that I use like Flickr that allows me to pay, I can't support Bit.ly as a business to ensure they stick around --  to our own hosted URL shorteners.  This ensures I can have guaranteed access to the links we send out to our contacts and clients for as long as I want to pay for it.  In this way and others, short links will form a good part of the glue of the Web going forward.  We should not forget that the demise of a URL shortener actual does terrible damage to the fabric of the Web itself (which is eponymously a deep web of billions of links), especially if a URL shortener has poorly designed redirects.  Shortened links, particularly since they are used so close to the attention center of the Web, when they break ultimately interfere with many important services that do link analysis (such as search engines) from providing good results.

While in the long term most Web damage will sort itself out, the issue is that foundational service collapse can be far more impactful of us as users individually when it does happen (URL shorteners are "foundational services" since they insert themselves into foundation of the Web itself, it's deep link structure.).  To begin resolving all this, I humbly suggest that startups and their users alike ponder these points carefully:

A Cloud Services "Mutual Contract":

• Cloud applications will let users extract all of their data in open standard formats on demand.  This includes their explicit data as well as their data shadows (log files, user behavior tracks, search terms, etc.)
• Users of cloud application will be given the option for paying for higher quality service as well as offsite backups. Cloud applications can still monetize through advertising and give away free versions but this guarantees a financial footing as well as a higher level of control by customers, who have a greater stake when a services actual revenue comes from them.  Giving users an option to pay (and businesses certainly will if the service is important) is one of the best ways to ensure a service, particualrly popular ones that widely affect a large number of people doesn't have an unexpected demise. Backups should be accessible without an intermediary.
• Users should use the "for pay" version of the service whenever they use it signficantly as part of their lives or businesses.  Monetize the usage, not the content as Fred Wilson says. Unfortunately, free is the most popular business model on the Web and users just aren't used to paying, even if an application has become important.  But keeping very reasonable usage fees that can be billed yearly seems to be a successful model.
• Cloud applications should offer use 3rd party storage for users' data.  Trusted services such as S3 make good "backing stores" for a user's cloud application data.  That way, if a service goes out of business or permanently offline, the data is already in a safe place.  Technically, this poses few serious challenges for most applications and is actually a strong selling point for a new, untrusted service.

This list is very close to my original Online Software Bill of Rights in the link above except the pay-for-use option.  I added this because so many startups habitually avoid early monetization, hoping that lack of fees will help build a big "pop" and where they are then either acquired or attain enough page views to monetize for a few years.  I'm certainly not advocating a pay gate, but Web startups too often never become real businesses either.  Instead, I'm encouraging that cloud applications offer at least a freemium model as soon as they build a good, initial audience.  And keep all their users' data safe and portable.

For a full view of how to build modern Web apps read: 50 Strategies For Creating A Successful Web 2.0 Product

Lastly, services keep forgetting that data is the key to the Web 2.0 era and frequently fail spectacularly to exploit it in their businesses.  Network effects by default is what happens when services make use of user's data to create powerful new features and capabilities for other users with fair use of user contributions.  While just letting users store private data in your cloud application can result in a viable business, it won't set the world on fire.

Are URL shortners complicating the Web by inserting themselves as key intermediaries? Will this make the cloud too fragile in the long term?  Your comments below. 

It's been five years now that we've begun to understand what Web 2.0 is, starting way back in 2003.  It's been a fairly impressive if winding road as a new online generation was born.  But far from getting long in the tooth, along the way Web 2.0 became vitally important -- even central in some cases -- to the very future of global culture and business.  Oh certainly, sometimes we get tired of the term itself, and admittedly it doesn't describe something necessarily new anymore, but what we just do these days.  But the concepts identified as Web 2.0 have proved to be highly insightful, even prescient, and are used around the world daily to guide everything from product development to the future of government.

It has been today's commonplace use of intensely popular and deeply pervasive social networks, the outright transformation of industries such as media and software, and the growing dominance of 2.0 techniques such as user generated content, open business methods, crowdsourcing, Enterprise 2.0, open APIs -- in the business world and elsewhere -- which has been striking, even if there's a long way to go in some quarters.  Indeed, Web 2.0 is not just here to stay, it seems to be a revolution that just keeps on rolling and giving us, as I often say in my talks, an amazingly resourceful and resilient new lens with which to 1) look at the world and 2) the network that now surrounds it, and 3) the opportunities between the two.

Now, to paraphrase Churchill, "Now this is not the end. ... But it is, perhaps, the end of the beginning" of Web 2.0, many are starting to perceive deeper patterns and concepts within Web 2.0 practices.  We can perhaps now see more clearly the next steps towards what some would like to call Web 3.0, and which Tim O'Reilly and John Battelle have decided to dub Web Squared, the deeper explanation of which you can find here on the Web 2.0 Summit site.  Whether we need a new term and whether Web Squared will be as accepted, or at least as widely repeated, as Web 2.0 is perhaps unlikely but it nevertheless is a cogent, if necessarily, incomplete next progression.  What is certain is, that like Web 2.0, the ideas within it are useful new strategic ones that are emerging from the countless practical experiences of Internet practitioners everywhere in the world's largest living laboratory: The Internet. 

At its core, the message is that the Web is becoming more autonomic, reflective, real-time, generative, and open while at the same time far more deeply embedded everywhere in the fabric of our environment.  And like what came before it, Web Squared is likely to have profound impact to the societies and organizations, either way, that choose to understand it or ignore it.

What is Web Squared?

While this is my personal take, Web Squared articulates a broader fusion between the world-at-large, the Web, and the people connected to it.  It's a more extreme view of Web 2.0 while at the same time hinting that while social computing has been a major transformative force recently in the consumer world and beyond, the's relentless growth of devices, network connectivity, and sensors into our lives across our homes, workplaces, and external environment is casting an growing "information shadow" that is increasingly hard to ignore.  At first glance this can seem to be an impersonal and inhuman concept as the network expands to surround everything and dominate the participation that so far at least is still driven (for a little bit longer anyway) by what people do and contribute online.  However, this bleak vision is tempered by the realization that far from being pushed to the side, we collectively must be the feedback loop that guides Web Squared through billions of daily interactions that makes it possible in the first place.  It's the full environment, including us, which makes it all work. 

The comparison above gives a cleaner, most succinct sense of what Web Squared is by comparing it to Web 1.0 and classic Web 2.0.  It's not necessarily a generation beyond Web 2.0 since many of the concepts are simply more refined or focused.  But the "knobs" on many Web 2.0 ideas like collective intelligence, feedback loops, network effects, and so on are turned up quite a bit more and are fueled more directly by our interactions with the world as well as our synthesis of it.  We know now how to sharpen the scalpels that we use to design our online businesses a good bit better and Web Squared reflects this.

For my own part, it's a useful evolution of Web 2.0 even if it's not quite as dramatically transformative culturally.  However, the implications in terms of the types of new businesses that will be created have the potential to be as potent as Google (or even more so) when it comes to cornering the market on new classes of data and therefore entire industries, since most winners in on the online space have outsized dominance of their sectors.  You want to use Web 2.0 ideas for the most impact? Think in terms of Web Squared.

I'll be exploring the concepts of Web Squared in further depth here as I am able, but it's clear that we need to take what we've learned in the Web 2.0 era and focus on emerging techniques that seem particular promising.  In particular, I think the key aspect of Web Squared will lie in teaching our applications to "learn inferentially" from our online product's strategic sets of data and drive out previously hidden value.  That's where being able to create powerful new autonomic, environmentally-connected, database-driven applications, often from ecosystems of partners that will provide access to their data (for a price), has the potential to become a dominant new growth model for modern Web apps.  Whether this is video search engines built on top of YouTube's content, near real-time language translation using peer production in social communities, or just better product/content recommendation engines remains to be seen.

But the chances are just as likely that entirely new types of break-out products will be created that we can only barely imagine today, like we did with Web 2.0 just a few short years ago.  These new applications will fully harness the Web of data powered by insightful and potent cooperative algorithms and novel integration strategies that are deeply connected to the world we live in.  Developing these generative algorithms will be the central challenge for a new era of product designer.  These product designers will be experts at developing interactive systems for drawing insight, collecting data, and creating value from instantaneous Web input.  We can look to examples such as the Netflix Prize as successful models for distributed, open design "studios" for creating, validating, and identifying the winners.  How we look at fostering innovation and harvesting it is being reshaped by this vision already.

One thing is for certain, however, the way we look at the network is in the process of taking another big leap.

I'd like to get together a list of Web Squared example applications and ideas.  Please leave your suggestions and comments below.

It's been a long time in coming and it's a subject that has seen far too little serious treatment, either in traditional media or online.  And that is the overarching design of Web 2.0 applications.  This is a topic that as a practicing enterprise architect, along with many other hats, is near and dear to me and I've covered many times over the years here, on ZDNet, and my talks at conferences (see below for videos for some of these). 

So it's official, our new book Web 2.0 Architectures is now out from O'Reilly as of this month.  You can find it in your local bookstore or online.  Early feedback has been excellent including a stellar early review from JBoss CTO Mark Little.  Amazon UK nearly sold out almost immediately and we're making it standard issue for the architecture course at Web 2.0 University.

I should be clear from the outset that this book will be most useful for those coming at Web 2.0 from the traditional software and IT side of things.  While anyone trying to create modern Web 2.0 applications will certainly benefit from the thinking and perspectives in the book, it takes an approach that will be very familiar with those in classical software development and enterprise application architecture.  The book includes many key Web 2.0 architectures in design pattern form (in fact, the book was originally entitled Web 2.0 Design Patterns) using a service-based, layered view of software that will be eminently familiar with SOA architects and software engineers.

I'd like to thank my co-authors Duane Nickull and James Governer, who put up with my busy schedule without complaint, as well as the publisher O'Reilly and seemingly tireless editor Steve Weiss, who both stuck with us through many iterations.  Read Duane's announcement post of the book for additional background.

Building on top of the foundational material in the book, readers will also likely find these writings and video on Web 2.0 Architecture useful in their work, many of which were either inputs to the book or subsequently written and enrich what it has to offer. I've handpicked the ones that have been enormously popular over the years with hundreds of thousands of readers.

Essential Readings and Media on Web 2.0 Architectures

• Hacking the Web's Network Effect.  Every powerful technological approach can be used for both positive or negative results and the argument can be made that pure technology essentially amoral. In particular, network effects are especially potent ways of leveraging the value of networked applications and I explore how they can be used for good or ill.  The appreciation of network effects is something that most software architects are not familiar with still today.
• Is Web 2.0 The Global SOA? I began to see the marked similarities (and differences) between Web 2.0 and SOA and began to explore this in some detail. This received wide coverage in the blogosphere and eventually evolved to become my regular blog on ZDNet and a cover story in the SOA/Web Services Journal.
• Tolerance And Experience Continuums. As the first major Web 2.0 applications began to flourish the idea that small pieces, loosely joined would result in better products and innovation in assembly began to be borne out, particularly with mashups and open APIs.  In this piece I take a look at how our heavyweight, complex, and monolithic software design in the traditional world was a solution that was often on the wrong site of the tolerance curve.
• A Timeless Way of Building Software.  I take a look at how the development of major software systems, particularly networked ones, have had the same essential design concerns, it's just a matter of emphasis.  This material made it into the book with an homage to Christopher Alexander's work on patterns.  I lay out the major design concerns of all software and show where SOA and things like Web 2.0 fall on the map.  
• Open Services That Last And Anyone Can Use.  The early offers of open APIs and lightweight public SOA, which have been instrumental in helping many of the newer Web startups such as Twitter be particulary successful, had an uncertain landscape in which to provide their services, not knowing the best way to expose them.  That's much clearer now but I took a look at the full range of options.
• Web 2.0 and SOA: Contrived or Converging.   I delve deeper into the apparent entanglements between Web 2.0 and service-oriented architecture, a subject that became increasingly apparent was a major topic.  This culminated into many vital architectural discussions at every level of the subject, from the bottom, with Web-Oriented Architecture to top with the emerging social layer. 
  
• Web-Oriented Architecture (WOA).  This become a more important topic as RESTful architectures began to become more popular and more interesting to the software development community in general. This is my most definitional work, but there were many others including my discussions of WOA and traditional SOA as well as my original research on creating effective REST clients which was published in the Microsoft Architecture Journal.
• The Co-Evolution of SOA and Web 2.0 and The story of Web 2.0 and SOA continues.  I do my most complete definition in detail of the concrete tie-ins between the models of Web 2.0 and SOA, which have more in common than they do differences.  SOA is essentially the most common approach to building traditional software systems today while Web 2.0 is the leading approach online, the differences are really in emphasis, barring a few true differences.
• Deconstructing Web 2.0 to the Next Level. Exploring Web 2.0 by describing it with patterns began when I first met Duane Nickull and made the video included in this post the day we became acquainted.  This eventually led to the collaboration that resulted in this book (which was originally called Web 2.0 Design Patterns.)  Be sure to watch the video, it has a good complete discussion of the topic of Web 2.0, patterns, and traditional software development.
• Architectures of Participation: The Next Big Thing.  This is largely missing as a formal software development discipline and traditional software lacks for this element.  I explore how in the future the best software well have well tuned Architectures of Participation.
• Next-Generation Web 2.0 Applications. Over the last few years Web 2.0 applications have become more and more sophisticated, but even understanding what a "Web 2.0 Stack" is has been poorly defined.  I unbox it in a layered description including social, distribution, and 3rd party sourcing as explicit tiers in and of themselves.
• Distribution Models for Modern Web Applications. Being successful on a large, crowded network requires using all the models for reach that are available, from syndication to Web services (open APIs), widgets, and more.  I explore how modern Web applications have evolved highly sophisticated new ways to reach their users, whether they are partners or customers.
• Cloud Computing And The Return Of the Platform Wars.  We're seeing the emergence of another new architectural model from the Web and it's poses challenges for traditional software models again.  Here are some of the opportunities and issues especially as platform lock-in and standards are going to be a major issue.
• Transforming Software Architecture with Web as Platform.  I gave a keynote at QCon in London earlier this year and I covered many of the major transformations taking place in architecture today and how it's being driven by the Web including open platforms, productivity-oriented frameworks such as Rails and Grails, non-relational databases, as well as cloud computing and more. Video and slides are included.  You can also read my Top 10 Must-Know Topics for Software Architects in 2009 for additional details.
• There Goes Everyone: Web 2.0 Expo Europe Keynote.  This is good for understanding the challenges we have before us as architects and business people.  While not technical, it's a good overview of the urgency we have in changing from older ways of doing things, which aren't working very well, to new models for using the network for better outcomes in our software, business, culture, and society:
   

I am fortunate enough to spend a lot of time looking at various online products and services in the development stage, mostly of the Web 2.0 variety, meaning they use one or more of the principles in the Web 2.0 set of practices.  It's been going on 4 years now and what's fascinating to me, despite the enormous amount of knowledge that we've accumulated on how to create modern Web applications, is how many of the same lessons are learned over and over again.

Wouldn't it be handy if we had a cheat sheet that combined many of these lessons into one convenient list?  In this vein of thinking, I decided to sit down recently to capture are some of the most important lessons I've learned over the last few years along with some of the thinking that went into them.

The Web Community Gets Smarter Every Time It Builds A Product

If there's one thing that the Web has taught us it's that the network gets smarter by virtue of people using it and product development is no exception.  Not only do we have examples of great online applications and systems to point to and use for best practices, but the latest tools, frameworks, development platforms, APIs, widgets, and so on, which are largely developed today in the form of open source over the Internet, tend to accumulate many of these new best practices. I've lauded everything from frameworks like Rails, Cake PHP, and Grails to online community platforms like Drupal and Joomla as examples of guiding solutions that can be vital springboards for the next great Web product or service.  

However, most of the success of an online product, Web 2.0 or otherwise, comes from two things: Its software architecture and its product design.  It's also the case that the story of any product is a story of ten of thousands of little decisions made throughout the life of the product, of which only a key -- and heartbreakingly small -- set will make much of a difference to its success on the network.  The list of strategies below tells part of the story of which decisions will make that critical difference.

What then is software architecture and product design when it comes to today's Web applications?  The good news: They're often the same as they've always been, albeit just a bit more extreme, though there are some additions for the 2.0 era as well: 

Doing both of these top-level product development activities well, striking a healthy balance between them (one often dominates the other), and doing it with a small team, requires people with deep and multidisciplinary backgrounds in creating successful products across this extensive set of practice areas.  These people are often hard to find and extremely valuable.  This means it's also not likely you'll be able to easily put together a team with all the capabilities that are needed from the outset. 

Be prepared from the outset for on-the-job learning and study, relying on tools and products that embody best practices, and replicating only the best designs and ideas (while being very conscientious not to steal IP.)

In this way, I've collected a set of strategies that address the most common issues that I see come up over and over again as online products go to market.  I've decided to share these with you so we can continue to teach the network, and consequently ourselves, a little bit more about how to make extraordinary Web applications that can really make a difference in the marketplace.

This of course is just my experience and is not intended to be a complete list of Web 2.0 strategies.  However, I think most people will find it a valuable perspective and useful cross check in their product design and development. And please keep in mind this list is for Web 2.0 applications, not necessary static Web sites, or traditional online Web presence, though there is much that here that can be applied to them to make them more useful and successful as well.

Finally, a good number of these strategies are not specifically Web 2.0 concepts.  They are on the list because they are pre-requisites to many Web 2.0 approaches and to any successful product created with software and powered by people.

Please add your own strategies in comments below for anything that I've missed.

1. Start with a simple problem.  All of the most successful online services start with a simple premise and execute on it well with great focus.  This could be Google with it's command-line search engine, Flickr with photo sharing, Digg with user generated news.  State your problem simply: "I make it easier to do X".  Focus on solving it elegantly and simply, only add features carefully.  Over time, complexity will become the enemy of both your product design and your software architecture, so start with as much focus as you can muster.

2. Create prototypes as early as possible.  Get your idea into a working piece of software as quickly as possible.  The longer you take to go through one entire cycle, the more unknown work you have ahead of you.  Not producing software also means that you are not getting better and better at turning the work of your team into the most important measurable output: Functioning software.  Throughout the life of your product, turning your ideas into software as quickly and inexpensively as possible will be one of the most important activities to get right.

3. Get people on the network to work with the product prototype rapidly and often.  The online world today is fundamentally people-centric.  If your product isn't about them and how it makes their lives better, your product really doesn't matter.  And if they're not using your Web application as soon as possible, you just don't know if you are building the right product.  Constant, direct feedback from real people is the most important input to our product design after your idea.  Don't wait months for this to happen; get a beta out to the world, achieve marketplace contact in weeks, or at most a few months, and watch carefully what happens. This approach is sometimes called Web 2.0 Development .

4. Release early and release often.  Don't get caught up in the massive release cycle approach, no matter how appealing it may be.  Large releases let you push off work tomorrow that should be done today.  It also creates too much change at once and often has too many dependencies, further driving an increase in the size of the release.  Small releases almost always work better, are easier to manage, but can require a bit more operations overhead. Done right, your online product will iterate smoothly as well as improve faster and more regularly than your competitors. Some online products, notably Flickr, have been on record as saying they make new releases to production up to several times a day.  This is a development velocity that many new startups have trouble appreciating or don't know how to enable. Agile software development processes are a good model to start with and and these and even more extreme methods have worked well in the Web 2.0 community for years.

5. Manage your software development and operations to real numbers that matter.  One often unappreciated issue with software is its fundamentally intangible nature.  Combine that with human nature, which is to manage to what you can see, and you can have a real problem.  There is a reason why software development has such a variable nature in terms of time, budget, and resources.  Make sure you have as many real numbers as possible to manage to: Who is making how many commits a week to the source repository, how many registered users are there on a daily basis, what does the user analytics look like, which product features are being used most/least this month, what are the top 5 complaints of customers, and so on.  All of these are important key performance indicators that far too many startups don't manage and respond to as closely as they should.

6. Gather usage data from your users and input it back into product design as often as possible.  Watch what your users do live with your product, what they click on, what do they try to do with it, what they don't use, and so on.  You will be surprised; they will do things you never expected, have trouble with features that seem easy to you, and not understand parts of your product that seemed obvious.  Gather this data often and feed it back into your usability and information architecture processes.  Some Web applications teams do this almost daily, others look at click stream analytics once a quarter, and some don't it at all.  Guess who is  shaping their product faster and in the right direction?

7. Put off irreversible architecture and product design decisions as long as possible. Get in the habit of asking "How difficult will it be to change our mind about this later?" Choosing a programming language, Web framework, relational database design, or a software interface tend to be one-way decisions that are hard to undo.  Picking a visual design, logo, layout, or analytics tool generally is not.  Consequently, while certain major decisions must be made up front, be vigilant for seemingly innocuous decisions that will be difficult to reverse.  Not all of these will be a big deal, but it's all too often a surprise to many people when they discover their architecture isn't malleable in the places that they want it to be.  Reduce unpleasant surprises by always asking this question.

8. Choose the technologies later and think carefully about what your product will do first.  First, make sure your ideas will work on the Web. I've seen too many startups with ideas that will work in software but not on the Web.  Second, Web technologies often have surprising limits, Ajax can't do video or audio, Flash is hard to get to work with SEO for example.  Choosing a technology too early will constrain what is possible later on.  That being said, you have to choose as rapidly as you can within this constraint since you need to build prototypes and the initial product as soon as you are able.

9.  When you do select technologies, consider current skill sets and staff availability.  New, trendy technologies can have major benefits including higher levels of productivity and compelling new capabilities, but it also means it'll be harder to find people who are competent with them.  Having staff learn new technology on the job can be painful, expensive, and risky.  Older technologies are in a similar boat; you can find people that know them but they'll most likely not want to work with them.  This means the middle of the road is often the best place to be when it comes to selecting technology, though you all-too-often won't have a choice depending on what your staff already knows or because of the pre-requisites of specific technologies that you have to use.

10. Balance programmer productivity with operational costs.  Programming time is the most expensive part of product creation up front while operations is after you launch.  Productivity-oriented platforms such as Ruby on Rails are very popular in the Web community to drive down the cost of product development but can have significant run-time penalties later when you are supporting millions of users.  I've previously discussed the issues and motivations around moving to newer programming languages and platforms designed for the modern Web, and I encourage you to read it. Productivity-oriented platforms tend to require more operational resources during run-time, and unlike traditional software products, the majority of the cost of operations falls upon the startup.  Be aware of the cost and scale of the trade-offs since every dollar you save on the development productivity side translates into a run-time cost forever after on the operations side.

11. Variability in the productivity amongst programmers and development platforms each varies by an order of magnitude.  Combined together and your choice of programming talent and software development platforms can result in a 100x overall effect on product development productivity.  This means that some teams can ship product in as little as 3 months and some projects won't ship ever, at least not without truly prohibitive time and resource requirements.  While there are a great many inputs to an Internet startup that will help or hinder it (take a look at Paul Graham's great 18 Mistakes That Kill Startups for a good list), these are two of the most central and variable: Who is developing the product and what development platform they are using. Joel Spolsky's write-up on programmer productivity remains one of the best at understanding this issue.  It usually turns out that paying a bit more for the right developer can often mean tremendous output gains.  One the other side of the coin, choosing a development platform not designed for creating modern Web applications is another decision that can sap your team of productivity while they spend months retrofitting it for the features they'll need to make it work properly in today's Internet world. 

12. Plan for testing to be a larger part of software development process than non-Web applications.  Cross browser testing, usability, and performance/load testing are much bigger issues with Web applications than many non-Web applications.  Having to do thorough testing in a half-dozen to a dozen browser types can be an unexpected tax on the time and cost of creating a Web product.  Doing adequate load testing is another item that often waits until the end, the very worst time to find where the bottlenecks in your architecture are.  Plan to test more than usual.  Insist on automated unit and integration tests that build up over time and run without having to pay developers or testers to do it manually.

13. Move beyond traditional application hosting. Single Web-server hosting models are not going to suffice for your 2.0 applications.  Reliability, availability, and scalability are essential and must be designed into your run-time architecture and supported by your hosting environment.  Solutions like 3Tera, Amazon's Elastic Compute Cloud, and Google's App Engine are three compelling, yet very different solutions to the hosting problem.  Either way, grid and cloud approaches to hosting will help you meet your growth and scalability requirements while managing your costs.

14. Have an open source strategy.  This has two important aspects.  One, developing and hosting a product built with open source software (the ubiquitious LAMP stack) is almost always much less expensive than using commercial software and is what most online products use.  There are certainly commercial licenses that have fair terms for online services, but almost none of them will match the cost of free.  This is one reason why you won't find Windows or Oracle embedded in very many Web 2.0 services.  Two, you'll have to decide whether to open source or commercial open source your product.  This has entirely to do with what your product does and how it does it, but an increasing number of Web 2.0 hosted products are releasing their offerings as open source to appeal to customers, particularly if they are business customers. Done right, open sourcing can negate arguments about the size of your company while enlisting many 3rd party developers to help enrich and make your product better.

15. Consider mobile users as important as your regular browser customers.  Mobile devices will ultimately form the majority of your user base as the capability and adoption of smartphones, Internet tablets, laptops, and netbooks ushers in mobile Web use as the dominant model.  Having an application strategy as well as well-supported applications for the iPhone, Android, and RIM platforms is essential for most Web products these days.  By the time you get to market, mobile will be even more important than it is now.  Infoworld confirmed today, in fact, that wireless enterprise development will be one of 2009's bright spots.

16. Search is the new navigation, make it easy to use in your application.  You have 5-10 seconds for a new user to find what they want from your site or application.  Existing users want to directly access what they need without going through layers of menu items and links.  Search is the fastest way to provide random access navigation.  Therefore, offer search across data, community, and help at a minimum.  A search box must be on the main page and indeed, every page of the modern Web application. 

17. Whenever users can provide data to your product, enable them.  Harnessing collective intelligence is the most central high-level principle of Web 2.0 applications.  To be a major online competitor, getting your millions of users to build a valuable data set around the clock is the key to success. Many product designers look at this too narrowly and usually at a small set of data.  Keep a broad view of this and look for innovative ways to get information from explicit contributions to the database of intentions can form your architecture of participation.

18. Offer an open API so that your Web application can be extended by partners around the world.  I've covered this topic many times in the past and if you do it right, your biggest customers will soon become 3rd party Web applications building upon your data and functionality.  Critically, offering an API converts your online product into an open platform with an ecosystem of 3rd party partners.  This is just one of many ways to realize Jakob's law, as is the next item.

19. Make sure your product can be spread around the Web by users, provide widgets, badges, and gadgets.  If your application has any success at all, your users will want to take it with them and use your features elsewhere.  This is often low-effort but can drive enormous growth and adoption; think about YouTube's badge. 

20. Create features to make the product distribute virally.  The potency of this is similar to widgets above and everything from simple e-mail friend invites to importing contact lists and social graphs from other Web apps are critical ways to ensure that a user can bring the people they want into the application to drive more value for them and you.   

21. The link is the fundamental unit of thought on the Web, therefore richly link-enable your applications.  Links are what make the Web so special and fundamentally makes it work.  Ensuring your application is URL addressable in a granular way, especially if you have a rich user experience, is vital to participate successfully on the Web.  The Web's link ecosystem is enormously powerful and is needed for bookmarking, link sharing/propagation, advertising, makes SEO work, drives your page rank, and much more.  Your overall URL structure should be thought out and clean, look to Flickr and del.cio.us for good examples.

22. Create an online user community for your product and nurture it.  Online communities are ways to engage passionate users to provide feedback, support, promotion, evangelism and countless other useful outcomes.  While this is usually standard fare now with online products, too many companies don't start this early enough or give it enough resources despite the benefits it confers in terms of customer support, user feedback, and free marketing, to name just three benefits.  Investing in online community approaches is ultimately one of the least expensive aspects of your product, no matter the upfront cost. Hire a good community manager and set them to work.

23. Offer a up-to-date, clean, compelling application design.  Attractive applications inherently attract new customers to try them and is a pre-requisite to good usability and user experience.  Visual and navigational unattractiveness and complexity is also the enemy of product adoption.  Finally, using the latest designs and modes provides visual cues that conveys that the product is timely and informed.  A good place to start to make sure you're using the latest user experience ideas and trends is Smashing Magazine's 2009 Web Design survey.

24. Load-time and responsiveness matter, measure and optimize for them on a regular basis.  This is not a glamorous aspect of Web applications but it's a fundamental that is impossible to ignore.  Every second longer a key operation like main page load or a major feature interaction takes, the more likely a customer is to consider finding a faster product.  On the Web, time is literally money and building high speed user experiences is essential.  Rich Internet Application technologies such as Ajax and Flash, albeit used wisely, can help make an application seem as fast as the most responsive desktop application. Using content distribution networks and regional hosting centers.

25. User experience should follow a "complexity gradient."  Novice users will require a simple interface but will want an application's capabilities to become more sophisticated over time as they become more skilled in using it.  Offering more advanced features that are available when a user is ready but are hidden until they are allows a product to grow with the user and keeps them engaged instead of looking for a more advanced alternative. 

26. Monetize every page view.  There is no excuse for not making sure every page is driving bottom-line results for your online business.  Some people will disagree with this recommendation and advertising can often seem overly commercial early in a product's life.  However, though a Web application should never look like a billboard, simple approaches like one line sponsorships or even public service messages are good ideas to maximize the business value of the product and there are other innovation approaches as well.

27. Users' data belongs to them, not you.  This is a very hard strategy for some to accept and you might be able to get away with bending this rule for a while, that is, until some of your users want to move their data elsewhere.  Data can be a short-term lock-in strategy, but long-term user loyalty comes from treating them fairly and avoiding a 'Roach Motel' approach to user data ("they can check-in their data, but they can't check out.") Using your application should be a reversible process and users should have control of their data.  See DataPortability.org for examples of how to get started with this.

28. Go to the user, don't only make them come to you.  The aforementioned APIs and widgets help with this but are not sufficient.  The drive strong user adoption, you have to be everywhere else on the Web that you can be.  This can mean everything from the usual advertising, PR, and press outreach but it also means creating Facebook applications, OpenSocial gadgets, and enabling use from mashups. These methods can often be more powerful than all the traditional ways combined.

29. SEO is as important as ever, so design for it.  One of the most important stream of new users will be people coming in from search engines looking for exactly what you have.  This stream is free and quite large if you are ensuring your data is URL addressable and can be found via search engine Web crawlers.  Your information architecture should be deeply SEO-friendly and highly granular.

30. Know thy popular Web standards and use them.  From a consumer or creator standpoint, the data you will exchange with everyone else will be in some format or another.  And the usefulness of that data or protocol will be in inverse proportion to how well-known and accepted the standard is.  This generally means using CSS, Javascript, XHTML, HTTP, ATOM, RSS, XML, JSON, and so on. Following open standards enables the maximum amount of choice, flexibility, time-to-market, access to talent pools, and many other benefits over time to both you and your customers.

31. Understand and apply Web-Oriented Architecture (WOA). The Web has a certain way that it works best and understanding how HTTP works at a deep level is vital for getting the most out of the unique power that the Internet has to offer.  But HTTP is just the beginning of this way of thinking about the Web and how to use its intrinsic power to be successful with with it.  This includes knowing why and how link structure, network effects, SEO, API ecosystems, mashups, and other aspects of the Web are key to making your application flourish.  It's important to note that your internal application architecture is likely not fundamentally Web-oriented itself (because most software development platforms are not Web-oriented) and you'll have to be diligent in enabling a WOA model in your Web-facing product design.  The bottom line: Non-Web-oriented products tend not to fare very well by failing to take advantage of the very things that have made the Web itself so successful.

32. Online products that build upon enterprise systems should use open SOA principles. Large companies building their first 2.0 products will often use existing IT systems and infrastructure that already have the data and functionality they need.  Although they will often decouple and cache them for scalability and performance, the connectedness itself is best done using the principles of SOA. That doesn't necessarily mean traditional SOA products and standards, although it could, often using more Web-oriented methods works better.  What does this really mean? Stay away from proprietary integration methods and use the most open models you can find, understanding that the back-end of most online products will be consumed by more than just your front-end (see API discussion above for a fuller exploration).

33. Strategically use feeds and syndication to enable deep content distribution.  This is another way to use Jakob's Law to increase unintended uses and consumption of an application from other sites and ecosystems.  Feeds enable many beneficial use cases such as near real-time perception of fresh data in your application from across the Web in feed readers, syndication sites, aggregators, and elsewhere.  Like many other techniques here, knee-jerk use of feeds won't drive much additional usage and adoption, but carefully designing feeds to achieve objectives like driving new customers back to the application directly from the feed can make a big difference.  Failing to offer useful feeds is one of the easiest ways to miss out on business opportunities while giving your competitors an edge.

34. Build on the shoulders of giants; don't recreate what you can source from elsewhere.  Today's Internet application usually require too much functionality to be cost-effectively built by a single effort.  Typically, an application will actually source dozens of components and external functionality from 3rd parties.  This could be off-the-shelf libraries or it could be the live use of another site's API, the latter which has become one of the most interesting new business models in the Web 2.0 era.  The general rule of thumb: Unless it's a strategic capability of your application, try hard to source it from elsewhere before you build it; 3rd parties sources are already more hardened, robust, less expensive, and lower defect than any initial code could that you could produce. Get used to doing a rapid build vs. buy evaluation for each major component of your application.

35. Register the user as soon as possible.  One of the most valuable aspects of your onine product will be the registered user base.  Make sure you application gives them a good reason to register and that the process is as painless as possible.  Each additional step or input field will increase abandonment of the process and you can always ask for more information later. Consider making OpenID the default login, with your local user database a 2nd tier, to make the process even easier and more comfortable for the user.

36. Explicitly enable your users to co-develop the product.  I call this concept Product Development 2.0 and it's one of the most potent ways to create a market-leading product by engaging the full capabilities of the network.  The richest source of creative input you will have is your audience of passionate, engaged users.  This can be enabled via simple feedback forms, harvested from surveys and online community forums, via services such as GetSatisfaction, or as the ingredients to mashups and user generated software. As you'll see below, you can even open the code base or provide a plug-in approach/open APIs to allow motivated users and 3rd parties to contribute working functionality.  Whichever of these you do, you'll find that the innovation and direction to be key to making your product the richest and most robust it can be.  A significant percentage of the top online products in the world take advantage of this key 2.0 technique.

37. Provide the legal and collaborative foundations for others to build on your data and platform.  A good place to start is to license as much of your product as you can via Creative Commons or another licensing model that is less restrictive and more open than copyright or patents. Unfortunately, this is something for which 20th century business models around law, legal precedent, and traditional product design are ill-equipped to support and you'll have to look at what other market leaders are doing with IP licensing that is working.  Giving others explicit permission up-front to repurpose and reuse your data and functionality in theirs can be essential to drive market share and success. Another good method is to let your users license their data as well and Flickr is famous for doing this.  It's important to understand that this is now the Some Right Reserved era, not the All Rights Reserved era.  So openly license what your have for others to use; the general rule of thumb is that the more you give away, the more you'll get back, as long as you have a means of exercising control.  This is why open APIs have become as popular as they have, since they are essentially "IP-as-a-service" and poorly behaving partner/licensees can be dealt with quickly and easily.

38. Design your product to build a strong network effect.  The concept of the network effect is something I've covered here extensively before and it's one of the most important items in this list.  At their most basic, Web 2.0 applications are successful because they explicitly leverage network effects successfully. This is the underlying reason why most of the leading Internet companies got so big, so fast.  Measuring network effects and driving them remains one of the most poorly understood yet critical aspects of competing successfully online.  The short version: It's extremely hard to fight an established network effect (particularly because research has shown them to be highly exponential).  Instead, find a class of data or a blue ocean market segment for your product and its data to serve.

39. Know your Web 2.0 design patterns and business models.  The fundamental principles of Web 2.0 were all identifid and collected together for a good reason.  Each principle is something that must be considered carefully in the design of your product given how they can magnify your network effect. Your development team must understand them and know why they're important, especially what outcomes they will drive in your product and business.  It's the same with Enterprise 2.0 products: There is another, related set of design principles (which I've summarized as FLATNESSES) that makes them successful as well.  And as with everything on this list, you don't apply 2.0 principles reflexively; they need to be intelligently used for good reason.

40. Integrate a coherent social experience into your product.  Social systems tend to have a much more pronounced network effect (Reed's Law) than non-social systems. Though no site should be social without a good reason, it turns out that most applications will benefit from having a social experience.  What does this mean in practice? In general, social applications let users perceive what other users are doing and actively encourage them to interact, work together, and drive participation through social encouragement and competition.  There is a lot of art to the design of the social architecture of an online product, but there is also an increasing amount of science.  Again, you can look at what successful sites are doing with their social interaction but good places to start are with user profiles, friends lists, activity streams, status messages, social media such as blogs and microsharing, and it goes up from there.  Understand how Facebook Connect and other open social network efforts such as OpenSocial can help you expand your social experience.

41. Understand your business model and use it to drive your product design.  Too many Web 2.0 applications hope that they will create large amounts of traffic and will then find someone interested in acquiring them.  Alternatively, some products charge too much up front and prevent themselves from reaching critical mass. While over-thinking your exit strategy or trying to determine your ultimate business model before you do anything isn't good either, too many startups don't sit down and do the rigorous thinking around how to make their business a successful one in the nearer term.  Take a look at Andrew Chen's How To Create a Profitable Freemium Startup for a good example of the framework on how to do some of the business model planning.  Taking into account the current economic downturn and making sure you're addressing how you offering can help people and businesses in the current business climate will also help right now.

42. Embrace emergent development methods.  While a great many of the Web's best products had a strong product designer with a clear vision that truly understood his or her industry, the other half of the equation that often gets short shrift is the quality of emergent design through open development.  This captures the innate crowdsourcing aspects of ecosystem-based products, specifically those that have well-defined points of connectedness with external development inputs and 3rd party additions.   Any Web application has some emergent development if it takes development inputs or extensibility with via 3rd party plug-ins, widgets, open APIs, open source contributions, and so on.  The development (and a good bit of the design) of the product then "emerges" as a function of multiple inputs.  Though there is still some top-down control, in essence, the product becomes more than the sum total of its raw inputs.  Products like Drupal and Facebook are good examples of this, with thousands of plug-ins or 3rd party apps that have been added to them by other developers.

43. It's all about usability, usability, and usability.  I've mentioned usability before in this list but I want to make it a first class citizen.  Nothing will be a more imposing barrier to adoption that people not understanding how your product works.  Almost nothing on this list will work until the usability of your application is a given.  And hands down the most common mistake I see are Web developers creating user experiences in isolation.  If you're not funded to have a usability lab (and you probably should be, at some level), then you need to grab every friend and family member you have to watch how they use your application for the first time.  Do this again for every release that makes user experience changes.  You will change a surprising number of assumptions and hear feedback that you desperately need to hear before you invest any more in a new user experience approach.  This now true even if you're developing enterprise applications for the Web.

44. Security isn't an afterthought.  It's a sad fact that far too much of a successful startup's time will be spent on security issues.  Once you are popular, you will be the target of every so-called script kiddie with a grudge or with the desire to get at your customer data, etc. Software vulnerability are numerous and the surface area of modern Web apps large. You not only have your own user experience but also your API, widgets, semantic Web connections, social networking applications, and other points of attack.  Put aside time and budget for regular vulnerability assessments.  You can't afford a public data spill or exploit due to a security hole that will compromise your user's data, or you may well find yourself with a lot of departing customers.Web 2.0 applications also need unique types of security systems, from rate limiters to prevent valuable user-generated data from being systematically scraped from the site (this is vital to "maintaining control of unique and hard-to-re-create datasets") to monitoring software that will screen for objectionable or copyrighted contributions.

45. Stress test regularly and before releases.  It's a well known saying in the scalability business that your next bottleneck is hiding just behind your last high water mark. Before your launch, data volumes and loads that work fine in the lab should be tested to expected production volumes before launch.  The Web 2.0 industry is rife with examples of companies that went down the first time they got a good traffic spike.  That's the very worst time to fail, since it's your best chance of getting a strong initial network effect and may forever reduce your ultimate success.  Know your volume limits and ceilings with each release and prepare for the worst.

46. Backup and disaster recovery, know your plan.  This is another unglamorous but essential aspect for any online product.  How often are backups being made of all your data? Are the backups tested? Are they kept offsite? If you don't know the answers, the chances that you'll survive a major event is not high.

47. Good Web products understand that there is more than the Web.  Do you have a desktop widget for Vista or the Mac? Might you benefit from offering an Adobe AIR client version of your application? How about integration and representation in vitual worlds and games?  How about linkages to RFID or GPS sensors? Startups thinking outside the box might even create their own hardware device if it makes sense (see Chumby and the iPhone/iPod for examples).  If one thing that is certain is that the next generation of successful Web startups will only partially resemble what we see today.  Successful new online products will take advantage of "software above the level of a single device" and deliver compelling combinations of elements into entirely new products that are as useful and innovative as they are unexpected.  A great Web 2.0 product often has a traditional Web application as only part of its overall design, see the Doritos Crash the Superbowl campaign for just one small example of this.

48. Look for emerging areas on the edge of the Web.  These are the spaces that have plenty of room for new players and new ideas, where network effects aren't overly established and marketshare is for the taking. What spaces are these? The Semantic Web seems to be coming back with all new approaches (I continue to be amazed at how much appears about this topic on http://delicious.com/popular/web3.0 these days.) Open platform virtual worlds such as Second Life were hot a few years ago and may be again.  Mobile Web applications are extremely hot today but slated to get over crowded this year as everyone plans a mobile application for phone platforms.  What is coming after this?  That is less clear but those that are watching closely will benefit the most.

49.  Plan to evolve over time, for a long time.  The Web never sits still.  Users change, competitors improve, what's possible continues to expand as new capabilities emerge in the software and hardware landscape.  In the Perpetual Beta era, products are never really done.  Never forget that, continue to push yourself, or be relegated to a niche in history.

50. Continually improve yourself and your Web 2.0 strategies. While process improvement is one of those lip-service topics that most people will at least admit to aspire to, few have the time and resources to carry it out on a regular basis.  But without that introspection on our previous experience we wouldn't have many of the "aha" moments that drove forward our industry at various points in term.  Without explicit attempts at improvement, we might not have developed the ideas that became object-oriented languages, search engine marketing, Web 2.0, or even the Internet itself.  This list itself is about that very process and encapsulates a lot of what we've learned in the last 4 years.  Consequently, if you're not sitting down and making your own list from your own experiences, you're much more likely to repeat past history, never mind raising the bar.  Like I'm often fond of saving; civilization progresses when we make something that was formerly hard to do and make it easy to do.  Take the time, capture your lessons learned, and improve your strategies.

What else is missing here? Please contribute your own 2.0 strategies in comments below:

You can also get help with these strategies from a Web 2.0 assessment, get a deeper perspective on these ideas at Web 2.0 University, or attend our upcoming Economics 2.0 workshop at Web 2.0 Expo SF on March 31st, 2009.