I’ve been thinking lately about the relationship between portals and other applications that they expose. I find it strange when people want to recreate a viable application in a portal. Just because it’s possible doesn’t make it a good idea. It’s amazing how pervasive this idea is.
Until now, I’ve always thought of a portal as the glue that connects an enterprise together. My view is now changing. I think a more proper definition is the entry point or map to the enterprise. Of course, new, custom applications can be built purely in a portal, but replacing existing, working applications with portal approximations must be considered carefully before being pursued.
This application recreation urge seems to originate from a general push in the industry that users have some desire to perform every interaction with a computer through one interface. It sounds like a good idea on the surface. What could be simpler?
I have to question the premise. Sometimes legacy applications work great just as they are. Often, extensive functionality has been built up over a number releases that can span years or even decades. There are lots of instances where examining two desktop applications at once is beneficial. If users really desired all computer interactions to be encompassed in one interface, why don’t they request the ability to do spreadsheet work in MS Word? Why is no one asking to Instant Message from iTunes? It is often useful to incorporate a piece of spreadsheet data (especially a chart) into a Word document, but duplicating Excel functionality in Word would be redundant and ridiculous.
Similarly, portals benefit by exposing some business application data and functionality, but complete duplication is often counterproductive. It may be nice to see your latest emails in a portlet, but often the form factor will be too small to be productive. When one considers the excellent web interfaces offered by leading email vendors like IBM Lotus and Microsoft, the validity of a stripped–down email portlet becomes even more questionable. It may be best for a portlet to alert the user that new emails have arrived or even message subjects, but, very often, linking off to a more capable application for more involved interaction with email is preferable.
In another example, I’m amazed at how often I see content administration portlets. Aside from avoiding licensing issues, I don’t really see the point. Is a content administration portlet going to be better than the dedicated tools that come with ECM systems? Alfresco’s content admin portlet is essentially the entire admin interface in a portlet form (which is certainly more useful than a limited, stripped-down portlet). Wouldn’t it be easier to implement a connection between the portal and desired functionality in the dedicated ECM tool, providing links where they make sense?
To this end, we could start viewing portals as the map to the enterprise. The portal could provide easy access to data and functionality that is otherwise hard to find. Existing applications shouldn’t be so much recreated as exposed. When more detail is desired, the limited view in the portal should give way to the fuller application (i.e. provide in-context links). The portal interface should be an overview application.
This leaves a problem. To provide a seamless and satisfying user experience, effective single-sign-on (SSO) needs to be in place. Very often SSO is created in ad-hoc fashion solving only the immediate problem, commonly creating an insecure result. Identity and Access Management (IAM) products exist, in part, to solve this problem. Conceptually, IAM can be considered the bridge for users between portals and the applications they expose, allowing authentication in one app to “count” in another.
Of course, single-sign-on is only one benefit of a centralized and cohesive IAM implementation. We’ll be exploring IAM and its benefits for portals and the enterprise more in upcoming posts.
I completely agree with your post. In the portal I work with, we typically link out to a new window so users can have a full screen to work with their applications.
Single sign-on definitely improves the user experience.
That’s not a bad solution. I usually tell clients to follow an 80/20 rule. Do the quick hit type of input, read, etc and then if you need to go deep and the application already exists, then use the application you already built.