Do I need a CMS or a Portal?
The line between each is a blurry one. Portals tend to offer CMS capabilities, in general, on par with all the features traditional content management systems do. The main differentiator between a "pure CMS" and a portal is adherence to the portlet specification, or allowing JSR 168-compliant portlets to be deployed within the container. So you see, a portal can have CMS capabilities, but not all CMSs are portals. Aside from this one dissimilarity, most CMS offer the same feature set as portals.

We will also say that we are cautious of traditional CMS that later cobble in support for the portlet specification. Having our own JBoss Nukes CMS, we can attest to the difficulties inherent in performing such a refactoring of the core architecture. Sure, it cost us in terms of time-to-market, but starting from scratch with a new portal architecture bought us endless flexibility and scalability. Cutting corners is not an option and we would be wary of any CMS-vendor-turned-portal-vendor for this reason.

Wouldn't retraining my staff to develop portlets nullify all economic gains compared to creating our own Web application with existing competencies?
If your developers are savvy enough to tackle SSO, personalization, internationalization, caching, clustering, etc.... and make it all accessible via servlets and JSPs, they are more than able to absorb all the technical knowledge found in the portlet specification in a short amount of time. After all, the portlet specification is extremely comparable to the servlet specification. The main differences between the specifications are:

• Portlets are not tied to specific URLS, making use of the API to create URLs that are parsed through the portal server and eventually execute within a specific portlet.
• Many instances of portlets can co-exist on any assigned page.
• Portlets leverage Portlet Modes and Window States, allowing for different content to be rendered depending on a user's desire.
• Portlet generate content fragments.
• Portlets are written to the javax.portlet package.

Is the portal JSR168 compliant? (Does it pass Sun's TCK?)
For reasons of portability and future maintenance, it would not be wise to develop to a proprietary API. The portlet specification continues to advance and knowledge-sharing by the community is extremely active. For these reasons, vendor lock-in should be avoided.

Are you considering open source or proprietary?
Open source and proprietary portals share essentially the same features currently, with one exception: some of the proprietary vendors supply smooth integration with other applications and systems they offer. For instance, a proprietary portal can be bundled with an existing CRM or e-commerce tools offered by the same company. If the need and budget exists to have a portal tightly integrated to other proprietary information systems, you should consider the proprietary offerings. On the other hand, we have seen a trend recently where businesses deploy open source portals and then custom develop the portlets that aggregate data from the proprietary systems in the back end. In many cases, the cost savings were immense, even when custom portlet development was outsourced to a third party as opposed to having paid the licensing and consulting costs from the proprietary vendors. In addition, a business may find the ROI acceptable for many more projects using an open source portal instead of an expensive proprietary portal. The open source portal will save a lot of developer time and reduce project risk because the presentation architecture is standards based and community tested where the in-house custom presentation infrastructure is not.

Does the portal vendor offer reliable support services for its products?
As with any piece of software, reliable support is extremely important. This is especially true with portals, as there is often a diverse set of components sitting under the hood managing a myriad of operations. Although some open source portals are backed by proven and professional support services, some of them will leave your development team at the mercy of a mailing list or a message board. Proprietary or not, you should ask who/what/when will be answering your support questions and only contract support from an organization with demonstrated high-quality support and customer satisfaction.

Conclusion
As you can see, there are many advantages to utilizing portal software. The essential decision that will take place will require evaluating whether a portal, CMS, or custom Web application is the path to proceed on. The case for the use of portal software is not cut and dry, but there are numerous advantages in adopting it like leveraging existing technology to perform the heavy lifting associated with Web application development, numerous open source and proprietary vendors backing their products with support services, and a shallow learning curve for JEE developers with regards to the portlet specification and existing MVC frameworks.