Q

When do I get to build my own portal application?

Before building out a new enterprise portal application, you should probably examine existing systems to make sure they don't need to be re-engineered.

How should an enterprise IT organization go about building a new corporate portal application?

Before building out a new enterprise portal application to connect existing systems, you should probably examine those systems to make sure the systems themselves don't need to be re-engineered. It's important that when you build out a corporate portal as a central location for enterprise employees to find the applications and data they need, that you're connecting workers with the right tools and information.

It wasn’t very long ago that enterprise information portals were all the rage. It wasn’t enough to just set up your corporate intranet; you needed a portal application to organize all the different information and applications that were available. Of course, that created a lot of noise because no single user needs to see everything, so the idea of “personalization” quickly worked its way into most enterprise portal discussions.

While this was going on, some big players were pouring a lot of resources into building out portal application standards (eg, JSR-168 and JSR-286) and the containers to support them. This was becoming a major piece of infrastructure. Meanwhile, the open source community, typically known for cutting through the Gordian Knot of bloatware, strangely followed the same path as their commercial counterparts. We didn’t get a better portal solution; just FOSS implementations of the same “standards.”

This is largely where we still are, and it’s the reason you don’t think information portals are sexy. Any portal application you use is probably a big clunky behemoth.

Giving users a central location to find applications and information seems like a good idea, so what went wrong? I can’t find anyone specific to blame. It’s kind of like Enterprise JavaBeans (EJBs); everyone talked them up, commercial and open source products sprung up, but in reality they were just giant headaches for most of us. I could also point out that both of these memes entered corporate IT departments from the top-down without much vetting from internal technologists.

Let’s get back to the premise here. Giving users an enterprise portal to organize their work seems like a good idea, but it might not be. There are some disadvantages to the typical “portal” metaphor.

  • Many apps (thick and thin) are not designed to operate within the relatively small confines of a portlet; they are designed to work full-screen. So app portlets either drastically scale down functionality, or serve as a gateway to the full version. This turns the portal application into a glorified navigation device.
  • You are locked into the consumption model of the framework (unless you are shoving iframes everywhere). Corporate portals dictate what information you can access. Even with personalization, you can only customize the experience within the guidelines set up by the portal engineers.
  • There are challenges delivering consistent performance levels as well as normalizing potentially different security models for the underlying content

I suppose I have to list some advantages. Single sign-on (SSO) and unified search are two of the biggest, but you can build these without portal software, so the extra cost and effort may not be worth it.

I think the real question here is not about building the right portal application; it is about creating a truly customized experience. What do users mean when they say they want a “customized experience?” The truth is that they really want an experience that doesn’t suck.

If you take an onerous order management system and stick it on a portal, it’s not going to make your users any happier. If you have an issue management system and you portlet-enable it, people aren’t suddenly going to love that it still takes two weeks to have their tickets closed.

Before you even begin to think about building some kind of “über-gateway,” take a look at your existing systems and processes. They need to be simplified down to the bare-bone. Users generally don’t want or need a new experience if the existing one already works. If something is broken now, then it will likely still be broken after the enterprise portal migration. Step One towards a useful solution is doing a little research. Are users upset because they can’t figure out how to perform a task, or is it because the existing process is just too confusing and/or slow to them?

It’s a huge jump from Step One to Step Two, because you might need to reorganize teams, streamline processes, establish new SLAs, etc. Essentially I am recommending you work on what’s broken before you build anything new. Once you have a collection of even a few quality assets, you can think about how to push them out to your community. You might think, “If a flawed system built these flawed products in the first place, then how do I get that same flawed system to correct these problems?” You have to think outside box. Maybe a different team can strategically re-engineer parts of your existing systems and create simple prototypes proving out their value. This kind of approach is very much in keeping with the “Lean Startup” philosophy.

The last job is to get these new assets out to the users. Remember that some of your enterprise applications simply won’t harmonize with the portlet metaphor. You might decide to start with that great-granddaddy of the portal: the site map. Users are certainly already familiar with bookmarking links they find useful – so perhaps an internal social bookmarking product is a better solution.

I’ve painted myself into a corner when it comes to one of the other potential advantage of portal applications – the ability for intra-portlet communication. If you have systems that can share information and you don’t automate this at the level of the portal container, the chances are that users will manually copy-and-paste information between applications. The instances where I have seen this handled successfully are so rare that I don’t think you should plan a strategic platform around it.

Another option to consider is an enterprise app store. Whether you build or buy one, an internal app store can have a few benefits. First, you deliver a level of personalization because users will only download the apps that they need. Second, if you follow Apple’s model and the store is curated, you can ensure certain usability and security standards.

I hope I’ve convinced you that the next time you hear talk about building a new portal, it’s probably a sign that something else needs to be fixed. Find out what information or functionality needs to be delivered better, and if possible, fix things at the source first before adding another layer of abstraction.

This was first published in June 2012

Dig deeper on Web services: Presentation, portals and clients

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close