Tag Archives: enterprise

Enterprise RSS – the State of the Industry

There has been much talk over the last few days about Enterprise RSS, and whether it’s dead, still being born, or alive and well. Since I’ve got a pretty unique view into this particular industry, I thought I’d write some thoughts and try to give you a more clear picture of what’s really happening.

First, let me get this out of the way – RSS use in the enterprise is definitely alive and well. But it’s not in the obvious places. No one is writing articles talking about how their desktop feed readers are revolutionizing the way they do business. No one is talking about how they’re retiring their Exchange servers because so much content is delivered via RSS instead of email (and in fact, email is alive and well). No one is saying “if I only had Google Reader behind my firewall, I could save millions of dollars.” Few companies even say their users are clamoring for some sort of enterprise RSS application.

So if not all of that, then what?

My team and I, collectively, have detailed conversations with at least 50 different large companies every week, talking about the real problems they do want to solve. Many of these include 10 or more people on their side, ranging from IT folks to business owners with line-of-business responsibility. And these conversations rarely start with any mention of enterprise RSS. These include:

  • Portal enhancement. They want to pull additional content into their portal to make it more useful, or get content out of the portal to distribute in some other way. Or in many cases, they want to add personalized content capabilities to the portal. A while back, an analyst told me “this could be the technology that saves the corporate portal.” Indeed – that scenario is playing out today.
  • Alerting. There are many use cases where folks want to alert certain groups or individuals of a specific event. For example, we have a large bank that uses our system to deliver fraud alerts to teller desktops, replacing a legacy system that worked via fax and paper. Incredible efficiency gains and cost savings.
  • Competitive tracking. Or tracking any other external news for that matter – many companies wish to track media mentions and online conversations about themselves, their competitors, or anything else; once they have this information, then, they need to filter and distribute it appropriately. Increasingly, these systems are being used as a replacement for high-end premium content services. We have a large bank who reduced their premium content subscription expenses by over $1M per year by using our solutions – we’re talking about real savings here.
  • Knowledge capture. In large companies, mountains of information are created every day, in many different systems. If there is some way to collect all of this information, and surface it in appropriate places, the content’s value is multiplied.
  • Social networking. More and more, companies are investigating the idea of implementing social networking within the enterprise. The use cases for this are numerous; we have a large PR firm, for example, who uses this to manage their talent globally. A global advertising firm uses this technology to connect not only the people working on a specific account, but also others in the company who might have relevant experience or interests; it’s amazingly effective.
  • Collaboration. This is sort of a catch-all, I suppose…but it’s a popular use for this technology. For example, one of largest banks in the world is using our system to unify groups of people who are on different communication systems (due to acquisitions and such); their analysis indicates rolling this out will be much faster and cheaper than attempting to unify their email systems in 2009, and provide other benefits such as social connections.

For any of these specific problems, RSS forms the underlying plumbing to transfer content around the organization. And if you can track the user interactions with the content, using enterprise RSS infrastructure, very rich data is collected – and the combination of the content plus this interaction data forms the underlying foundation for a social computing solution. One that can even form relationships based on implicit behavior, rather than explicit actions.

An interesting tidbit – of the content recently added to NewsGator Online, 40% of it is content related to social computing (e.g. Twitter updates, Facebook feeds, etc.). In the enterprise, this percentage can be even higher in active social computing environments. But the point is, RSS (and associated enterprise infrastructure) is increasingly used as the basis for social networking and collaboration.

From a business perspective, momentum for all of this is accelerating dramatically. As Brad mentioned, NewsGator added over 30 paying enterprise customers in Q4 2008 – most of whom were large Fortune 2000 companies (there is some breakdown by industry in this press release). These enterprise installations (plus ongoing maintenance) represent about 75% of NewsGator’s revenue, the rest coming from our enterprise SaaS offerings. Enterprise RSS-related infrastructure, including social computing, is growing quickly in demand.

RSS in the enterprise is not about “reading feeds.” It’s more about enterprise integration, search, feedback, etc. It’s about extending the value of existing systems, and leveraging efficient content distribution and tracking into new applications (e.g. social computing) as well as existing applications (e.g. portal enhancement). It’s not about installing FeedDemon on every desktop to enable folks to read content.

And, thus, it’s hard to see from the outside. But it’s there, forever an enabler, making new things possible. It’s enterprise infrastructure. And it’s in more places than you probably think.

9 Comments

Enterprise RSS and security

Peter Verhoeven wrote an article a few days ago talking about security features he feels are missing from Enterprise RSS tools, including NewsGator Enterprise Server. I wanted to address his concerns directly, explaining exactly why NGES handles secure feeds the way it does, and talk about how specifically one could address the issue he brings up.

Public feeds

So first, let’s discuss the general case where no security is involved. If user A and user B both subscribe to publicly accessible feed X, the feed content is the same for both – so there exists only one copy of the feed in the system, and everyone sees that same copy and the contents therein. This is highly efficient for all systems involved.

Secure feeds

Now on to the slightly more complicated case. When NGES encounters a secure feed (more specifically, a feed which requires user credentials to access), it treats the content from the feed as secure. When user A retrieves feed Y using his credentials, the contents will be stored specific to user A. When user B retrieves the same feed Y but using her own credentials, the contents will be stored for user B. So now we essentially have two copies of the feed.

Why, Greg, why would you do this? It’s the same feed, so you should only store it once. Right?

As it turns out, the answer it no. The issue is that NGES has no way of knowing if feed Y will return the same content for every user that has access to it. Just because the feed URL is the same, doesn’t mean user A and user B will see the same thing when they retrieve it using their own credentials. So, the system stores the content separately.

“Shared” secure feeds

Ah, but now we get to the heart of Peter’s issue. He has a case where he _knows_ the content for a given feed will be the same for every user that has access to it. The problem is, Peter knows, but NGES has no way of knowing.

The only part of the system that could possibly know this is the publisher of the feed – because it’s the application generating the feed, and it knows whether it would generate the same feed for everyone that has access. But it’s a valid case – there are indeed situations where the publishing system knows this is the case.

So, in NGES 3.x, it will actually look for a specific header in the feed that basically says “this feed will be the same for everyone.” If it sees that header, it will still individually authorize access for every user trying to access the feed, but it will only retrieve and store the content once. So essentially, authentication and authorization works the same way – we are just making the behavioral assertion that the content in the feed may be shared among the group of people who have access.

[note: I’ve slightly simplified here, but this is very close to what is actually required.]

This code was initially written to optimize some of the content-retrieval that goes on with our SharePoint-integrated Social Sites Enterprise product…but there are definitely use cases for this feature beyond just SharePoint.

6 Comments