Why Portal or Why Not Portal?
Service Oriented Architecture
One of the main reasons a consumer, partner, or employee will come to your website is to transact business. This might mean buying a product, servicing their account, or paying their bill. There may be multiple back-end systems that are the systems of record for the product, account, and billing information.
A portal framework provides the ability to create user interfaces that tie in to these back-end systems through a services layer. Additionally, the framework can utilize existing user interfaces, essentially treating them as services. Finally, you can create or acquire portal user interface components and reuse them in different portal contexts. Thus, a portal framework provides many ways to leverage existing assets and to expose business functionality to the end user.
Custom portlets may be created as the front end to business functionality. Back ends will be accessed through a common services layer, perhaps using web services. When this functionality is exposed through a portlet, it is possible for the portlet to be reused in many different contexts across your consumer, partner and employee user experiences. It is also possible to expose your custom portlet as a gadget or frame in a non portal application.
A portal framework also provides for the ability to use existing, non portal, web user interfaces. Through techniques such as frames or web clipping, existing user interfaces can be repurposed as portlets through the portal.
Finally, you may be using packaged business functionality from a vendor or open source provider which can be exposed through standard portlet APIs. In this case, these existing portlets can easily be integrated into your portal, within the information architecture suitable to your audience.
Another common element in many web applications is access to information in the form of dashboards, charts, and reports. This information is blended with the content and applications mentioned earlier.
Once again, the portal can become the front end for querying and consuming this information in a way that is relevant to the end user. The business intelligence functionality can be knitted in to the portal along with the other architectural elements, forming a unified whole.
Business Process Management
The last architectural element related to user experience you will look at is business process management. A portal framework provides the content, information, and applications needed at a given point in time for an end user to perform a specific task. However, there are other human to human, human to system, and system to human processes that need to be managed over a period of time. This is where business process management is needed.
Portal frameworks and business process management systems also can be knitted together so that business transactions seamlessly flow from customer to partner to employee.
Other Architecture Elements Related to User Experience
There are additional architecture elements related to user experience that have not been covered here. For example, collaboration architecture elements often are integrated into the overall experience including presence, chat, wiki, and blogs. Standard office tools such as email, calendars, and spreadsheets also can be integrated with the user experience. I've focused on the common elements across B2B, B2C, and B2E experiences in this article.
Why or Why Not Portal?
So now I must ask you, if you are creating a typical B2B, B2C, or B2E website, why not use a portal framework?
A commercial or open source portal framework knits together many of the architectural elements related to user experience that you take for granted, including security, information architecture, content management, search, service oriented architecture, business intelligence, and business process management. By choosing not to use a portal framework for your consumer, partner, or employee website, you are taking on the burden of implementing or integrating these architecture elements yourself. You would do better to focus on the content, applications, and information integrated into the portal because this is what differentiates your site and provides value to your customers, partners, and employees.
Use of a consistent portal framework will enable you to reuse many common components shared among your web applications. This includes the architecture elements mentioned previously, but also the content, applications, and information integrated into the portal. The portal framework also eliminates a lot of home grown code that needs to be designed, developed, tested, and maintained in favor of more robust commercial or open source implementations that are constantly being enhanced.
Utilizing a portal framework for the first time will require some additional effort. However, committing to use of a portal framework and governing its use will provide a better user experience and simplify your architecture over time by eliminating one-off implementations.
Although a portal framework is a good choice for most serious B2B, B2C, or B2E websites, there are some legitimate reasons to consider not using a portal framework. These reasons include:
- You are using a packaged application that already has knitted together many of the architecture elements related to user experience, such as security, content management, information architecture, and service oriented architecture.
- You are creating a pure content site that has no security component.
- You are creating a departmental application for a limited set of users.
I've found that many of my business and IT partners fail to understand the value of using a portal framework to create consumer, partner, and employee facing web applications. They often ask me "Why portal?"
When I explain the architectural elements related to the user experience of typical web applications they are familiar with, and how a portal knits them together, I will turn the question around and ask them "Why not portal?" That truly is the better question.
Do your consumer, partner, and employee web applications have a consistent and effective user experience? Are you effectively exposing business functionality, content, and information to multiple audiences? Do your web applications have consistent security, content management, search, and information architecture implementations? Has your organization adopted the use of a portal framework? Is use of the portal framework being governed so it is used consistently? If your answer is no to any of these questions, you might consider why you are not using a portal framework or using one to its full advantage. The rest is up to you!
About the Author
|Jeff Ryan is an enterprise architect with twenty-four years experience architecting and implementing thoughtful solutions to business problems. A number of years ago, Jeff created his own portal framework for a large B2B website, and later traded it in for a much more capable commercial offering. Click here to browse Jeff's catalog of articles on enterprise architecture, front end architecture, portal, SOA, Java, XML, and XSLT.|
Page 3 of 3