Let’s cut to the chase, this is how it should NOT look like:

Fig 1: Internal Collaboration Enterprise Social Graph of the US Senate – 2009  (Source: Slate.com)

The graph you are seeing above is a visual representation of internal collaboration enterprise social graph of the US Senate [This force directed graph from Slate is based on votes in 2009 (I will be working on a 2011 graph). Each blue dot represents a Democratic senator, each red dot represents a Republican senator. A line connects two senators when they voted the same way on 65 percent of the votes]. The force directed graph clusters dots with the most connections to each other, pushing away dots with the least connections and as a result we can visually identify the people who collaborate with each the most and those who collaborate the least.

In my engagements with various companies, I have observed that many people draw an enterprise social graph as dots connected by lines, some even go as far as drawing pretty clusters of dots connected by lines as shown in the US Senate graph above. While such a graph is not incorrect, it is not what you want your internal collaboration enterprise social graph to look like if you are to have effective internal collaboration. An effective internal collaboration enterprise social graph looks like this:

Fig 2: Effective Internal Collaboration Enterprise Social Graph (Source: Tom Chikoore -http://tomchikoore.com)

It’s not pretty, it’s messy but it’s effective. Each dot represents an employee and each line represents two employees who follow each other on an internal social enterprise collaboration community. This means each line represents a “bi-directional” follow between two employees. A bidirectional follow represents an open communication channel for effective collaboration. The color of each dot represents department in the organization. The following is a legend for some of the organizational departments shown in the graph:

BLUE – Sales
RED – Engineering
SALMON – Product Marketing
FLUORESCNET GREEEN – Product Management
ORANGE – Marketing
BLACK – Professional Services
ACQUA – Support
QUALITY ASSURANCE – Saddle Brown
LIME GREEN – Vendor

From this graph, you can see that the departments that one would expect to collaborate with each other are collaborating with each other. This is a beautiful visualization: Notice how the Support team is positioned between Engineering and Professional Services; and Professional Service is positioned between Support and Sales. This is the type of relationship you would expect to see is the majority of product development organizations. QA is positioned right next to Engineering and Product Management is nestled between Engineering Product Marketing, and Sales. This is what you would expect in most organizations, this is what your internal collaboration enterprise social graph should look like.

You can think of graph depicted above as a depiction of the “internal collaboration DNA” of your organization. Using this graph and the right algorithms, an assessment of the health of your community is possible. The right tools can help you identify collaboration problems and suggest solutions to fix the problems to enable effective internal collaboration.

For more information on the social graph and community health assessment tools send me an email at tom AT tomchikoore.com

To help answer this question, here is the Web 2.0 school of thought that I subscribe to:  Let’s start off with an enterprise database analogy. The basic assumption is that blogs are nothing but a data store.  While information in a blog makes for an interesting read, it is about as interesting as reading data in a text column in a relational database.  While the data in a single text column may have a lot of meaning, its meaning and usefulnes is enhanced when the data is combined with other columns in the same table in database, or with other tables in the same database, or even with data in other databases. The wealth of data is hidden in its interconnections with other data. In order to harvest the wealth of data in databases, applications are built on top of the databases that reference and make relational semantic inferences between the data in the database(s).  Today, blogs are the database(s). What is lacking are the applications that harvest the wealth of information stored in the blogs.  These are the applications that the next wave of Web 2.0 companies (including myself) are working on. 

The pace of these next generation applications is being hindered by the lack of a consistent structure (standard) in blog data. What Isikold is bringing attention to is that unlike relational databases, which adhere to relational database management system standard (characterized by a simple TABLE/COLUMN/ROW+SQL structure that has been consistent over the years), blogs have no such standard. The structure of blogs is currently left up to the blogging platforms such a WordPress, Typepad etc. Blogging standards today are akin to having Oracle, SQL Server, MySQL each using a different standard for storing and retrieving information. Not only a different a standard for each of the databases, but a different standard for each version of each database.  Exacerbating the problem further, each of the different databases being customizable by anyone and anyone can change the standard to a standard of their liking. If these databases were is such a state, it would be very difficult to write any applications that leverage data from these databases. ODBC and JDBC standards would be very unreliable, if not useless.  Such is the state of the blogosphere today when one looks at it from a data interface perspective.  

As many of you know, I am currently devoted to work on the layer of applications that leverages the data in blogs and beyond in order make such data more useful to users.  The lack of standardization (as described above) makes it difficult to identify the content in blogs.  Content identification is important because an application needs to be able to identify the difference between actual blog post text and some other text on the blog so that analyses and inferences can be established appropriately.  I have been monitoring the different types of templates in an attempt to predict template patterns for the different blogging platforms (mainly WordPress, TypePad, Blogger, MovableType).  I came to the conclusion that pattern prediction is only successful to a certain point due to the following

1) the original templates from the blogging platform vendor consists of multiple major and minor versions that do not have a predictable consistency in the template content tagging and

