Tag Archives: publishing

Enterprise Social Software and Portals: A Brief Comparison of Deployment Patterns

In my last post, I examined whether or not Enterprise Social Software (ESS) is the functional equivalent of enterprise portal applications as they existed ten years ago. My conclusion was:

From a functional perspective, ESS is quite similar to enterprise portal software in the way that it presents information, but that does not tell the whole story. ESS lacks critical personalization capabilities, but provides better collaboration, process, publication and distribution, categorization, and integration functionality than portals. In my judgment, ESS is somewhat similar to portal software, but mainly in appearance. It makes more functionality available than portals did, but needs to add a key missing piece – personalization.

In this post, I will focus on the observation that ESS resembles enterprise portals in another regard – how and why it is deployed.

Enterprise v. Smaller Deployments

Portals were initially marketed as a tool for enterprise-wide communication and interaction, with each internal or external user role having its own personalized set of resources available in the user interface. While there were some early enterprise-wide deployments, portal software was deployed far more often at the functional level to support specific business processes (e.g. sales, procurement, and research portals) or at the departmental level to support operations.

Enterprise social software has also been touted as most valuable when deployed across an organization. However, like portal software, ESS has most often been deployed at the functional level in support of activities such as marketing, customer service, and competitive intelligence. As a result, the promised network effects of enterprise-wide deployments have not been realized to-date, just as they were not with most portal deployments.

Internal- v. External-Facing Deployments

Most early portal deployments were internally-focused, as shown in this InformationWeek summary of market research conducted in 2001. Not only was there a smaller number of externally-focused deployments, mixed-audience deployments did not begin to appear until the portal market was extremely mature. ESS deployments have followed this same pattern, and we are just now seeing early efforts to blend inward- and outward-facing business activity in common ESS environments.

Internal Use Cases

Portal software was often deployed in response to a specific business need. Among the most common were:

  • intranet replacement/updgrade
  • self-service HR
  • application aggregation
  • document/content management
  • expertise location
  • knowledge sharing
  • executive dashboards

ESS has been deployed for many of the same reasons, especially intranet replacement, application aggregation, expertise location, and knowledge sharing.

External Use Cases

Portal software was deployed externally to provide self-service access to corporate information. In some cases, access to selected application functionality was also provided to key business partners. Retail and B2B portals enabled customers to purchase goods and services online. Process acceleration, revenue growth, and cost reduction were the key business drivers behind nearly all external portal uses.

ESS doesn’t seem to have the same goals. I have seen some, but little, evidence that external communities are being leveraged to accelerate business processes or reduce costs. Peer support communities are a good example of cost reduction via ESS. The goal of most outward-facing ESS deployments seems to be customer engagement that translates (eventually) into increased innovation and revenue for the deploying organization.


ESS deployments today strongly resemble portal projects that were undertaken ten years ago. Few, if any, ESS deployments have been enterprise-wide. Instead, ESS is deployed to many of the same department and functional groups, to support the same business processes, and to drive many of the same business results as portals were a decade ago (and still are.)

What does this commonality with early portal deployments mean for ESS? I will examine that in my next post. Until then, I would love to hear your reaction to what I have presented here.

Enterprise Social Software: The Second Coming of Enterprise Portals?

Enterprise Social Software (ESS), at first glance, is eerily similar to the portal software that was the hot enterprise toolset 10 years ago. That became very clear to me during the Enterprise 2.0 Conference in Boston last month, even though I was only able to attend the first 2 (of 4) days of the event.

I have noticed and commented on the parallels between the portal software market as it existed a decade ago and today’s enterprise social software category in a previous post. However, the notion of their similarity was reignited by a comment that I overheard as I walked through the exposition space at this year’s E2.0 Conference. One individual said to his companion something to the effect that if the branding was removed from each vendor’s ESS demo, one would be hard pressed to say which offering came from which specific provider. In other words, there was very little differentiation of user interface (UI) layout or functionality. In fact, every screenshot and live demo that I saw looked like a portal, in that the UI was a collection of data and unstructured information aggregated into a single interface and presented through a number of widgets.

