Click on the image for the original description and full pdf

I’m delighted that the framework is still seen as relevant and useful over 3 years after it was created in May 2007. Certainly the original post continues to get plenty of traffic, not least because an image from the framework still appears on the front page of a Google search for ‘Web 2.0’. The phrase ‘Web 2.0’ has been largely replaced with ‘social media’, 'cloud' and similar terms, but the underlying concepts remain valid in understanding what is going on today.

I thought it would be worth reviewing the framework today to see what is still current and what I would change.

Overall, my thinking on the space has evolved a fair bit over the last years, and I would certainly create a fairly different framework if I started again from scratch. Then again, I find it hard to identify anything that I think is no longer true – the framework still seems to provide a solid frame to understand what is going on in the social web.

Web 2.0 mechanisms
The heart of the diagram is how Inputs flow through Web 2.0 Mechanisms to Emergent Outcomes. To me, this has always been the heart of the emerging social web. My definition of Web 2.0 offered in the framework, which I still stand by, is:

“Distributed technologies built to integrate, that collectively transform mass participation into valuable emergent outcomes.”

The essence is the creation of something new and worthwhile from participation by many. This is something that is often missed by those who treat ‘social media’ as a new kind of broadcast mechanism. What remains most interesting about the web today is how users’ activities are aggregated to create something that did not exist before. Collaborative filtering, which preceded Web 2.0, is a key aspect, but it also goes beyond this.

Web as global brain
As I’ve written several times recently, the concept of the global brain seems to be on the rise again. Indeed, Tim O’Reilly’s original definition of Web 2.0 referring to “harnessing collective intelligence” is absolutely valid.

Web 2.0 and Enterprise 2.0
The framework suggests the same principles apply in the open web and the enterprise. That is absolutely true. In Chapter 2 of my book Implementing Enterprise 2.0, written last year, I explained how the Web 2.0 framework applies to the enterprise and the five issues in adapting Web 2.0 to organizations.

Web 2.0 Landscape
The landscape of Web 2.0 companies provided key dimensions for distinguishing different aspects of Web 2.0. One key dimension was distinguishing between Content Sharing and Recommendations/ Filtering, another was between Web Applications and Social Networks. Each pair of these combined to yield another space, to yield 8 dimensions.

Click on the image for the original description and full pdf

Again, I would slice this differently today, but the dimensions remain valid, and in particular the dimension and quadrants each make sense, though some could be renamed.

I briefly considered redoing this landscape with the current crop of web companies, but it would take too much work – it can be an exercise for people to work out for themselves where a company should sit on the landscape.

I find it interesting that back then I placed Twitter as a combination of social network and content sharing. While that is today a great way of describing Twitter, early on few seemed to understand that the core of Twitter’s value is in sharing content.

The aggregation space has receded in importance as RSS has become less prominent, though collaborative filtering is still a core business model. The web applications space has developed into the burgeoning software-as-a-service market. What I describe as widgets/ components is now in many ways a far larger space, which supports cloud computing in its truest sense.

I’d love any thoughts or comments on how the Web 2.0 Framework is (or isn’t) relevant today – where is it still valid and how might it be changed to make it fully current?

One of the most critical elements of this principle is the ability to establish and run effective pilot programs.

Below is an excerpt from Chapter 17 of Implementing Enterprise 2.0 on Pilots, which describes 8 guiding principles for pilot programs.

GUIDING PRINCIPLES FOR PILOTS
While there are no hard and fast rules for establishing successful pilots, eight guiding principles that should be kept in mind are:

“It is reasonably cheap and easy to get a pilot up and running to evaluate how successful a new Technology will be. Fail fast, fail cheap. Set things up as pilots and pick up the lessons.”
CIO, large property developer

1. Select fertile ground.
Pilots often establish the tone for how broader initiatives are received across the organization. Stories – both positive and negative – about the success of pilots often filter out very widely. A successful pilot can easily take a life of its own as others hear about the benefits and actively want to apply them in their own work. Failures can often be referred to across the organization as reasons why related initiatives will not succeed. While you can never expect all pilots to be successful, maximize chances of success by selecting the most promising projects and the best team, and make it easy for them to identify value.

2. The pilot team is critical.
Perhaps the single most important success factor in Enterprise 2.0 pilots is the people involved. While there are a number of criteria in selecting a pilot team (for more details see below), the single most important attribute is enthusiasm. Given that these technologies require new approaches to working and communicating, uptake and resultant benefits will depend substantially on the degree of use and experimentation during the pilot.

