Lord of the Portals

May 1, 2009 at 10:11 am | Posted in Fun, Governance, portals | 2 Comments

I was speaking recently with a client who has three portals in house (IBM, SAP, and Microsoft) and was asking how normal that is and how to integrate them.  This is a very common question as well as very common combo of portals.

My advice continues to be the same.  It’s perfectly normal for a large organization to have several portal products around.  What is best (if possible) is to anoint one as the “enterprise portal” that acts as an umbrella above the others and then strictly define the roles of the other portals using governance.  This rationalizes the role of the other portals and makes sure people know where they should be posting and looking for information.  Certainly having a common search engine that can go across all the portals to find content is helpful, but you don’t want to use that as a crutch for lack of governance.  When you have multiple portals, integration is best handled by selecting separate, third party products for supporting services (e.g., web content management, collaboration rooms) if they will need to be exposed across all the portals, and use web services as an integration mechanism, although portal standards like WSRP may help.

After I got off the phone it clicked that this advice fit a very familiar pattern: it can be easily reworded to fit the inscription on the One Ring from Lord of the Rings! So here’s a link to the original, and here’s it is paraphrased as portal guidance:

One Portal to rule them all,
One Search Engine to find things,
One Statement of Governance to rationalize them all
and in the darkness integrate them using web services and emerging portal standards.

OK, so I’m not a poet.

geek^2, over and out.

Update: Instructional picture added below

portal governance lotr


Diagnosing Viability of Chargeback Models for Portals and SharePoint

April 24, 2009 at 9:56 am | Posted in business case, Intranet, Microsoft SharePoint, portals | 2 Comments

I just had a good conversation with a client about whether setting up a chargeback model for SharePoint would be a good idea for them and how to design it.  This is a common question that I blogged on over at the Collaboration and Content Strategies blog (see Do Chargebacks Work for SharePoint, Portals, and Collaboration?), but thought it could be useful to provide the set of questions I use to diagnose a portal chargeback situation and determine if it is the right path to take and how to design the model.  It’s probably useful to read that previous blog posting first to see where I’m coming from.

1. What’s the governance structure (e.g., federated I assume)? How many other sites using it?

  • Rationale: Validating that the organization fits the standard situation where there is a federated model where I’m talking to the central IT provider and there are many potential adopters of the enterprise portal. 

2. Rollout maturity: Where are they on the curve of network effect? How many other sites could potentially use it?

  • Rationale: Collaboration technology thrives on network (aka snowball) effect where the more people use it, the more valuable it is.  You don’t want to disincent usage. But once the portal is rolling and users are addicted, it may be possible to shift chargeback models from a tax to a utilization model to prevent abuse and provide a more fair sharing of the cost burden based on usage.

3. Pricing: Cheap? Subsidized?

  • Rationale: It can help adoption of the chargeback if not all cost recovery is addressed by the fees. For example, maybe 50% of the infrastructure is centrally funded and the other 50% is recovered through chargebacks.  This is not essential though.  100% recovery through chargebacks can help provide the business a clearer view of costs and value.

4. Competition/lockin: how easy for units to say you’re too expensive and use something else? policy or regulatory barriers?

  • Rationale: A common problem with chargebacks is that potential buyers start haggling with you or just go to a SaaS provider who is a few bucks cheaper. Then all information sharing and network effects go out the window. This works best when there are barriers to users going outside the centrally provided service.

5. Chargeback maturity: do other technologies use chargeback too? Is there a “tax” model that has been used”?

  • Rationale: If business units aren’t used to being told they have to pay a chargeback they may balk at the idea, even if it is a good one.  In an extreme case there may not even be an accounting/financial process where chargebacks can be implemented.  Same goes for “tax” -if you’re just one of many the business will understand your proposition much better.

That’s it.  From these 5 questions I can now tell a client whether they share characteristics of other organizations I’ve spoken with that have been successful or unsuccessful with chargebacks.  I can also determine whether it is better for them to do a usage or tax-based assessment.  And provide a few areas to beware of (and hence prepare for) as well.

On the Relationship Between Portals and Social Networking: Replace or Coexist?

March 20, 2009 at 8:49 am | Posted in portals, social software | Leave a comment

