Take-out or Dine in? Considering The Future of the Enterprise Portal

I am participating on a team that’s looking at candidate software for the UW enterprise portal. The software that MyUW runs on was written in-house here, back before the term “portal” was even used in this context, and it makes little sense to pretend it is cost-effective for us to continue to develop our own code when there are other platforms that are widely used and supported, like Liferay and uPortal. There are also new needs for a web platform that allows easy integration of related applications, most pressingly in the area of research administration.

That being said, I keep wondering whether the concept of an enterprise web portal even makes sense anymore. We are at the beginning of a time where, instead of turning to monolithic portal sites that centralize information access and interaction, people increasingly consume information and applications in smaller bite-size pieces, distributed across multiple locations and devices. Individual gadgets show up now in Windows and Google, while Apple calls them Dashboard Widgets. These small “mini-applications” are characterized as being quick to develop and easy to deploy, making for low barriers to entry for information providers and consumers alike. Perhaps the best current examples of this trend are iPhone apps, which have grown to encompass apps for access to enterprise information as well as games and consumer interests. One notable trend is the bundling of specific pieces of content, like ebooks, as individual iPhone apps. People are selecting a variety of methods of interacting with different pieces of information, such as text messages on mobile phones, rss messages flowing into readers, and text-to-voice phone calls, in addition to traditional methods such as email or desktop web interfaces.

I can imagine a world where, for example, a UW grad student chooses to run the Course Registration App on her iPhone, gets SMS text message notifications of Husky volleyball and womens’ basketball scores, gets messages from her faculty through Facebook, receives notifications of grant opportunities on Twitter, and has access to her research data and apps for interacting with it via a web browser on her full-featured laptop.

It is at least conceivable, if not a foregone conclusion, that the future of enterprise portals lies more in the direction of a distribution hub instead of a single site where people interact with all of their information and applications. I think of this as being analogous to a take out counter as opposed to a full-service restaurant. Perhaps we should think of the Amazon or the iTunes App Store as the models for the portal of the future, where we can find the app or piece of content we need, see what the authors (or distributors) as well as other consumers have to say about it, and choose to download the appropriate version for the platform of choice.

Has anybody else been thinking along these lines?