3. Design around business applications or benefits NOT tools.
Far too often organizations decide to trial specific tools such as wikis and blogs without having a clear idea of why they are doing so. In the majority of these cases pilots fail to gain traction or result in clear benefits. Pilots should be designed either to create specific benefits such as streamlined processes and faster outcomes (which will provide clear measures for the pilot’s success), or an application such as project management or creating better sales forecasts.

4. Define scope but encourage experimentation.
In establishing pilot projects, a balance needs to be struck between having clarity on the intentions and scope of the pilot, and allowing experimentation that may uncover even more valuable uses and applications. A definition of pilot scope includes the immediate objectives, participants, and timeline for review. However if variations on the intended activity, or even entirely different approaches, seem to offer potential business value, these should be encouraged. Remember that experimentation is often the source of much of the value of Enterprise 2.0 implementations.

5. Design the pilot to learn useful lessons and expand.
Pilots are established with the primary intention of demonstrating value so that they can be applied more broadly across the organization. However even if the pilot is very successful, it should not necessarily be implemented in the same way for future roll-outs. And if the pilot is not seen to be successful, there may be even more useful lessons on how to improve or refine subsequent initiatives. As such, there need to be specific systems to capture lessons during and at the conclusion of the pilot.

6. Provide training and guidance.
If no training is provided on the use of a new tool, it should not be surprising if it is not used or used well. This can be done in many formats, including brief online learning sessions. It is possible to setup pilots so that usage guidelines and recommendations are provided at first login, and regularly during the process of the trial.

7. Create visibility.
In many cases you will want pilots to be visible outside the pilot group, in order to attract participation, generate demand in the rest of the organization, and stimulate ideas for other applications. For example providing reference materials on IT support or HR policies creates broad visibility for new approaches. However in some cases you may choose to keep pilots less visible if there are greater risks of failure or active experimentation by a small team.

“The earlier you determine when something should be killed, the better.”
Charlie Beaver, vice-president, Booz Allen Hamilton

8. Monitor progress and cut or expand.
It is a mistake to set up a series of pilots without subsequently assessing progress. That can be easier with Enterprise 2.0 tools than with some other technologies, given the very low costs of the tools. The mantra of “fail fast, fail cheap” is immensely relevant here. Specific timeframes – usually measured in months – for the pilots need to be established at the outset. Success needs to be assessed both in terms of the initial objectives and/or any other value that has been created in the process of the project (see principle 5 above). Decisions must be made on whether to continue, expand, discontinue, or change the pilot.

One of the most critical elements of this principle is the ability to establish and run effective pilot programs.

Below is an excerpt from Chapter 17 of Implementing Enterprise 2.0 on Pilots, which describes 8 guiding principles for pilot programs.

GUIDING PRINCIPLES FOR PILOTS
While there are no hard and fast rules for establishing successful pilots, eight guiding principles that should be kept in mind are:

“It is reasonably cheap and easy to get a pilot up and running to evaluate how successful a new Technology will be. Fail fast, fail cheap. Set things up as pilots and pick up the lessons.”
CIO, large property developer

1. Select fertile ground.
Pilots often establish the tone for how broader initiatives are received across the organization. Stories – both positive and negative – about the success of pilots often filter out very widely. A successful pilot can easily take a life of its own as others hear about the benefits and actively want to apply them in their own work. Failures can often be referred to across the organization as reasons why related initiatives will not succeed. While you can never expect all pilots to be successful, maximize chances of success by selecting the most promising projects and the best team, and make it easy for them to identify value.

2. The pilot team is critical.
Perhaps the single most important success factor in Enterprise 2.0 pilots is the people involved. While there are a number of criteria in selecting a pilot team (for more details see below), the single most important attribute is enthusiasm. Given that these technologies require new approaches to working and communicating, uptake and resultant benefits will depend substantially on the degree of use and experimentation during the pilot.

3. Design around business applications or benefits NOT tools.
Far too often organizations decide to trial specific tools such as wikis and blogs without having a clear idea of why they are doing so. In the majority of these cases pilots fail to gain traction or result in clear benefits. Pilots should be designed either to create specific benefits such as streamlined processes and faster outcomes (which will provide clear measures for the pilot’s success), or an application such as project management or creating better sales forecasts.

4. Define scope but encourage experimentation.
In establishing pilot projects, a balance needs to be struck between having clarity on the intentions and scope of the pilot, and allowing experimentation that may uncover even more valuable uses and applications. A definition of pilot scope includes the immediate objectives, participants, and timeline for review. However if variations on the intended activity, or even entirely different approaches, seem to offer potential business value, these should be encouraged. Remember that experimentation is often the source of much of the value of Enterprise 2.0 implementations.