Similarities in Functionality

In 1999, Delphi Group published a portal architecture diagram, which depicted the layers of functionality that the firm thought were required of a robust enterprise portal solution.

Examining each layer of the portal architecture model and commenting on its applicability to ESS as it exists today will allow us to determine whether ESS really is just another incarnation of portals or if there is something significantly different being offered.

Presentation: In portals, data, unstructured content, and application functionality were  aggregated from multiple sources and presented in widgets, whose layout on the screen was usually customizable by individual users. ESS strongly mimics this UI design, including, in some cases, the ability to customize which widgets are displayed. Most ESS providers are beginning to offer application stores stocked with widgets that can be run in their offerings, exactly like portal software vendors rolled out portlet libraries for their users a decade ago. Finally, portal access on mobile devices was big deal 10 years ago, as is mobile access to ESS functionality today. So portals and ESS certainly appear to be the same.

Personalization: The primary value-add of portal software, in addition to it aggregation capabilities, was its ability to personalize (and, thus, filter) information based on a user’s unique digital identity and organizational role. ESS needs to improve vastly in this area; currently, most information must be manually filtered. This typically occurs via selection of one or more parameters ( to narrow the organization’s activity stream) or by following an individual, group, space, or tag. ESS should apply more profile information and use heuristics to dynamically effect what information is applied on an individuals dashboard or home page.

Collaboration: Some portal deployments embedded collaboration workspaces or their individual elements (IM or chat, discussion forums, polls) into the UI, but, in general, most deployed portals fell short as full-fledged collaboration tools. ESS is a definite improvement here. The array of available collaboration tools is richer and they are more usable, which results in higher adoption.

Process: There was a lot of ink spilled about process portals, but the promise was never fully realized, although there were some exemplary deployments. Process portals had workflow (BPM) either embedded directly into the portal technology or available though an integration with a stand-alone process engine. Similarly, there has been much talk about the need to process enable ESS. The good news is that we might actually execute on the vision this time around. We are beginning to see process-related notifications generated by applications integrated with ESS appear in activity streams. The next step will be to add lightweight activity and information coordination functionality (not full-blown, rules-based BPM) to ESS.

Publishing & Distribution: Portals were (and are) used to publish links to documents, syndicated content, and web clippings. ESS is also used heavily to publish and distribute content and goes well beyond what was possible in portals 10 years ago by adding additional content sources such as status messages, shared bookmarks, blogs, and wikis.

Search: Despite the push nature of information flow in portals, the ability for individuals to find and pull information was also very important for portal users. Search is equally important in ESS and, generally speaking, has under-performed, as it did in portal implementations. So, unfortunately, the similarity in this aspect between portals and ESS is negative in effect.

Categorization: Taxonomies were widely used in portals deployments to aid information personalization. They are still important in ESS, but their new relative, Tagging, is equally valuable in its ability to aid information personalization, browsing, and recall. We now have more tools at our disposal to apply to the information overload challenge than we did 10 years ago.

Integration: Integration of other enterprise applications and content sources was key to realizing the value that portals offered through their ability to aggregate information into a single interface. Portal integration was accomplished using a combination of hard-coded connectors, XML, and JSR-168/WSRP standards. The ESS value proposition also seems to be closely tied to the integration and aggregation model. However, ESS makes better use of defacto integration standards, including REST, RSS, and OpenSocial.


From a functional perspective, ESS is quite similar to enterprise portal software in the way that it presents information, but that does not tell the whole story. ESS lacks critical personalization capabilities, but provides better collaboration, process, publication and distribution, categorization, and integration functionality than portals. In my judgement, ESS is somewhat similar to portal software, but mainly in appearance. It makes more functionality available than portals did, but needs to add a key missing piece – personalization.

