Portal Must Haves
State of the Art for Enterprise Portals
by Janus Boye
19-Mar-2007
Portal software technology has been around since 1998, and while portal implementations still often suffer from many shortcomings, the industry has also come a long way.
As our understanding of portal technology has evolved we've elaborated a set of common, sometimes decisive, portal scenarios that describe different business problems. These scenarios, however, range widely from the simple to the more complex.
While we favor scenario-based analysis, it still begs a question: can we
generalize more broadly about features and attributes that are universally
essential to successful portal projects? Have we learned enough to identify
a current "state of the art" in portal functionality across all
types of enterprise scenarios? I think so.
Beyond Scenarios
Many vendors call their products "enterprise portals," but our research finds that in reality, different tools do better and worse across these different scenarios -- and also vary substantially in complexity and cost. As such, scenarios are essential to help you focus on your concrete needs and project goals.
Nevertheless, portals are mature enough that we can start talking about baseline capabilities and practices. As part of my ongoing research with technology buyers for the new Portal Project Starter Kit, I've identified a set of features and attributes that any enterprise portal in 2007 should be able to boast. These range across the different services a portal offers, its technical aspects, as well as important vendor intangibles. Any portal project worth its salt will benefit.
State of the Art, Circa 2007
I'll divide state of the art into the same dimensions that we employ in our evaluation reports:
- Services
- Technology
- Intangibles
Every portal vendor will say that everything below is possible with their platform. That's because portals are, if nothing else, web application development platforms. Given enough time, money, and risk aversion, you can get them to behave almost any way you want.
The key thing is what a product wants to do natively. Each vendor with a mature offering should be able to provide these capabilities out of the box, without you having to customize the product first.
Portal Services
Generate short, meaningful, and permanent URLs
This is the web after all, even if the portal is running on your intranet. Good URL practices translate into better search results and ranking, easier use in printed media and e-mails, as well as fewer problems with broken links when technology changes. And technology always changes.
Replace select portal functionality with third-party services
You may want to plug in a third-party workflow provider or replace the incumbent search engine. You should be able to do this easily, without worrying about complex integration.
Natively provide lightweight collaboration services
Self-evidently useful for departmental project teams, simple collaboration should be included in any portal product. Collaboration tools cover a wide range of functionality, from discussion groups, wikis, project areas, and even the concept of presence.
Easily support arbitrary content and data models
This means your content and data can be organized according to your own requirements, effectively enabling you to leverage existing investments in information architecture.
Navigation controlled by business users
This removes developer bottlenecks and empowers the business folks to change the navigation as they see fit. Also, the portal should allow designers to break out of the simple document-directory-based navigation paradigm.
Search all of different content types within the portal repository
Just like using the popular Google search engine, your search should not be confined to a subset of content, but rather work across all the content that resides in the portal.
Integrate with third-party Single Sign-On solutions
Security, identity management, and ease of log-on are always important, but most organizations have already made significant investments in this area, with many having dedicated resources doing nothing else than managing user directories (e.g., Active Directory or LDAP). The portal should be able to leverage this, as well as any existing security infrastructure in place, while enabling the user to avoid logging in twice.
Technology
Application Server freedom
At some point you may decide to change the application server or middleware running underneath your portal. This change should not affect your portal. Refrain from writing proprietary or vendor-specific code and you should easily be able to switch platforms. This is particularly germane in the Java world.
IDE of choice
Developers can be a talented, but high maintenance participant in your portal project. Letting them use their favorite tool for development surely makes them more productive.
Fast installation
First impressions matter and this should be a good one. A fast installation accomplished in a couple of hours can help the project move along to the real work of helping the business.
Control configuration management and deployment
Moving code and configuration changes among different environments such as staging and production should be possible in a simple, controlled manner. An important detail here is that you can deploy changes and also roll-them back again, without having to deploy everything from scratch. Modifications made in one environment should not have to be redone in another environment, but rather a simple deployment should suffice, ideally without restarting the portal or appserver.
Easily expose application data
Without writing code, business users should be able to expose application data throughout the portal. This could be customer information leveraged by the sales team or inventory data used in the logistics department. Application data is valuable and a portal should provide a simple magnifying glass into the organization. (Of course, true application integration is another matter.)
Better than linear scaling
When you grow your portal installation you should be able to benefit from economies of scale, so that each added server or cluster member should provide synergies towards a faster user experience.
Intangibles
Community rating of portlets
All vendors and open source communities brag about the depth of available, 3rd-party portlets. Reusing and sharing components is already a great idea, but without community ratings it can be prohibitively difficult to assess the quality and usefulness of available portlet code.
Widely available community support
Whether formalized in a user group or using an informal network, community support is a fast and effective way to get answers to your questions. Moreover, location still matters. Local consultants that can support and guide you can make a decisive contribution to your implementation.
A Word About Standards
Vendors may say, "don't worry about URLs and communities, since our wonderful standards support guarantees your investment."
Sure, unlike most other adjacent technologies (such as content management), the portal marketplace boasts many relevant technology standards. However, I encourage you to look beyond industry standards and leave it to the vendors to fight about who has the best implementation of JSR 168, BPEL, EJB, SOAP, and so forth. Don't get me wrong -- these standards matter and are helpful -- but you should look at the market from a broader business and technical perspective.
Final Advice
I intentionally do not crown vendors for each area covered. Different vendors perform well in different areas. So instead of discussing vendors here, I encourage you to start your analysis by identifying which scenarios you need to cover, and then moving on to researching enterprise portal vendors.
Use "state of the art" as your baseline and revisit it regularly during implementation. Your portal might get a stamp of approval from the toughest judges of all -- your colleagues.
Good luck with your projects!