5. Design the pilot to learn useful lessons and expand.
Pilots are established with the primary intention of demonstrating value so that they can be applied more broadly across the organization. However even if the pilot is very successful, it should not necessarily be implemented in the same way for future roll-outs. And if the pilot is not seen to be successful, there may be even more useful lessons on how to improve or refine subsequent initiatives. As such, there need to be specific systems to capture lessons during and at the conclusion of the pilot.

6. Provide training and guidance.
If no training is provided on the use of a new tool, it should not be surprising if it is not used or used well. This can be done in many formats, including brief online learning sessions. It is possible to setup pilots so that usage guidelines and recommendations are provided at first login, and regularly during the process of the trial.

7. Create visibility.
In many cases you will want pilots to be visible outside the pilot group, in order to attract participation, generate demand in the rest of the organization, and stimulate ideas for other applications. For example providing reference materials on IT support or HR policies creates broad visibility for new approaches. However in some cases you may choose to keep pilots less visible if there are greater risks of failure or active experimentation by a small team.

“The earlier you determine when something should be killed, the better.”
Charlie Beaver, vice-president, Booz Allen Hamilton

8. Monitor progress and cut or expand.
It is a mistake to set up a series of pilots without subsequently assessing progress. That can be easier with Enterprise 2.0 tools than with some other technologies, given the very low costs of the tools. The mantra of “fail fast, fail cheap” is immensely relevant here. Specific timeframes – usually measured in months – for the pilots need to be established at the outset. Success needs to be assessed both in terms of the initial objectives and/or any other value that has been created in the process of the project (see principle 5 above). Decisions must be made on whether to continue, expand, discontinue, or change the pilot.

By 2014, social networking services will replace e-mail as the primary vehicle for interpersonal communications for 20 percent of business users.

This is a transition that we’ve seen for a very long time, and looks finally ready to come to fruition. Coming from a financial markets background, I’d seen from as far back as the late 1990s that email as a primary medium was resulting in communication breakdown. I’ve long believed that shifting communication out of email was one of the main ways that social media would be valuable, as for example expressed in my 2005 white paper How Collaborative Technologies are Transforming Financial Services.

This prediction will play out very differently across organizations. Many companies will remain bound in email. Others, particularly those that are project-centric and effectively implement social software, could well see a substantially more than 20% of communication shift out of email. The development and evolution of new tools such as Google Wave will see email not quite die, but rapidly erode in the most innovative organizations.

By 2012, over 50 percent of enterprises will use activity streams that include microblogging, but stand-alone enterprise microblogging will have less than 5 percent penetration.

I agree that stand-alone microblogging is likely to have limited uptake. There are quite a few success stories for Yammer, the current leader in enterprise microblogging, but far more cases of it simply not taking off.

I think the forecast of 50% of companies using microblogging in some form by 2012 is optimistic. While many or even most platform vendors will offer this, a minority of organizations will go beyond tiny experiments. This is not to say that microblogging, effectively used, cannot be an extremely valuable tool. However relatively few will get there in the next two years.

Through 2012, over 70 percent of IT-dominated social media initiatives will fail.

More like over 95%.

Within five years, 70 percent of collaboration and communications applications designed on PCs will be modeled after user experience lessons from smartphone collaboration applications.

This is the most interesting prediction. What is most likely to be transferred from smartphones to PCs are the device user interfaces. There are very few enterprise collaborative apps on smartphones yet, so there is not much to learn so far. However the rise of the “third device” exemplified by the iPad will unleash a whole new world of collaboration. More and more collaboration and social media will happen on portable (but not pocketable) devices (as I noted in this recent interview on Sky Business). That is where lessons will be learned that can be applied to desktop devices.

Through 2015, only 25 percent of enterprises will routinely utilize social network analysis to improve performance and productivity.

This is a particularly interesting one for me, since I have been applying social network analysis to help organizations improve their performance for close to a decade now. Having seen the uptake over that time, including noting in 2006 that organizational network analysis was going mainstream, I reluctantly have to conclude that this forecast is overly optimistic.

One of the current trends in applying social network analysis inside organizations is that it is far easier to take digital communication trails (e.g. from email) to infer social networks in organizations. Tools such as Lotus Connections now have social network analysis functionality embedded in the system, and other vendors are integrating similar tools. However I am very aware of the difference between generating a social network map, and using this to improve organizational performance.

As I expressed in my California Management Review article Managing Collaboration with a Network Perspective, there is real competitive advantage from effective use of social network analysis. In fact for many of the most sophisticated organizations that have been developing their capabilities over the years, it is the single tool that is most likely to drive significant performance improvement. However I fear relatively few organizations will do this, or at least do it effectively.

