There are many, many different kinds of portals. The Merriam-Webster’s Online Dictionary contains five definitions for portal as a noun, ranging from a door to the entrance of a bridge and ending at “a site serving as a guide or point of entry to the World Wide Web.” This article (and the portal it is published on) is only concerned with web portals, and the readers of this article (should be) only concerned with two types of portals: portals that succeed and portals that fail. No one purposely goes out to build a portal that will fail, yet it happens time and time again. To understand some of the key reasons portals fail, it will probably help to know a little bit about how portals evolved to what they are today.
A Brief (Unofficial) History of Portals
Web portals began as a way to simplify the Internet for new users. Just as the word “portal” has evolved to encompass broader and richer meanings since its 14th century roots, the web portal has expanded in functionality and complexity. Many of the early portal successes were based on little more than a collection of categorized bookmarks and have expanded to become a network of sites almost as large as the early Internet they intended to simplify.
Portal technologies evolved, too. The first portals were simply very large and very well-designed web sites. The portal approach was rapidly adopted for intranets and extranets. Software companies were born with the (ironic) goal of making it easier for their customers to enter the arena of building portals. Then, the bigger software companies began to provide portal software as well. For a brief period, portals (other than the early successes open to everyone and continuing to grow) fell out of favor due to a lack of standards. As standards were established, the companies that made only portal products were bought by the software giants, moved to open source, or disappeared. Once the technologies were standardized, everyone had to have a portal (again).
Now that the technologies are standard and there are lots of successful portals to copy emulate, it should be easy to build a successful portal. In the immortal words of Wayne and Garth, “Not!” This leads to the key topic of this article: What not to do.
1. Designing from Back to Front
Part of the Wikipedia web portal entry says “It is designed to use distributed applications, different numbers and types of middleware and hardware to provide services from a number of different sources.” Depending on who reads this description, it could be interpreted to mean that portals are driven by the needs of backend services. If a backend service is a good candidate for a portal, it is either because it is hard to find, hard to use, or related to other services that have their own access points. Simply providing access to such services through a service does not make them usable or useful. If an application is added to a portal without thought to who will use it and how they want to use it, the user will either continue to use it the way he did before or not use it at all. By definition, a portal that is not used has failed.
Avoid this pitfall by designing your portal from the front end to the back. Most of changes necessary to build a usable portal can be done within the portal framework itself, and when making changes to backend services that don’t lend themselves well to being exposed in a portal appear to be the only way, it is generally a case where the service is not being used to its full potential because of this already.
2. Too Much Too Soon
The early portals that succeeded all share one common evolutionary path. They began with a small number (usually one) of services that were well designed and highly desirable to users. Many new portal projects start with the goal of aggregating everything from one common point of access. This may be a goal with a high probability of success if there is a binding theme to “everything,” such as the audience (customers, employees, vendors). Trying to go from zero to goal will generally lead to a crash. Contributing factors to this common failure strategy include poor site structure, user-vicious applications, performance issues, and manageability failures. It only takes one of these factors the make a portal a failure and a single release containing a large number of features will almost always lead to at least one of these issues.
There are indications that can tip you off before this becomes the death of your portal. Requirements take more than three meetings for a given topic. People joining the portal project mid-stream will find it difficult to understand the goals of the project or how things work. Developers will begin working long hours. Quality engineers will have difficulty defining test cases or test cases will not make sense to the development team.
3. Leaving Maintenance Planning for Post Production
Portal maintenance includes activities such as updating portlets, managing user access and entitlements, static content updates, integration testing, performance tuning, navigation enhancements, and dozens of other tasks. Because most portals are built on top of a portal framework, it is often thought that these things are magically managed out-of-the-box, or that it will be so simple that planning for these activities is a waste of time. These lines of reasoning lead straight to portals that are never used, or fall over when used by everyone who needs to, or are used furiously at first and then forgotten, or different people making the same changes multiple times or different people making conflicting changes or a few people burning out from overwork.
Portals are intended to simplify life for both users and IT. They can only fulfill these good intentions if they are planned for. Simple does not mean self-maintaining. Yet. During your planning stages, be sure to consider what will change, how often, by whom, and why? It is also important to avoid the “everything will change” trap and the “business (or IT) will manage everything” fallacies. One leads to a lot of extra work and complexity and the other leads to finger-pointing and disappointment.
4. Complexity for the Sake of Consistency
Many project plans correctly tackle the most complicated functionality early because they impose the most risk to the project. Complicated functionality often requires the use of complex design patterns to ensure extensibility, maintainability, and performance. It is also a common practice to enforce the use of consistent development approaches to improve time to market, reduce training, and avoid knowledge islands. All of these are important goals. Taken to the extreme, the pursuit of these goals will lead the portal in the exact opposite direction.
Complex solutions applied to simple functionality will result in exactly the opposite result of when they are applied where necessary. A maintenance developer has to learn the functionality of multiple classes and have deep experience to work on something that could have been contained in a single file. A new (simple) application takes three times as long (six times if you use TDD) to write and has more potential points of failure. Performance begins to degrade as the same amount of system resources are allocated on the server for a “Hello World” level portlet as an intricate BI data aggregation portlet. Solution patterns are meant to solve a particular problem and become an anti-pattern when applied to the wrong problem.
5. Random or Pure Agile Approaches
Many Agile practices are well suited for portal development. Some will cause the very problems that Agile methodologies are meant to solve. One such practice is that all developers work on all code. Although it is important that knowledge islands be avoided by making certain at least two developers can work on the same functional area, portals by nature contain features that are best owned by those who are specialized. A rich user experience is difficult (if not impossible) to achieve if every developer is expected to understand the presentation as much as the control. Really talented portlet developers often do not have the 5,000 foot view necessary to manage the placement and navigation of the portlets they develop. Writing test classes first makes perfect sense for isolated components but will lead either to useless test cases or very slow time to market if applied to every feature within a portal. Because of all the moving pieces in a portal, allowing any developer to run integration builds will lead to frequent build failures and delays while the cause is traced down. Having only a few people run the builds who understand how all the different pieces are supposed to interact and making sure that each developer communicates the needs of their work to these build masters will provide the productivity results that are one of the key goals of Agile methodologies.
6. Politics
If death and taxes are inevitable parts of life, bugs and politics are inevitable to software projects. Even though neither can be avoided, the impact of politics can be minimized by coming to a consensus of the portal goals and selecting a person or group to act as an unbiased party that will arbitrate conflicts and manage timelines.
7. Combining SOA and Portal Initiatives
Ask any of the current portal vendors and they will tell you that portals are the web presentation layer of a solid SOA strategy. Althoug this is absolutely true, it is no coincidence that vendors remind you of this constantly because most (if not all) portal software vendors also have SOA infrastructure applications. And, it is definitely an improvement to both SOA and portal ROI to take advantage of any bundling discounts this can lead to. But bundling the SOA and portal implementation as projects within your organization can spell disaster. Politics (mentioned earlier) will become involved. The constant communication of dependencies can lead to delays that will eat up the budget saved in the software bundling. There will be conflicting directives as the groups that manage the two technologies are rarely the same. The only way around the delays are compromises that will lead dissatisfaction to users, developers, managers, or all three.
The two technologies do compliment each other, and the important thing is to work at creating a synergy that gives the advantages and avoids the conflicts. The two groups should communicate their plans and needs to each other and develop with future integration in mind. Waiting for a service or expecting a service to be deployed to dovetail with portal release cycles can lead to delays and rushed re-work.
8. Misallocated Outsourcing
Most projects these days require some outsourcing for cost effectiveness. When outsourcing portal design and development tasks, the right mix will improve ROI and time to market. The wrong mix will achieve the opposite and then some. This mix will depend entirely on your individual organization and there is no simple solution, only some simple advice. If IT development needs to be done within a short period of time, either outsource all of it to one provider, bring in experts to work onsite with your team, or keep it in house. Once you have established a pattern of how your portlets are designed and integrated, you can start dividing the tasks, but not until then. If you outsource your UI design, make sure that the UI vendor has deep experience with the portal framework you are using. Finally, re-evaluate what to outsource and what to keep in house continuously as the portal and your needs evolve.
9. One Stop Shopping
Not all portal frameworks are equal. This isn’t to say any particular one is better than another (author’s opinion aside). What this means is that different frameworks provide different features or similar features in different ways. The decision to buy a portal framework is based on not wanting to have to deal with all of myriad pieces that are part of a portal individually. Trying to pick a framework that will do absolutely everything you need they way you need it is a good way to either lose time to market while evaluating, ROI on cost, or usability when all features are found but some number are poorly done. It makes sense (and saves dollars) to try to get the most in one place possible, so long as you remain flexible to consider integrating multiple pieces are creating some custom features to achieve all of your specific portal goals.
10. Looking Inward for Direction
The purpose of portals is to aggregate access to applications. Even though this will definitely (if done well) result in a ROI for IT, it all becomes meaningless if no one uses (or, if forced to, likes to use) using the applications from the portal. Even if the initial launch of the portal is a smashing success, losing touch with the users will simply lead to a delayed failure. Pushing out more and more applications without discussing with users what applications they need, how they want to be able to use them, and how they use them in combination with other applications will lead to a portal where the number of users (or satisfied users with a captive audience) will decrease with each release.
Avoid growing your portal into a deployed failure by actively soliciting user input, comment, suggestions, and requests. Most importantly, if they say something doesn’t work for them, remember that they are always right and the only solution is to find another way to satisfy them or seek out a different user base—whichever one doesn’t kill your portal project.
About the Author
Scott Nelson is a Senior Principal Portal Consultant with 12 years of experience designing, developing, and maintaining portals for manufacturing, pharmaceutical, financial services, and real estate companies for use by employees, customers, vendors, franchisees, and executive management.