Burton Group recently announced the completion of a field research project to determine how organizations are approaching social networking (see Field Research Study: Social Networking Within the Enterprise). The interviews were only very lightly guided, so respondents got to guide the conversation where they wanted to go. It was telling that quite a few of them, when asked to talk about social networking, wanted to talk about portals. In fact, one third of the 29 organizations interviewed steered the conversation to portals at some point. This point occurred in one of two places: when talking about how social networking could bolster an existing, successful portal – or how it could replace a failed portal.

First, replacing a failed portal effort with social networking. Respondents in this category indicated they had failed in attempts to create a portal to address generic “knowledge management.” One idea is that perhaps social networking will offer a better route to KM than portals since it focuses on human interconnections rather than collecting data assets. For example, one organization said they had an “older KM Portal previously established, but information was hard to find and use,” so now they were interested in social networking.

In other cases, portals failed to get off the ground due to endless planning. One respondent indicated “They have not deployed yet after a year and a half of planning but are now looking to go to a collaboration platform”. Another organization had different internal constituencies (IT, corporate communications, and HR) come into conflict as they forced the portal in different directions. For this organization, the result has been a portal effort that has been stalled for over 3 years. We recommend time boxing portal implementations to be six to nine months (the longer time being for large enterprise deployments) to avoid analysis paralysis.

If a social network is being launched from the ruins of a portal effort, one has to seriously ask why the social network is expected to succeed when a portal failed. If the answer is that a focus on connecting people to people is really what the organization needed rather than connecting people to applications and content then you may be on the right track. But if the answer is that the new technology is better or more exciting, expect failure for the same reasons the portal failed: lack of business buy-in, poor or no governance, poor adoption resulting in a failure to reach a critical mass of users, analysis paralysis, and no business proposition for solving problems the users can recognize.

Now that I’ve discussed using social networking to replace a failed portal effort, I want to move on to the more cheerful subject of using them together. The path is clearer for organizations with successful portal efforts that want to add social networking in. Portals act as a personalized hub for applications, content, collaboration, and processes. This puts them in a unique position to reach people in a role-based manner who may want to interact in a social network. Through integration, social network sites can inject people and relationships into the portal interface. One interviewee explicitly mentioned that it “would be interesting to add people and relationships to the portal user interface and experience … to surface social networking in the portal.” Another mentioned they were interested in hanging community features off of their new, open source portal. This makes sense since portal infrastructure is often used today to create role-based portal sites. For example, one respondent had separate portals for employees, alumni, retirees, and a women’s network. By adding social networking technologies, these existing portals could become even more powerful mechanisms for connecting people with similar interests that may not come in casual contact during their workday.

Note that in this model the portal is not itself a social network, but it can work with the social network site. The SN site may have portlets or widgets that the portal can consume, APIs that custom-written portlets could access, or (worst case) screen scrape summary information the network site. The portal could also provide links to contextually relevant social network sites. The social networking site simultaneously exists as a destination for use when social networking is a primary activity and can point to information in the portal. In this way the portal and the social network site can each play to their strengths and make each other stronger and more successful. The portal provides the back-end integration (directory, single sign-on, implementation of portlet standards, portlets connecting to enterprise applications) and front-end presentation (in a personalized, screen real-estate metaphor) for building portal sites. However, the SN site is probably not built on the portal framework. The SN site provides the ability to define an online persona, list connections, receive notifications on the activities of those connections, participate in inter-personal, group, or community activities, and control social networking permission, preference, and privacy settings. It’s a great combination and one we expect to see more frequently.

Note: This is a cross-posting from the Collaboration and Content Strategies blog.

The Role of Communication, Collaboration, and Content Technology Investments during Tight Economic Conditions (part 3)

January 22, 2009 at 3:13 pm | Posted in collaboration, communication, Content Management, Economics, portals, Recession | Leave a comment

This is the third in a series on how organizations can frame and deal with the issue of constrained budgets due to the recession at the same time users are demanding productivity-enhancing technology for communication, collaboration, and content. 

In part 1 I set up the idea that companies that do best coming out of a recession are those that invest prudently while they are in one.  In part 2 I mentioned three approaches for meeting user needs with no ability to increase budgets: cost savings, cost avoidance, and “free” stuff.

In this part I will discuss the fourth approach which I’ll call “leveraging existing investments” or “doing more with what you have”.  I’ve given this approach an entry of its own because I think it’s the most useful – but overlooked – of the four approaches.