Back in June, I posted some information on social graph engines triggered by my interest in Google Pregel. I still expect this area of social analytics to be a key capability organizations will need to focus on as they deal with large-scale processing of social graph data.I came across the info below (related to an Apache project) and thought I would pass it along:

Apache HAMA: An Introduction to Bulk Synchronization Parallel on Hadoop

Apache HAMA: An Introduction toBulk Synchronization Parallel on Hadoop

View more documents from Edward J. Yoon.

 Welcome to Hama project

Hama (means a hippopotamus in Korean) is a distributed scientific package on Hadoop for massive matrix and graph data. It is currently in incubation with Apache. The main goal of Hama is to provide computational tools for data-intensive scientific and industrial areas. It consists of two packages, which are the matrix package and the graph package.

• Scientific simulation and modeling
  • Matrix-vector/matrix-matrix multiply
  • Soving linear systems
  • Scientific graphs

• Information retrieval
  • Sorting
  • Finding eigenvalues and eigenvectors

• Computer graphics and computational geometry
  • Matrix multiply
  • Computing matrix determinate

For more information about Hama, please see the Hama wiki.

Welcome to Hama project

FrontPage - Hama Wiki

Hama (means a hippopotamus in Korean) is a distributed scientific package on Hadoop for massive matrix and graph data. It is currently in incubation with Apache. The main goal of Hama is to provide computational tools for data-intensive scientific and industrial areas. It consists of two packages, which are the matrix package and the graph package.

FrontPage - Hama Wiki

Architecture

BSP

The BSP package is a implementation of BSP over Hadoop RPC(sockets). By using a BSP model which is based on the concept of a superstep, during which processes perform computations using local data, a more rapid and sensitive program will be allowed.

• http://wiki.apache.org/hama/BulkSynchronizationParallel

Matrix

• http://wiki.apache.org/hama/Algorithms

Graph

• http://wiki.apache.org/hama/GraphPackage

Shell/DSL

• Hama DSL (Domain Specific Language) in Groovy -- Work in progress

• Hama Shell -- Work in progress

Architecture - Hama Wiki

The Graph Package (Angrapa)

The graph package, called Angrapa, is an large-scale graph data management framework for analytical processing. It is still in heavy development. Angrapa will employ massive parallelism on Hadoop, and It aims to achieve the scalability for processing tera bytes or peta bytes graph data. Angrapa will be used in a variety of scientific and industrial areas, such as data mining, machine learning, information retrieval, bioinformatics, and social networks, required to process large-scale graph data.

GraphPackage - Hama Wiki

Continuing my series of my blog posts that have attracted the most interest in 2009, here is my selection of 10 posts on Enterprise 2.0 and organizational effectiveness.

1. Why ‘critical mass’ is intensely relevant to Enterprise 2.0 user adoption
What the diffusion curve means for Enterprise 2.0 adoption initiatives.

2. Enterprise 2.0: Competitive differentiation occurs at the intersection of technology and culture
The harder it is to implement Enterprise 2.0, the greater the potential for competitive differentiation.

3. Pilots as a key instrument for improving organizational performance in a complex world
Why pilots are a key tool in applying complexity thinking to organizations.

4. Largest ever organizational network analysis shows how social networks drive performance
Research shows in detail the role of social networks in organizational effectiveness.

5. An Argument for Heterarchy: creating more effective organizational structures
Heterarchy as a valuable concept in organizational design.

6. 10 DOs and DONTs of organizational change
A very popular post on fundamentals of building more effective organizations.

7. Driving innovation in large professional service firms: Six high-return initiatives
Details on specific high-value initiatives to drive innovation.
1. Develop a systematic innovation strategy.
2. Establish lightweight innovation programs.
3. Set up a program of pilot projects.
4. Implement product development processes.
5. Run industry strategy workshops.
6. Identify and support innovation champions.

8. Uncovering high-value applications of organizational network analysis
Digging deeper into how social network analysis can drive organizational performance.

9. The immense value of expertise location will help drive enterprise social media
The state of expertise location and the role of social media.

10. Six ways technology is transforming small business
Why small business is using technology to leapfrog big business.

As a special bonus, here are links to four posts with free chapters from my book Implementing Enterprise 2.0:

- Free Chapter 2 - Web 2.0 and the Enterprise

- Free Chapter 4 – Key benefits and risks

- Free Chapter 7 – Governance

- Free Chapter 11 - Social Networks In The Enterprise

