Skip to main content

Digital Transformation

When to Use a Portal

I had a client ask me to give more advice on when to use a portal technology.  Obviously, a portal isn’t a fit for every single web site out there.  I typically look at four main categories:

  1. Content only or content heavy sites
  2. Mix of content and applications
  3. Some content and many applications
  4. stand-alone application

Of those, you should consider items two and three as almost slam dunks for portal use.  Item number one, content heavy could still be a portal site but you need to look at it closely.  Stand alone web applications typically work best as a custom developed web application.

As part of the process I defined a decision matrix for when to use a portal.  Here it is and I hope it’s useful for you.

Image defining a decision matrix for when to use a portal

Portal fits into a number of use cases. This decision matrix will help define the fit

Thoughts on “When to Use a Portal”

  1. Michael, This is wonderful, thank you for sharing . . . wish I had it down this clear and crisp way back when (aargh, seems as every day passes I know less and less!)
    Some of the teams I’ve been on, at the strategic stage, often wrestled with the “to portal or not to portal” . . . in addition to your four items, I find categories can also include personalization (system managed, and governance related) and customization (user managed) opportunities.
    As these opportunities become more essential to the business and the employee, there seemed to be a greater chance that a well designed portal with it’s relevant layers, would be a “yes, let’s do it” and a win.
    Portals, done right, seem lagging in our world, perhaps because they are political beasts in part, take time to concept, design and build (more so than apps), and require dedicated care thereafter (shouldn’t all software/hardware?).
    Those I’ve seen work are amazing, you can really live within them, and the “ROI” (both objective and subjective) is apparently quite remarkable. Examples are rarely public but I know include, e.g., LL Bean, Staples, HHMI, Genentech, Campbell’s Soup, NCR . . .
    Keep the wisdom coming Michael. Many kudos . . .

  2. Thanks Andrew. You are correct that things like personalization come into play. When I created this I almost threw in personalization decision point. However, most modern WCM’s provide some level of personalization so it’s a bit of a toss-up between WCM and Portal in that regard.

    Finally, I do agree with you regarding the ROI. It can be phenomenal but it all depends on how it was implemented.

  3. I have to say I disagree quite a bit.

    Been working with portals quite some time since the the early days in 2004 (Vignette Application Portal at that time).

    The major selling arguments were (and I guess still are) personalization and content aggregation.

    Even with personalization being implicit in your diagram:

    My personal experience is that portals didn’t (and maybe never will) play well with content management in general due to the fact that they are aware of pages, navigation and all sorts of other “presentation objects”. Some of these – at least navigation and pages are usually needed in CM context, and things tend to get messy when portals collide with the CMSs here.

    The fact that most successful portals may not be out in the wild may also be due to issues like SEO in CMS scenarios. SEO tends to interfere with personalization. Have to say I have not had a look at SEO functionality provided by recent portal versions, but I guess doubt it is quite far from what wordpress or other highly specialized systems offer.

  4. There are lots of opinions. I wrote a while ago about my opinion of content management in portal. Content is hard unless you use the oob content management system with the portal. In years past, even that was a bit of a disaster because the integration left something to be desired. However, more and more portals have decent content management tools. I won’t call them great because the CMS’ of today have evolved a lot as well.

    That said, I think they are better. If you just want personalization and content then a modern web content management tool may be a better choice. If you want personalization, content, and application, then I think a portal would work quite nicely.

    Regarding SEO and personalization, I spend less time thinking about SEO than almost everything else in the web world. However, don’t portals allow you to create a seed list that would function regardless of personalization. You would search on that and then get a better personalized experience once you hit the site.

  5. SEO imho is a major aspect of the content part if the content is meant to be public.

    Regarding the application functionality, there are (portlet) alternatives today – Open Social Gadgets for example.

  6. I don’t disagree that it’s important. Just keep in mind that SEO is only crucially important to one of a number of portals. That’s why I leave it to SEO experts to work with a site to optimize it. Anyway, consider the kinds of portals I’ve seen just this last year:
    1. Employee Portal (SEO irrelevant)
    2. Partner Portal (SEO irrelevant except for small set of content on public portion of site)
    3. Very specific customer application portal. For example, (SEO irrelevant except for public portions)
    4. Consumer portal like many consumer sites that drive traffic and business. (SEO highly relevant)

    I could name a bunch of other portal sites like member, broker, patient, physician, and other sites but they all just repeat the themes above. Again, I don’t dispute the importance of SEO in general. I just want to note that it’s not always important to a portal.

    Now onto the application side. Yes, there are lots of alternatives. Open Social Gadget is one of many. Adobe CQ5 even has a portlet container. Lots of other technologies support widgets or gadgets. What I’ve found is that portlets are more enterprise ready and support more enterprise concepts. If you need to deliver rock solid functionality that works every time and handle the a heavy load, then portlets provide a technology capability you should consider.

    So yes, choosing a portal is a bit of a fun decision. It’s not a perfect fit for all situations. It can provide a lot of value though. You just need to determine the value and the resulting costs for using a “heavier” tool like portal.

  7. The diagrams entry point is “New Site”. 😉

    The vast majority of websites is hypertext/content (and not application) driven.

    But even in a scenario where SEO is not an issue – and personalisation is highly relevant:

    Portals Java based nature also narrows down potential application. You may be lucky in case of a green field project or an existing “mostly” java based environment.

    The cost aspect surely depends on the product/software chosen (in general). But some portals (i.e. Websphere Portal) definitely has a very long code/deploy/test cycle.

    Still, I see valid use-cases for them. 😉

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Michael Porter

Mike Porter leads the Strategic Advisors team for Perficient. He has more than 21 years of experience helping organizations with technology and digital transformation, specifically around solving business problems related to CRM and data.

More from this Author

Follow Us