Doing More With What You Have

Communication, collaboration, and content management technologies have been around a long time – long enough for large organizations to have accumulated quite a portfolio of them. Many are going unused or underutilized.  An initial attempt at rolling them out may have been ill-planned, badly timed, or poorly messaged.  Or the champions or experts on that technology may have left the group, leaving no one to push them forward.  Now is the time to dust off these valuable assets and take a fresh look at how they could meet current user needs.

Not all existing assets can be scaled up without incurring substantial expense.  If new versions haven’t been licensed, playing catchup to get current may be expensive.  In other cases the product cost is mostly based on per-seat licensing, in which case scaling up the existing investment may still be cost prohibitive since costs will rise in near-linear fashion with users.  This applies to some high-end document management and web content management systems for example.  But other products, such as portals, are licensed on a per-CPU or per-server basis, which can allow for some economies of scale when upsizing the usage.  Portals are a good example since initial purchase and setup was often funded during better economic times but they may be underutilized today.  This is a good time to do a portal refresh and beef up parts that are working, fix or ditch parts that aren’t, find out information sources that aren’t on the portal but should be, and re-launch a freshened portal.

The best opportunity for leveraging existing investments is to utilize communication, collaboration, and content technology built into superplatforms that hasn’t been used.  SAP shops have access to a full suite of portal, content management, and collaboration technology in NetWeaver.  IBM Lotus Notes shops may be focusing on email and ignoring its collaborative capabilities.  Organizations with Windows Server have access to Windows SharePoint Services (the no cost part of the SharePoint portfolio).  Oracle’s application server still includes Oracle Portal.  Microsoft OCS 2007 includes instant messaging built in.  There are many examples where useful technology has been bundled in with something the enterprise is already using. 

It is still important to do due diligence in order to avoid winding up with a lot of technologies that were just installed because they were already paid for, but aren’t right for the organization.  But if the option is to wait until the recession is over to get painfully needed communication, collaboration, or content technology, leveraging existing investments should get some very close scrutiny.

Enterprise Portal Planning Process

January 20, 2009 at 1:36 pm | Posted in portals | Leave a comment

I recently had a request for my enterprise portal planning process, which I haven’t published in this blog before, so I’m including it here.

An enterprise portal is a form of website that marries a set of back-end integration and front-end delivery capabilities that provide information in context, personalized to a user’s role and needs. An enterprise portal (rather than just a single instance of a portal website) is meant as a set of infrastructure that will be leveraged by many portal websites that will subsequently created using the infrastructure (like cutting off cookies from a roll of refrigerated cookie dough!). 

Planning for an enterprise portal should include these steps:

  1. Determining organizational structure and sponsorship: initiating the portal Statement of Governance by identifying and obtaining buy-in from key sponsors, owners, and stakeholders in the enterprise portal
  2. Building the business case: examination of the drivers (e.g., improved productivity, reduced costs, employee retention) and how to satisfy them (i.e., phased release) as well as estimated costs and risks
  3. Inventorying desired features: definition and prioritization of all desired features
  4. Conducting an infrastructure impact assessment: investigation of current systems (e.g., ID management, directory, collaboration, content management, search, line of business applications) and how the portal will integrate with, synchronize with, or replace them
  5. Selecting products: analysis and review of products on the short list
  6. Implementation and rollout:completing the Statement of Governance, marketing internally to ensure adoption, establishing baselines and ongoing metrics, managing implementation of the portal system

There are lots of different ways of breaking up these tasks and new ones that may be required in certain situations so just consider this a starting point.  Also, there is lots of detail for each step, but this is a quickie summary of what I usually compare portal plans to in order to see if they are missing any important steps.

SharePoint: It’s Not a Gap, It’s Room for An Ecosystem

October 15, 2008 at 1:33 pm | Posted in collaboration, Content Management, Microsoft, Microsoft SharePoint, portals | 2 Comments

There’s an old coding joke: when presented with a bug in your program you try to pretend it is intentional by saying “It’s not a bug, it’s a feature!”  I’m reminded of that when told about the rich ecosystem Microsoft has nurtured around SharePoint 2007.  More information is coming out about the parts of SharePoint where a sophisticated enterprise has to look outside of what is in the box, such as our half day of sessions at Catalyst entitled “SharePoint: Fixing a Hole Where the Pain Gets In” or this article today in InternetNews.  And the more that information comes out, the more I think back to that old coding joke, except now it is Microsoft saying “It’s not a gap, it’s room for an ecosystem!”