2) there are modified/hand coded templates floating out there which are totally unreliable.

As a result of these observations, I have resorted to writing my own content identification algorithms that include a combination of template pattern predictor algorithms and NLP based semantic blog post text identification algorithms.  While this has served me well up to now, a blog template standard will be very beneficial not only to myself but many people who have not figured out how get past the problem.  

Isikold is suggesting that a standard be adopted with the goal of giving blog templates a consistent structure.  This means the adoption of a template standard that identifies the different types of data on the different parts of bogs post. Isikold is suggesting that on a blog post, the template should make it easy to identify the blog post text, the side bar, the name of the author, the data that blog post was published, the tags for the blog post content and the blog posts comments.  I believe an adoption of this simple template will go a long way in helping to bring the next wave of Web 2.0 applications to market faster.  I support a blog template standard.

The applications that I am working on are reliant on some calculations using RSS dates.  I have noticed that the RSS date specification is probably the most taken for granted part of the RSS spec.  It is taken for granted because many consumers of RSS program around the date inconsistencies so there is not much of an outcry.  However, when you see a date like 01/02/07, you have to stop and say something. 

To those developers generating RSS feeds, please take a look at the RSS date format specifications as per the RSS specification.  I will summarize it here: 

The RSS date must conform to the RFC-822 (refer to the BNF for “date-time”  in section 5) date time format.  Examples of this format are: 

Wed, 04 Feb 2008 08:00:00 EST

Wed, 04 Feb 2008 13:00:00 GMT

Wed, 04 Feb 2008 15:00:00 +0200 

Do not just execute a stringifying method on your date object before writing it to the RSS feed.  Set the date format to the above mentioned format first before writing it to the RSS feed. 

To validate whether your date is correct, you can use http://feedvalidator.org

The successful migration of Web 2.0 to the enterprise hinges on the successful adoption of the Web 2.0 concepts into the enterprise. I will go into some specific application examples here to help move this discussion forward:

Supply Chain Management: Most enterprise software has an event notification system of some sort. Most of the events are in proprietary formats, thus are only consumable from a specific vendor’s software. RSS can move the enterprise towards client agnostic event notifications. For example, if database triggers on an inventory control table, generate RSS, an inventory manager can be notified on their mobile e-mail client or RSS reader of choice whenever the stock unit re-order level is reached. RSS provides more choices for the consumption of event notifications beyond the e-mail and app notifications that are generally used today.

Sales and Marketing: The sales and marketing organization within the enterprise is the best example of a candidate for an application that implements social networking concepts because the interaction patterns between the members of this organization mirror the social networking that occurs outside the enterprise. At a previous job, I would often venture to the sales and marketing department’s section of the company intranet; I noticed that they used any tool they could get their hands on in order to communicate. This included bulletin boards (to announce deals), threaded discussions (to discuss strategy for prospects) and good old e-mail blasts (to find out if anyone know anything about a prospect). The current hodge-podge of tools used by sales and marketing organizations can benefit from applications that aggregate social networking concepts around information sharing.

Human Resources: An enterprise’s human resources organization can benefit from the concept of a “social graph”. Social graph concept enhance the traditional org chart. For example, an application that implements an HR social graph that describes relationships between employees such as ” employed A worked with employee B under the management of employee C on project X in year ZZZZ” is very valuable to a member of the organization that is looking to put together a team for a new project. By examining an employee’s historical social graph, the organization can better assess an employee’s experience and it also helps the employee in career planning.

Customer Relationship Management: The implementation of Web 2.0 in CRM is pretty obvious and has been well articulated. CRM is an example of case where complete Web 2.0 applications can be transplanted into the enterprise e.g. a LinkeIn-like application provides the same benefits as part of a CRM suite as-is.

Here are some of my thoughts around enterprise technology:

Widgets: While widgets have really taken off in the Web 2.0 world, the major enterprise vendors have been traditionally strong in this space through the concept of portlets. Ironically this is concept that came about from the Web 1.0 days. However, there is still some opportunity around the delivery and integration.

AJAX: When enterprise software vendors moved from the desktop app model to the web app model, their customers clamored for the same rich user experience that they had on the desktop. The experience on the desktop was enhanced by a better UI event model. As a result, for the past several years most UI teams at major enterprise software vendors have been dedicated to re-capturing the desktop experience. They primarily achieved this by hacking some AJAX-like functionality well before the AJAX that we know of today. In my assessment, the user wants the desktop experience, so it is highly unlikely that vendors will invest their UI teams’ development cycles in AJAX, instead they are more likely to spend their cycles porting their code to RIA frameworks instead.