Previous posts:

Year-End Thoughts On Enterprise 2.0 & Social Software (Part 2)

Year-End Thoughts On Enterprise 2.0 & Social Software

There are a few vendor events that stood out in my mind for 2009 (related to Enterprise 2.0 and social software) - in no particular order:

Cisco Stumbles Early But Regains Composure & Sets The Stage 

Back in July, I published a post Cisco: Great Expectations But "Where's The (Collaboration) Beef"? that took Cisco to task regarding how strongly it was "talking about" collaboration but was not really "doing" much about collaboration. However, by the end of the year, things become much more clear as I outlined in several posts:

• Cisco Broadens Foray Into Collaboration Market
• Understanding Cisco's Collaboration Strategy (Part1)
• Understanding Cisco's Collaboration Strategy (Part 2)
• Understanding Cisco's Collaboration Strategy (Part 3)
• Understanding Cisco's Collaboration Strategy (Part 4)

The good news is that Cisco delivered its opening ante and salvo (hosted/SaaS e-mail) as it more proactively enters the collaboration market. In 2010, expectations will continue to rise that Cisco will have a decent critical mass of large enterprise accounts before we go too far with putting them on par with traditional collaboration heavyweights IBM and Microsoft. Cisco needs to develop an Enterprise 2.0 message and also come up with a plan to reach some level of solution/functional parity between its on-premises and SaaS-based collaboration solutions. I would like to see Cisco also have a more holistic message regarding collaboration/Enterprise 2.0 and its social media efforts. Finally - Cisco should strongly step up as a Google Wave platform - it should not let Google's XMPP efforts erode position as thought leaders when it comes to XMPP (via the Jabber deal).

On the UC front - Cisco's decision to anchor presence on XMPP should cause many IT architects to take notice. Right now, presence tags along with IM, telephony, etc. Cisco has transitioned presence into a model that not only supports XMPP and SIP/SIMPLE but has service oriented and REST interfaces. If Cisco can take steps to build a story around presence, location, and micro-blogging/activity streams - that could be a top story for 2010. Right now - Cisco should hammer Microsoft and IBM for their lack of broad XMPP support (gateways are just expected nowadays).

Microsoft Bets Its Social Fortune On SP2010

The SharePoint 2009 conference in Vegas provided the industry with the first look at SP2010 and its new/enhanced social computing capabilities. With an expected May 2010 release (my best guess), Microsoft has delivered enough "good enough" enhancements that will satisfy a large majority of enterprises committed to SharePoint overall. There is little in the upcoming release that is truly innovative or moves SharePoint out in front of other vendors offering capabilities associated with E2.0 but it is largely adequate. It provides IT organizations with enough ammunition to make a strong case against platforms that add too much infrastructure complexity/overlap.

That said, there is nothing in the release that I think will satisfy external needs (e.g., social media, external communities, certain extranet applications). For those organizations that have a strong business case that is best satisfied by a strong solution for internal communities and social networking - then over vendors are still very credible and viable as alternatives. This release is Microsoft's first serious attempt to support online communities. Some related posts where I commented on the good/bad that I heard in Vegas:

• Microsoft Social Computing Overview
• Analyst Breakfast With Microsoft Execs: Good Food, Insight Pending
• MySite - Social Architecture & Planning
• Customize Enterprise Wikis In SP2010

Overall, I don't see SP2010 eliminating the need for strategists in committed "SharePoint shops" to look at Jive, Telligent, NewsGator, or Lotus Connections given the right circumstances. There are situational needs that can still be best satisfied by competing platform and/or best-of-breed vendors. There also remains a lack of parity between on-premises and hosted versions of SharePoint so organizations strongly pursing a SaaS/Cloud strategy might have reason to pause re: SP2010 and social computing. However, in general, vendors will have to integrate with SharePoint 2010 at some level (e.g., ECM).

Oracle Comes And Goes (Again) - Stay Tuned For 2010 (Like You Did For 2009)

In May, Oracle seemed to renew its commitment to collaboration as I noted in this post Oracle Beehive 1.5: Still A Work-In-Progress. So I was optimistic that at the OpenWorld event the industry would see a more cohesive and aggressive collaboration strategy. But the event revealed a trail of missed opportunities as I noted in these posts:

• The Art Of The Possible
• WebCenter Vision and Strategy Session
• Beehive Session Notes