Now, I am not saying that all gaps in SharePoint are mistakes.  Honestly, I don’t know how many of the gaps filled by the ecosystem are due to intentionally leaving some portions of SharePoint to communities, developers, and vendors and how many simply happened because Microsoft didn’t forsee common needs that it should have.  It’s probably some of both.  The best way to determine that for yourself is to look at the feature sets from the long and growing list of partners filling gaps in SharePoint (not just integrating, but filling gaps) and determine if those are niche needs that a vendor should correctly leave to the ecosystem or basic needs that should be included to fit the way the vendor advertises its product should be used.

Too many SharePoint implementations wind up causing pain because a promising demo or proof of concept led planners to underestimate the difficulty of the full solution.  The same implementation might have been considered a roaring success if time and resources were understood upfront and did not follow a winding path with multiple failures before completion.  If you’re in charge of an enterprise-wide SharePoint plan or a specific SharePoint site, you don’t care if a gap in SharePoint is intentional or not. The task for you is to quickly assess what users will need from SharePoint and to set expectations up front that SharePoint out of the box may not get them there.  Determining what combination of built-in SharePoint capabilities, partner products, community-provided bits, and custom in-house coding will be required to deliver the expectations of the users will help paint a realistic picture of the time and resources needed. 

To summarize, perhaps a cartoon (from our Catalyst track) will help:

SP Ecosystem

Note: This is a cross-posting from the Collaboration and Content Strategies blog.

Invitation To Join Portal Governance Benchmarking Survey

October 13, 2008 at 3:04 pm | Posted in Governance, portals | Leave a comment

The most common questions I get about enterprise portals are around portal governance.  And while I provide as much of an aggregated view as possible into what others are doing about portal governance (for example, check out my podcast on Understanding Web Governance), it’s been difficult to provide actual examples of what organizations are doing.  My discussions are confidential and companies rarely talk publicly about a topic that involves so much internal politics.

That’s why I was thrilled today to talk to Elaine Walsh at United Health Group, who is conducting a benchmarking survey about portal governance.  Participants all benefit by getting a copy of the final benchmarking report that abstracts out any specific company information.  If you’re interested, you can contact Elaine per the contact info below.

Here is the announcement:

United Health Group is conducting a benchmarking  survey on Portal Architecture Governance.  The standard benchmarking code-of-conduct will be followed and results will be shared, but blinded.  The survey has 30 questions covering organization, process and tools topics.

If you are interested in participating please contact Elaine_Walsh@uhc.com   (908-696-5090) or Aaron_gaalswyk@uhc.com  (952-931-5052) . We hope to have all survey responses by October 24, 2008.. Again, we will hide participants’ identities and companies  in the report, so no proprietary information about your company (or you)  will be divulged to any other party.

JSR 286 Grows Up

August 1, 2008 at 8:00 am | Posted in BEA, IBM, Oracle, portals, SAP | Leave a comment

A belated congratulations to the JSR 286 group, which went into final release in June. You can get the details here.  Good job to Stefan Hepper of IBM, the specification lead, who must have had a tough time herding the cats on this one.  Right out of the gate it’s good to see JSR 286 getting some attention from the portal vendors. 

Of course it’s been in development for quite some time.  When JSR 168 was being created a number of enhancements were shifted to JSR 286 to keep from slowing down the original portal spec’s ratification. The most important features of JSR 286 are inter-portlet communication (IPC) and alignment with the ongoing work on Web Services for Remote Portlets 2.0 (WSRP 2.0).

Vendor support has been promised soon as well (or is already here in the case of IBM). 

  • IBM quickly announced support in for WebSphere Portal 6.1 (as well as for WSRP 2.0).  Way to track the standards guys!
  • Oracle’s ALUI and Oracle Portal don’t have support yet.  I’m told Oracle Portal may get it in 11gR1 release or later
  • JBoss (Red Hat ditched its own portal in favor of the JBoss portal after acquiring JBoss) is promising support in Version 2.7, due out in Q3 2008 according to CMS Watch.
  • A document from someone at SAP coldly stated that “SAP supports and actively participates in this new standard as EG member. As this specification is in draft version, it is not supported in NW CE.”  I checked with my contacts at SAP and was told that JSR 286 is currently in scope for NetWeaver 7.0 Enhancement Pack 2, which is expected around October.  I also noticed they did not vote on the standard.  I wondered if this was a sign of lack of interest or a passive way to vote “no”, but their analyst relations staff said it was in fact because their committee representative was in the hospital. 