Data: There is a wealth of data that is very useful to the enterprise, especially to marketing organizations, that resides outside the enterprise (on the web). However, enterprise software vendors mostly build applications that access and manipulate data that has been gathered and structured in their databases (and most preferably using their apps).This traditional reluctance of the enterprise software vendors to go outside the firewall provides an opportunity for Web 2.0 applications that gather, structure (and store) data resident outside the enterprise for use within the enterprise.

Semantic Web: In this case, I prefer to call it the Semantic Enterprise. Enterprise applications from the major vendors come with a heavy dose of semantic information both for the application itself and the data that it generates in the form of meta-data. Content Management systems from enterprise vendors usually provide a lot of meta-data (not necessarily RDF but XML nonetheless) to describe the content. This meta-data is a great starting point for Web 2.0 applications that implement semantic web concepts.

Meta data: Enterprise software systems are heavily meta-data driven (for reasons that I will not go into here). This means user interfaces, application interfaces, data sources and data are all described using meta-data. The implementation partners of the vendors have access to metadata generators and sometimes the meta-data spec itself. If one wants to develop Web 2.0 applications for the enterprise, approach the vendor for the meta-data generators or the spec itself and you should be ready to go. Most vendors are working on SOA frameworks, so you should have no problem integrating your application.

In short, the Enterprise 2.0 approach that I am advocating here is first understanding how the current enterprise systems work before judiciously determining where to apply concepts vs. products. Obviously other people have other approaches and it would be great if they can chime in.

Lastly, let me take a stab at the Facebook-type application question from your reader. I think a Facebook-type of application can be adopted for an enterprise – with some restrictions. One has to realize that “social” networks in an enterprise are not organic. The nature of the enterprise does not lend itself to organic networks similar to those that form outside the enterprise. In an enterprise you may not be able to choose your “friends”. Your “friends” were chosen for you when you accepted that job offer. So an implementation of a Facebook-type of application may have to use a different granularity for its “users”. For example, it may have to be a group oriented Facebook –type application rather than a user oriented Facebook-type application. 

Today, the words “enterprise” and “social”,  convey two contradictory notions. The enterprise today is characterized by its emphasis on the productivity of the individual employee. For the 8+ hours that an employee is at work, they are supposed to be 100% productive (even though we all know that this rarely happens).  “Social” is  a word that does not really exist in the vernacular of the productivity oriented enterprise especially as it relates to software.  Everything in the enterprise is geared towards productivity, thus every enterprise software vendor attempts  to tag their software with the phrase “productivity tool”. With all this obsession with productivity, the enterprise is very “anti social”. Thus, the perception of social computing in the enterprise is not really the same as that of the people outside the enterprise.   While those outside the enterprise harness the variety of benefits of social software for variety of business needs on a daily basis, to some in the enterprise, social software still carries the stigma of being a non productive, time wasting web based consumer applications that you use at home (not at work).  Unlike those who believe that the terms “enterprise” and “social” are contradictory, I believe otherwise.  I think that there is a lot of social software that can be very beneficial to the enterprise but the enterprise will not fully embrace it until three things happen: 

1. Social software companies need to leverage concepts that being applied by web-based consumer applications rather than try to implement these application the enterprise as they are.  Trying to implement a Facebook in an enterprise is not necessarily the right approach, however, applying the concept of a “social graph” for a Sales Department or “implicit web” concepts for lead qualification and cross selling will have a better shot of being successful in the enterprise.

2. Elimination of the word “social”. While this may sound silly, I think I may be onto to something here. Words like “productivity” and “collaboration” mean something in the enterprise.  Take for example, del.icio.us concepts can be very useful in an enterprise intranet; however, calling that concept  “social classification” will not carry as much weight in the enterprise as “collaborative classification” So, instead of “social networking” maybe start using “productive networking” or “collaborative networking”. No more “social graph”, it’s now a “collaborative graph” J A good example is IM/Chat which was renamed to “Real Time Communications Suite” by some enterprise vendors (well, you guessed it, the word ”Chat” is too social); it is quickly becoming a staple within the enterprise.

3. The enterprise needs to make a mind shift from its current notion of “productivity tools”.  The enterprise is beginning to absorb a generation of employees who are proficient with “social” tools. Why not leverage the social tools to make them even more “productive”?

The perception of the gap between “enterprise” and “social” exists only at a semantic level. The convergence of the enterprise space and the social space is inevitable; however for some of the more popular applications, it’s not a matter of simply transplanting the application as-is but rather, transplanting the concept. 

I believe Enterprise Social Software/Enterprise 2.0 is here to stay. Recall several years ago many companies resisted employee access to the web in the enterprise because it would affect “productivity”.  Looks like a similar battle brewing here.