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.

Conclusions

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.

About these ads

21 responses to “Enterprise Social Software: The Second Coming of Enterprise Portals?

  1. Pingback: Enterprise Social Software: The Second Coming of Enterprise … -Political Fund USA

  2. Pingback: Tweets that mention Enterprise Social Software: The Second Coming of Enterprise Portals? « Together, We Can! -- Topsy.com

  3. Nice post Larry. I think the initial complexity and expense of Portal 1.0 deployments drove the adoption of the large second wave of WCM offerings as customers sought simpler, cheaper alternatives. “OK, I don’t need everything, just give me a simple website that I can publish content to.”

    But as WCM products and their constituents have become more sophisticated, the resulting websites have had to become ever more interactive. The portal model of assembling web experiences out of pre-assembled building blocks — both on the end-user side as well as on the back-office admin console side — is now more relevant than ever.

    I find that much of the analysis that compares X to “portals of 10 years ago” doesn’t allow for the fact that those first generation portal platforms have all evolved with the times to incorporate many of the best elements of WCM, BPM, Collab, Social Media, etc — that goes not just for commercial portal products but also for their highly competitive open source counterparts. Why not make the comparison with the new Portal 2.0 generation of those original offerings? It seems clear that all of these enterprise middleware categories are converging towards an ever-alluring yet ever-elusive all-in-one application hosting platform — the web operating system of the future.

  4. Good way to think of this…could a company replace its existing portal with a new ESS? I think they could, depending on an ESS’s document management capabilities.

  5. Pingback: Political Campaign Expert » Blog Archive » Enterprise Social Software: The Second Coming of Enterprise …

  6. Pingback: Political Fund Consultant » Blog Archive » Enterprise Social Software: The Second Coming of Enterprise …

  7. Pingback: Enterprise Social Software: The Second Coming of Enterprise … « Politics And Funds

  8. It seems many vendors of portals will naturally take an evolutionary approach and layer on “social” features to their existing enterprise software platforms. This approach has user interaction and adoption challenges to be sure.

  9. Pingback: Get Political Fund » Blog Archive » Enterprise Social Software: The Second Coming of Enterprise …

  10. Pingback: Enterprise Social Software: The Second Coming of Enterprise … « Social Computing Technology

  11. Great “keep it real” blog Larry –

    Of course a differentiator is that each product has its different market that are going for (HR, Marketing, Eng, PM, etc.), but then yes – they seem to mash up a bunch of common features – which they must do, otherwise ironically they become uncompetitive.

    Another differentiator is on the backend – how open their APIs are, and also their third party developer community.

    For me as a customer, this would play large favor on which platform to choose – since without this, the vendor is being very short-sighted on the value of other technologies – some purpose-built ones, that could (should?) be swapped in as an option for their customers.

    In particular, I see this in three areas

    1) Hutch called out one: *doc management* (or CMS/DMS, and everything surrounding this area – not small at all)

    2) You called out *Search* – which indeed is a mixed bag, and usually not cross-system outside the main platform

    3) Wiki – underestimating the value of the wiki functionality for key productivity given advanced platforms out there like Confluence and MindTouch seems absurd to me – integrating with advanced wikis gives the customer the best of both worlds.

    Another one as you mentioned is indeed publishing output formats (and processes to do so). Seems to always been been a hard area to standardize on for some reason. PDF was a step forward, even if a uneditable format. At least its clean.

    As you can tell, pretty passionate on the theme – in fact building a business around the need – since customers need this flexibility to overarching platform systems.

    http://www.appfusions.com/category/sub-dashboard.action?categoryKey=vision

  12. Portal replacement has actually been a major source of business for PBworks. The other difference between ESS and portals is that you can get ESS in a hosted and generally more affordable fashion. As Sean Nicholson has pointed out, in many cases, you can get a hosted ESS solution with more functionality than what you’re paying in maintenance on your nearly EOL portal solution.

  13. Sorry I got off the topic here on my comment a little – but have one more.

    An area that is not covered in the Delphi diag which I think merits its own is reporting and analytics.

    Statistics – can’t get enough of it, and an important differentiator between products today, from then (even if was important then too, in terms of need – tracking data has definitely has more emphasis nowadays).

    Platforms that focus on it more benefit without a doubt. Tangible examples in today’s marketplace.

  14. Pingback: Enterprise Social Software: The Second Coming of Enterprise … « Harrington Fundraising

  15. John: Thanks for your insightful comment! I’ll respond to two separate points that you made.

    1. You cited an interesting pattern – the tendency of technologies to move from initial simplicity to over-complexity. Granted, portals were not particularly as simple in their deployments as some other enterprise application categories, but they definitely became increasingly complex as organizations applied portals to more use cases. WCM (and all CMS for that matter) was also burdened with increasing complexity over time, for the same reason. What is really interesting to me is that we are now seeing the convergence of portal, WCM, CRM, BPM, collaboration, and analytics technologies (among others) into a new category of User Experience Management software. Talk about potential complexity! If we don’t find a way to keep things simple for enterprise software users, they will continue to turn to consumer-focused Web 2.0 technologies to get work done. My big trend prediction: We will see single-function applications, like those written for and deployed on mobile devices (i.e. iPhone, Android), deployed and heavily used within enterprises in the next 3 years.

    2. Your point that my comparison of current Enterprise Social Software with 10 year old portal technology isn’t exactly fair is true. However, my intent with this post (and the next one) is to compare those software categories at early stages in their development and use. My hope is that at the end of this analysis (this post and the next one to be published), vendors and deployers will see the choices that must be made to avoid repeating the strategic and tactical mistakes that caused the enterprise portal software market to severely contract in 2002-2003.

  16. Hutch: Many thanks for offering an excellent question to ask. The Delphi model included document management in multiple tiers of the conceptual architecture, including the Collaboration, Publishing & Distribution, and Integration levels. Portals have changed since this model was created and now allow deployers to use basic DM functionality that is embedded into the platform, as well as integrating with external CMS. Seems to me that ESS is also providing deploying organizations this sort of flexibility, with an emphasis on integration to third-party CMS.

  17. Ryan: Yes, there are challenges inherent in that approach, but infusing social functionality into the existing portal framework does provide the valuable personalization and filtering capabilities that are missing, or manually affected, in current ESS. It would be interesting to compare adoption rates over time of ESS and socially-enabled portals.

  18. Ellen: Thanks for sharing your thinking about what’s missing from the Delphi portal architecture that could be valuable. I absolutely agree that, if the model were being constructed today, reporting and analytics would be a key layer. ESS has begun to prove the value of including that functionality, particularly in the last year.

  19. Chris: The notion you surface that ESS can serve as a portal replacement is an interesting one, and I’m glad to hear that it is contributing to PBwork’s revenue growth. We’ve certainly seen supporting evidence in the area of corporate intranets, where some organizations have retired their aging, portal-based intranet with a more dynamic ESS environment.

    Your hosting comment is also interesting. As the portal market rapidly consolidated c. 2002-2003, many existing portal application vendors’ technologies became embedded in enterprise infrastructure, either their own or, more frequently, in that of an acquiring vendor. As a result, portal applications never really had much of a chance to be delivered as hosted apps, although there were some largely unsuccessful attempts to do so through the Application Service Provider market. So, yes, it will be a significant cost reduction for many organizations to replace their on-premise portal software with a hosted ESS offering.

  20. Pingback: Enterprise Social Software and Portals: A Brief Comparison of Deployment Patterns « Together, We Can!

  21. Delphi developer

    The portals is not an option novadays. People want an information sorted and prepaired to consumption.

    ==========
    http://developex.com/custom-development/custom-delphi-development.html

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s