My guidance to portal architects though is to consider bypassing JSR 168 or 286 portlets and even WSRP and focus on creating web services for information that they want to expose.  Once the data portion is available as a web service, any decent portal product can create a quickie portlet (maybe in JSR 168 or some proprietary format) from the WSDL of the web service so it can be used in a portal.  And then you have the option of leveraging that interface through non-portal mechanisms as well.

I should mention JSR 301 here as well.  Presentation models have changed since the original JSR 168 specification was created. JavaServer Faces (JSF), the most significant of the presentation models for Java and has spawned many proprietary and open source attempts to transform JSF interfaces into JSR 168 portlets. The JSR 301 specification is only in its early stages, but promises to standardize these bridging mechanisms. No solid word yet on what that’s coming though.

Fusion Reaction: Oracle Fusion Middleware Gets Additional Nucleus from BEA

July 1, 2008 at 5:24 pm | Posted in BEA, Oracle, portals | Leave a comment

I got a chance to talk to Oracle yesterday about how they plan to integrate the BEA middleware assets they picked up in their acquisition into their own middleware portfolio.  Oracle let it be known that – no surprise – Oracle strategy is constant and BEA integrates into it.  Fusion Middleware is the brand and it’s all about Fusion in this integration strategy.  Dictionary.com defines fusion as “a nuclear reaction in which nuclei combine to form more massive nuclei with the simultaneous release of energy.”  That seems to be what is happening at Oracle these days as the nucleus of Oracle and the nucleus of BEA (which had already combined with the nucleus from Plumtree) combine to form something pretty massive.  And there is certainly a lot of energy being released, so that definition certainly applies. 

Still, Oracle assures BEA customers that all products continue under “existing BEA support lifetimes”, there’s no forced migration, and license costs are grandfathered for existing customers. In fact, some support costs may come down since Oracle policy is to price support as a percentage of net price rather than list, but others could increase or decrease a bit since Tuxedo’s pricing tiers get remapped to CPUs.

I won’t comment much on development since that isn’t my coverage area.  I will say that JDeveloper is still the flagship development platform for Oracle.  BEA Beehive is just in maintenance and Workshop is a freebie in the Eclipse Pack. 

And now, the answer to the portal conundrum I wrote about in my “Four Portals of the Apocalypse” posting when Oracle announced its intention to acquire BEA.  For portals, as expected, the winner is WebCenter.  It’s not that the others are dead, but WebCenter is the “hot” product they want to talk about first, connect everything to, and anoint with all the cool, buzzword-compliant enhancements.  Users of the other portals (Oracle Portal, BEA WebLogic Portal, AquaLogic User Interaction aka Plumtree) need to figure out how soon a rewrite is going to be in their future since those products are in the “continue and converge” category (C&C).  A C&C portal will keep going forward for existing customers for quite a while (Thomas Kurian publicly stated the lifecycle would be about 9 years), but will not have new customers steered towards it and will eventually be merged into WebCenter. 