11 thoughts on “Take-out or Dine in? Considering The Future of the Enterprise Portal”

  1. I agree. Perhaps we should view a UW portal as simply an aggregator of UW information, apps, etc. Sort of like the Apple app store for UW but not exactly: more general and stuff. I’m somewhat partial to not even hosting a portal as you touch on.

    Being on one of the evaluation teams, since it looks like we will be selecting a portal, it’s important to me that we don’t create or recommend implementation choices that are specific to our portal. It would be nice if “cross-platform” choices could be made by implementing web widgets as simply as possible. We’ve used the netvibes framework for some things which allows you to write once for google gadgets, Windows whatever they’re called, Mac dashboard widgets and others. I don’t think netvibes’ framework would necessarily be ideal, though (it wants you to proxy ajax requests through their servers 😦 ).

    Like

  2. Oren,

    I couldn’t agree more and my current employer is reevaluating its portal as well, and considering whether or not to have one. My previous employer never managed to find the resources to implement one and I think that turned out fine.

    A very nice feature of some university portals is the easy access for parents/students (in particular) to the suite of resources they need to “get stuff done”. What’s not clear to me at all is why a “portal” is needed to accomplish this.

    The overhead of maintaining a portal is pretty high, though, and the benefit to having one (to the extent that there is a benefit) goes way down quickly if it isn’t maintained well.

    Cheers,
    Cliff

    Like

  3. Yes, we’ve been having similar conversations. As an alternative, we thought about a single lightweight page with all the links to key services. If all the services are enabled by SSO, customers would have a pretty easy time using this like a portal. But it would avoid all the baggage and expense of a portal that may not be worthwhile to incur in the world that’s emerging.

    Like

  4. Oren, I think you’re absolutely on track here. Certainly what I want, as a new UW grad student, is for information to come to me through my well honed and carefully constructed information gathering tools. It’s jarring to have to adapt to the idea of visiting a Catalyst forum, or to resign myself to accepting a flood of emails updating me on various events. I’ve been used to funneling most everything through RSS and just giving up on anything that didn’t come to me that way.

    One growing problem I see is how individualized each person’s communication preferences have become. I have to have conversations with new team members along the lines of, “Do you use Google Docs? Do you prefer email, text messages, or IM? How do you want me to contact you?” The idea of a distribution hub which might just let me direct my message to an individual and let the system figure out how to distribute it based on that person’s preferences… that’d be damned useful.

    Like

  5. The thoughts expressed in your post and the follow up comments seem to be part of a theme I hear expressed more and more often. We are nearing the end of a re-visioning process for our portal and participants stated that not only did they want all their important information in the portal, they wanted to be able to consume it outside of the portal. I fully expect that the ability for users to consume information in a manner to their liking will continue to increase.

    I believe the campus portal continues to play an important role. Here at the University of Wisconsin-Madison, the other MyUW continues to be seen as a place applicants, students, faculty, and staff can go to for useful information. Offices and departments continue to make more applications available through the portal. The institutional portal already provides authentication, authorization, identity management, and security that is already understood and trusted by the community. Portal platforms like uPortal have focused on technology that helps integration with existing applications, reducing the need for those applications to develop another UI for these emerging devices/sites.

    Our portal today is indeed more of a hub then a final destination. We increasingly deploy dashboard-like portlets that show you a preview and invite you to launch the full application if needed. It will indeed be interesting to see how these paradigms shift over the next decade.

    Like

  6. Great comments!

    Perhaps we need to think of an enterprise portal as two or three different beasts:

    1. A place, as Cliff, Jim, and David suggest, where the links to the applications and information that people really need the most are grouped together. As they suggest, that doesn’t probably require a heavyweight “portal”, though it is nice to be able to take the knowledge we have of people’s relationship to the enterprise and present them with the proper set of links, based on their identity and roles. That’s pretty close to the vision we had for the original MyUW portal, and seems most allied to an enterprise content management sort of approach.

    2. A different (perhaps related) place where consumers can manage their means of interacting with various apps and information, much in the way Stuart alludes to. A distribution hub for routing your notifications and obtaining apps.

    3. There is the need for an application integration platform within specific lines of business to tie together their disparate applications into a coherent whole. This is what we hear most loudly now from the folks doing Research Administration, which is now a jumble of different applications, web sites, and information that need to be integrated to make it easier for UW researchers to manage their grants and applications.

    So I guess one question for us as we proceed with our “portal” software evaluation is to what extent the software we evaluate (where we’re really focused on category 3) can help with the other needs. Currently we plan to evaluate Liferay and uPortal, as they’ve got the most uptake within higher ed. Any opinions?

    Like

  7. This came via email from Scotty Logan:

    I think (hope) that traditional portals will be replaced by OpenSocial [http://opensocial.org/] containers and gadgets using OAuth [http://oauth.net/] for delegated access to services. I also expect there to be many OpenSocial containers on each campus, with users choosing the one that best meets their needs – so IT developers and Chemistry faculty may use different containers, but some of the same gadgets.

    Atlassian is making many of thie products OpenSocial containers; iGoogle appears to be container too. Traditional portal products could implement the OpenSocial container spec to make ease migration.

    Like

  8. This is the key: “increasingly consume information and applications in smaller bite-size pieces, distributed across multiple locations and devices.” We are in the process of moving to uPortal (supported by Unicon). I see our portal just as a single destination point, rather than having students try to remember all the different systems they need to access. I don’t see it as a “message delivery system.” It is a place to congregate – Grand Central Station – with paths to other systems. That has narrowed our portal development focus.

    Like

  9. If you’re lucky, the process of building a portal forces your organization to break all its information resources down into easily consumable representations.

    If you’re unlucky, you end up with another huge silo.

    In either case, the concept of a portal itself is fundamentally tied to a large desktop screen. That’s going to become increasingly irrelevant over the next 5 to 10 years.

    Like

    1. Excellent point! I’m increasingly thinking about an enterprise portal as being a place where you can manage how you want to consume the different pieces of information from differing sources – I want these kinds of notices forwarded to my email, but these should be delivered via texts to my phone, and these I’d like to see on Twitter.

      Like

Leave a comment