Are there similarities in deployment patterns between ESS and portal software as it existed 10 years ago? If so, what do the functional and deployment affinities between the two software categories mean for the evolution of the ESS market? I will attempt to answer those questions in my next post. Until then, I would would appreciate any comments or questions you have on my analysis of their overall functional likeness and differences.

Emerging Enterprise Content Management Trends

Crystal Ball Gazing

I was at the Gilbane Conference in San Francisco last week, where I answered questions as a panelist, moderated another panel, heard many excellent presentations, and joined in many engaging discussions. On the plane ride home, I took some time to piece together the individual bits of information and opinion that I had absorbed during the two-day event. This reflection led to the following observations regarding the state of enterprise content management practices and technologies.

Up With People

Many content software vendors are now focusing on people first, content second. This is a huge shift in perspective, especially when voiced at a content management conference! Kumar Vora, Vice President & General Manager, Enterprise at Adobe was the first person to proclaim this philosophical change during his opening keynote presentation at Gilbane San Francisco. He reported that Adobe has shifted its business philosophy to focus on serving people and their needs, as opposed to thinking about content first. Many other vendor representatives and attendees from end user organizations echoed Kumar’s emphasis on people during the event. It is too early to say definitively what this radical change in perspective means, but we should see more user friendly enterprise content management tools as a result.

Keyword Fail

Keyword search has largely failed end users and incremental improvements haven’t been able to keep up with the explosion in newly created content. Jeff Fried, VP Product Management for Microsoft’s FAST search engine actually proclaimed that “keyword search is dead!” The business world is at a point where alternatives, including machine-generated and social search techniques, must be explored. The latter method was on many attendees minds and lips, which should not surprise, given the shift to people-centric thinking identified above. Social search will be an increasingly hot topic in 2009 and 2010.

SharePoint Upheaval

Microsoft SharePoint 2010 has the potential to completely shake up the information management market. The next version of SharePoint will likely include a raft of (as of yet unconfirmed) Web Content Management features that have been missing or rudimentary. In her keynote address, Tricia Bush, Group Product Manager for SharePoint said that the promise of content management has not yet been realized and that her team is focusing diligently on the opportunity. This increased emphasis on content management is contrary to the first trend that I described above, and the negative perceptions many hold of SharePoint may increase unless Microsoft also better enables people in SharePoint 2010 (it is rumored that the product will also see substantial additions to its currently limited social collaboration functionality.) Those placing bets should do so knowing that Microsoft intends to, and probably will, be a major force in enterprise information management.

Simplicity Trumps Complexity

Enterprise applications and systems managed by IT departments continue to grow in complexity. As this happens, end users turn to simpler alternatives, including consumer oriented Web 2.0 applications, in order to get work done. The “problem” is that these consumer applications aren’t approved or controlled by the IT function. The opportunity is a potentially large market for software vendors that can create enterprise ready versions of Web 2.0 applications by adding security, reliability, and other attributes demanded by CIOs. For those vendors to succeed, however, they must retain the simplicity (intuitiveness and ease of use) that are the hallmark of consumer Web 2.0 applications.

Communication Beats Publishing

Communication applications are increasingly being used by end users to collaborate, because enterprise content management applications have become too complex (see the trend immediately above). Additionally, communication tools are favored by end users because they can use them to simultaneously create and distribute content. This increased speed of content publication also accelerates general business process execution, allowing users of communication tools to be more productive than users of formal enterprise content systems. Communication tools will continue to become an important and growing back channel that employees use to share content when overly complex publishing tools impede or fail them.

Having one’s ideas validated by a reputable peer is always rewarding. John Mancini, President of AIIM, published a blog post in the time between when I first formulated these thoughts on the flight home from San Francisco last week and when I published this post today. Reading John’s post should encourage you to believe that the trends I (and he) have described are for real. The question for all of us now is how will we respond to these emerging realities.

Photo credit: Charles Soper (via Flickr)