So, here’s my recommended strategy based on which Oracle portal product you’re using based on what I know so far. I’ve been told that more detailed migration plans will probably come out in 2-3 months:

  • Oracle WebCenter: You lucky dog!  You picked the winner.  It’s a rosy future for you, full of the best piece parts from other portal products, new Enterprise 2.0 functionality, and you’ll meet lots of new friends at each annual WebCenter user’s group meeting.  For a new portal project being planned, WebCenter is the only reasonable choice in the Oracle portfolio unless you’re into planned obsolescence. 
  • Oracle Portal or BEA WebLogic Portal: You’re probably OK coasting along as is unless you fall into one of a few categories.  If you’re really thinking of adding the newest functionality (Enterprise 2.0) and architectural standards (REST, RIA) you’ll want to start thinking about migration soon, although Oracle intends to have some WebCenter services plug into WebLogic Portal, Oracle Portal, and ALUI to be leveragable without migrating.  And if you are in the rare situation of having a strategic portal with a long lifespan expected ahead of it (5+ years), you’ll have to make a reminder for yourself in 2010 or so to start thinking about migration. 
  • AquaLogic User Interaction: The picture for ALUI users is pretty similar to that of Oracle Portal and BEA WebLogic Portal – it’s in the C&C category so expect it to be supported for quite a while. Still, it’s my personal opinion that Oracle will have a harder time with ALUI since it will be chopped up into more pieces and there are lots of legacy installations with deep customization. Also, ALUI has a .NET side to its heritage. In the Plumtree days they had spent quite a bit of effort on building out .NET support. For example, the Enterprise Web Development Kit (EDK) could be installed with either a Java or .NET (C#) development and there was a .NET version of the EDK is available as a dynamic link library (DLL).  The .NET portlet creation capabilities are going to be rebranded as the Oracle WebCenter .Net Application Accelerator.

Oracle is rolling out a few new SKUs (packages) that will help portal owners. 

  • WebCenter Services combines the WebCenter Framework with some Oracle pieces (BPEL Worklist, their portlet bridge and JSR 168 container) and sprinkles some ALUI and WebLogic Portal pieces in.  Ensemble is renamed Oracle Ensemble and put into services SKU and Analytics gets Oracle branding. 
  • WebCenter Suite has everything in WebCenter services as well as restricted licenses for content, Oracle Presence, BPEL Process Manager, and search.  ALUI is renamed WebCenter Interaction and goes in the suite for now, although as of 11g there’s nothing in ALUI that they’d recommend for new deployments. AL Collaboration is renamed WebCenter Collaboration and goes in the suite until they can roll out new collaboration in WebCenter 11g.

I was a fan of the BEA Pages and Pathways products, both of which will melt into Fusion Middleware.  Pages melts into the WebCenter Framework. It will be part of WebCenter Composer for users to create mashups and its wiki and blog capabilities go into WebCenter Services in the 11g timeframe.  Pathways melts into two separate places.  Its social search merges into secure enterprise search and the social tagging merges into the 11g foundation.

All in all, this roadmap is pretty complete and as good as owners of Oracle Portal or BEA WebLogic Portal could have hoped for.  Owners of complex, customized ALUI portals need to see the writing on the wall and plan to migrate to the new WebCenter model (method TBD by Oracle) or re-architect off the Oracle platform entirely.  But one more telling statement about nuclear fusion may shed light on Oracle’s strategy of unifying all its pieces under the Fusion umbrella.  Wikipedia notes that “Artificial fusion in human enterprises has also been achieved, although not yet completely controlled.” Ah, yes, how true.  We still have to see how well this bit of fusion winds up being under control over the next few years.

Note: This is a cross-posting from the Collaboration and Content Strategies Blog

Back Home and Blogging Again

June 17, 2008 at 4:02 pm | Posted in Enterprise 2.0, portals, social software, virtual worlds | Leave a comment

It’s been a while since my last blog post as I’ve been kept running all over Europe lately doing speaking and visiting current and potential clients in Munich, Copenhagen, Vienna, and London.  My presentation on social computing for the Domino Notes Users Group in Bremen went fine except for my PC getting possessed and flipping slides around on me while presenting.


Now that I’m home I’m decompressing and reflecting on what I was hearing from the corporate and government organizations I talked to about collaboration and portals. 

  • I found a great deal of interest in social software, but the dozen or so organizations I spoke with seemed a bit further behind the U.S. in terms of awareness and piloting.
  • There was quite a bit of SharePoint work going on, but generally in a more controlled fashion than I’ve seen in the U.S.  SharePoint was being stripped down to fit into the rest of the environment, being used as just a web file store in one case and as a low-end content management system in another.  I prefer this approach to the whole-hog implementation that steps on the toes of other installed infrastructure that I see too often.
  • Portals were a hot topic, with most organizations I visited using them, sometimes many of them.  In fact, portal consolidation and governance is as big an issue as it was in my last few visits to Europe.
  • Enterprise virtual worlds came up twice, without much prompting from me.  One governmental agency was very interested in its use for rehearsal and disaster preparedness.

Now I’m off to work on the Mother of All Expense Reports.  

Munich Neues Rathaus

« Previous PageNext Page »

Create a free website or blog at WordPress.com.
Entries and comments feeds.