Clearly, Oracle has all the necessary technology assets to become a player in the collaboration market, taking on IBM and Microsoft. However, the go-to-market message remains a bit murky with overlapping sub-brands (WebCenter, Beehive) and messages (collaboration and E2.0). I also believe that Oracle seriously wants to have a stronger footprint in the collaboration market - leaving that space open to other competitors will leave its application business vulnerable to developers building collaborative applications in SharePoint for instance (especially given SP2010 improvements). Oracle remains a contender but really needs to streamline its message, product portfolio and most of all, execute well.

Potpourri

• IBM: IBM delivered Lotus Connections 2.5. Now that Microsoft has made SP2010 public I think the expectation bar will be set pretty high for Lotusphere. IBM squandered (my opinion) the time between MOSS 2007 and SP2010 to do the type of broad and deep integration with SharePoint that would have given it a beach head to compete when SP2010 does come out. As it stands, I think we're seeing a play to the Lotus and WebSphere install base - for the most part - there are examples of Connections in "SharePoint shops" - but we'll see if that type of situation remains by late 2011. Shops that are committed to both SharePoint and WebSphere have an "embarrassment of riches" I suppose when it comes to social computing but the duality also creates a very interesting debate on which way to go over time. Overall - Lotus Connections continued to mature in 2009. It remains a platform that Microsoft will be measured against.
• Jive: Jive Social Business Software (SBS) 4.0: While there were a number of incremental improvements the addition of application modules on top of the platform (e.g., Market Engagement, Bridging) stood out most. For Jive to stay above the infrastructure debate (e.g., Microsoft, IBM), they need to continue focusing on application solutions - especially those that connect external and internal constituencies. The idea of a platform that straddles internal/external environments to connect employees, partners, suppliers, customers gives Jive a unique edge. Although the differentiation is not unique, Telligent could duplicate this story as well.
• Google and Novell: Google gained a tremendous amount of media attention with its Wave announcement. I think the company deserves credit for pulling together a lot of various ideas over the years into a single concept and adding a unique angle to the technology (XMPP). However, it remains a "concept car" for me. What was intriguing was how Wave might be taken in unforeseen directions by the community and other vendors. For instance, talk about the past and future coming together. Novell surprised many people, including myself, with its Pulse solution that works with Google Wave. I believe that's how Google Wave will get into the enterprise - not so much by what Google does directly but how the community around Google Wave and more specifically, how the ecosystem of enterprise software vendors embed Google Wave and slipstream it into the Enterprise.
• Salesforce: Salesforce Chatter: Perhaps the most over-hyped media event in 2009 (my opinion). While interesting, the lack of details left me unimpressed so I suppose that by not jumping into the media-created "mosh pit" touting Chatter, I am in the minority here. I do recognize the trend of adding social context to applications - not unexpected for those studying market trends in this area - but I just prefer news that is real news vs. promises of something delivered sometime in 2010.
• Yammer / Socialcast / Socialtext: Micro-blogging becomes hot - then becomes a feature. Yammer and Socialcast helped make "Enterprise Twitter" a reality but then vendors like Socialtext made it a feature in a platform (as have other vendors). As it stands, micro-blogging (or social messaging as I call it), is a topic that clients are still interested in but not so much as a standalone tool. Socialtext might have been the first to convert the capability into more of a platform play - but now most everyone else is doing the same - and including activity streams as well.
• Open Source: Although Mindtouch does not come up often in my client inquiries - the company has been hard at work blending an open source model with SaaS. Architecturally strong, hopefully this solution will also get more notice in 2010. Liferay got a boost in my mind with all the Cisco news (there is a bit of Liferay DNA within Cisco's collaboration platform). Drupal and Elgg came up more often in my calls this year but nothing overwhelming. I am still hopeful that Apache SocialSite gains more notice in the media and traction in the developer community - Apache Social Site builds on OpenSocial and Shindig but does not seem to get noticed. Apache Abdera (Atom/AtomPub) also seems to have dropped off the news front. Hopefully that project will become more visible as well in 2010. 

In my last post, Year-End Thoughts On Enterprise 2.0 & Social Software, I wanted to provide a background context on some of the areas where Enterprise 2.0 remains ambiguous:

• Enterprise 2.0 is not a market. Enterprise 2.0 is perhaps best thought of as a collection of principals, organizational practices, and adoption methods that enables emergent participation and contributions models.
• Enterprise 2.0 is not a project. By this, I mean that organizations should not undertake Enterprise 2.0 initiatives for the sake of "doing Enterprise 2.0. This was the fundamental mistake that doomed many KM projects in the late nineties. There needs to be some business purpose - that purpose may be very intangible in terms of ROI, but there should be some localization and internalization of what E2.0 means to the enterprise itself.
• Enterprise 2.0 is not that big of a deal. There are too many voices that are taking E2.0 as the hammer to every nail. Enterprise 2.0 does not address all patterns of communication, information sharing, and collaboration.
• Social Software lacks definition. The Wikipedia definition that McAfee defaults to does not help clarify what E2.0 is about when it comes to use of social software. The best definition that I mentioned in the post comes from Clay Shirky. We too easily constrain social software to specific tools which leaves the door open to ambiguity and vendor posturing.
• Emergent Social Software Platforms remain ill-defined as well. ESSPs form the technical foundation for Enterprise 2.0 yet (1) there has been little effort to examine the evolution of social software platforms over time (made more difficult by a lack on consensus on what social software is in the first place), and (2) if there is such a thing as an ESSP then there must be a non-emergent SSP - so what makes a social software platform emergent - what examples of emergent social software platforms have we witnessed in the past and why did they fail or where did they succeed - and does that mean we have legacy ESSPs/SSps and what can we learn from those older generations solutions.

Enterprise 2.0-related activities overall continued to mature in 2009 from what I have seen in the industry and within Burton Group clients. From a tooling perspective, across the board, IT groups seem much more comfortable with social tools and social applications. Increased calls from identity and security teams indirectly tells me that these systems are getting more scruitiny as they are rolled out to broader audiences. From an organizational viewpoint, adoption challenges remain the most significant hurdle. Project teams consistently under-estimate the need for governance and change management efforts. Getting management to buy off on the business case is also difficult given the discretionary nature of such initiatives and the lack of traditional metrics to gauge ROI.

Wikis are highly commonplace when I talk to clients - sharing content is less "scary" (association with publishing perhaps) than some other tools such as blogs. It is not uncommon for organizations to have more than one Wiki provider but consolidation via standardization is underway. While purists will make the case that Wiki vendors (e.g., Atlassian) have distinct technical advantages over larger platform providers that offer less-than-perfect Wikis (e.g., Jive, IBM, Microsoft), it is clear that platform approaches are winning out. Most conversations now are about platforms that best support 

Blogging seems to be something that organizations remain somewhat skittish about (internally) - there are more blogs discussed during my calls than in 2008 but they still appear to be more controlled (versus letting all employees blog openly). This still strikes me as an irrational fear for the most part. There are valid concerns regarding confidentiality, compliance, etc but the fear that employees will use blogs as a soapbox is one that I have yet to come across when policies and governance programs are effectively put in place.

Tagging/bookmarking remains a nascent topic in my calls. Mostly I chalk this up to most enterprise intranets having poor native web content and the lack of bookmarklets in productivity tools which would allow people to tag/bookmark content in applications other than a browser. Most people I talk to see tagging and bookmarking as a feature not a product.

RSS (including Atom) discussions actually did increase this year vs. 2008 although overall, this topic remains below the level it should within the industry and clients. I chalk this up to the classic middleware dilemma. A feed syndication platform is essential from an architectural perspective. There remains too much emphasis on feed readers and not enough focus on the underlying management platform to handle read/unread marks, de-duping, security, storage and network management, analytics, and so on. NewsGator is the only viable enterprise option (for a feed syndication platform) in most cases. Major vendors (IBM, Microsoft, Oracle) are still missing in action when it comes to a complete feed syndication framework.

Social networking is taking off but from the perspective of a social network site (a "corporate Facebook") that acts as a community and social networking destination hub. Social network sites arguably represent the current E2.0 best practice. These platforms often contain a complete manifest of tools often associated with E2.0 (e.g., blogs, wikis, community spaces) along with profiles, social graphs - and more recently - micro-blogging / activity streams. Back in 2008 I defined (and shared on this blog) an architectural reference model (template) for an enterprise version of a social network site (based on the early work of dana boyd and Nicole Ellison who defined something similar for consumer sites). This model remains an accurate depiction:

Overall, the social network site is where most of the E2.0 action is from a vendor perspective. An illustration of how I personally view the competitive landscape is illustrated below. Platform Vendors are those that have established, broad-based environments. Domain-specific Vendors are those that concentrate on a set of related capabilities (sometimes referred to as best-of-breed). Emerging Vendors are those in a specific domain that compliment or augment an existing market model. Transformational Vendors are those that threaten an existing market model (possibly as a new entrant), or trigger disruption (changing market structure), or act as a template that enterprise vendors mimic (they do not enter the market but what they do has a direct influence).

The goal is to get to the center of the bulls-eye by the way. Note: so far, no one is there.

These charts go nicely with an early post and graphic I shared concerning Social Networking Platform Evolution: From Destination Site To Networked Services. While the focus currently is on a destination site, you can feel change in the wind as the focus shifts towards middleware services that enable social information to be contextually composed into other applications and productivity tools.

During the Enterprise 2.0 event in Boston last year, I moderated a discussion between IBM and Oracle on the topic of portals and its relation to Enterprise 2.0. Somewhere during the discussion, I wondered aloud how OpenSocial should be compared/contrasted and put into perspective within the enterprise as the most viable widget/gadget effort around. I'm happy to see a session on the topic for the San Francisco event on Wednesday morning hosted by Chris Schalk, Developer Advocate at Google. Panelists include: Adina Levin, Vice President of Products & Co-founder, Socialtext, Benjamin Mestrallet, CEO, Exo Platform, David Johnson, Web 2.0 Senior Architect, IBM and Jay Simons, VP Marketing, Atlassian.

Developers considering social applications should track ongoing work to evolve OpenSocial so that it can be used within the Enterprise. You can get involved by following the OpenSocial blog, the OpenSocial Wiki, or the OpenSocial Forum. You should also be aware of the Apache Project SocialSite effort - since it builds on Shindig - I am surprised it is not mentioned more by those involved in OpenSocial.

We need to start designing and implementing social networking platforms that have capabilities to span internal and external audiences. While initiatives that started off in the consumer market may not have the necessary identity, security, and other necessary services - alternatives within the enterprise are often not viable for consumer environments - so we are left somewhere in the middle - with no one particularly happy. Given overall consumerization of IT trends, it seems to me at least, that it's more viable (in the social computing realm) to start with efforts like OpenSocial and ActivityStrea.ms and evolve them for the enterprise than the other way around.

However, to be a viable approach - more enterprise developers need to participate (not vendors - developers from end-user organizations). And to be fair - developers from the consumer side of the market, need to embrace the need for robust permission models, audit, and other capabilities that are critically important to many organizations - especially if they are in regulated industries. I'm sometimes amazed at the naivete of some consumer vendors when it comes to some of the more serious and complex requirements for identity, security, compliance, etc. that are fundamental within the enterprise.

Below, is a relevant post from Adina on enterprise opensocial:

The conversation centered on changes to OpenSocial that will make it a better fit for the enterprise.

* OpenSocial is planning to incorporate the ActivityStrea.ms standard to represent activity. The standard has a well-developed draft, and has already been implemented by Facebook, MySpace, Windows Live, and Opera. An important next step there is a JSON representation of ActivityStrea.ms content. The Enterprise group agreed to have representation in ActivityStrea.ms (disclosure, that's Ryan Boyd of Google and me).

* The definition of "friend" was updated to make it clear that it supported relationship definitions that make sense in the enterprise. The language about the "friend" representation the standard covered the symmetrical relationships that are common in consumer applications such as FaceBook and MySpace, and business applications that deal with loose ties, such as LinkedIn. But the symmetric friend model makes less sense within the enterprise. What does it mean to ask to be friends with a corporate VP, or for your boss to ack to be friends with you? The asymmetric model used by Twitter, where each individual chooses people to follow, to manage their own attention. It wasn't clear to the folk at the meeting - including the people from Google, that the Friend definition could actually be used to cover the asymmetric friending suitable in the enterprise. We updated the definition to make it clear that asymmetric friend lists were acceptable within the standard.

* Single Signon and Security. Security and trust models are not well agreed upon or understood by the vendors. There was lack of shared understanding about how or whether to use OAuth, and how authentication and single signon might work with a multi-layer model including gadget contents, container, application server, and corporate directories. In particular, there was a lot of discomfort with the assumption that the container (server side) could hold tokens for widgets to use to access external apps on behalf of a user. One person from Cisco said that they could basically not do that at all. The next step is for the conversation to continue on the OpenSocial mailing list.

* Intergadget communication. There was a fair amount of interest in intergadget communication, in particular the relationship between work done by the OpenAjax alliance and Google's work on pubsub. Mark Weitzel of IBM has the ball to submitting a spec proposal on this topic.

* Other technical development. There are ongoing development efforts with technologies such as Google secure data connect (which can be used for tunneling through firewalls), Shindig (the opensource server and client reference implementation of OpenSocial), and Caja (sandboxed JavaScript). The next step is for Chris Schalk of Google to arrange webinars on SDC, Shindig, and Caja development.

* Web standards are gaining adoption in the enterprise, and more information is needed for enterprise developers about the benefits and options available to them. The group took on a task to write a White Paper on OpenSocial in the Enterprise (Disclosure: Gabe Wachob is one of the authors)

SocialText