Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
As a front-end architect in a major financial services organization, a question I often hear from business partners, executives, project managers, business analysts, architects and developers alike is “Why do I need a portal framework to create my website?”
To answer this excellent question, I begin by discussing some business to consumer (B2C), business to employee (B2E), and business to business (B2B) websites that the questioner is familiar with. I like to describe the typical user experience of visiting the home page, registering, logging on, viewing personalized content, conducting searches, transacting business, setting preferences, and so forth.
Once the questioner has this context, I then explain all of the architectural elements that came into play to create that user experience. Usually, the questioner is surprised because many of the elements essential to creating that experience are taken for granted.
Then, I will explain how a portal framework knits together the architectural elements related to user experience. These architectural elements include security, information architecture, content management, search, service oriented architecture, business intelligence, and business process management.
Each time you create a consumer, partner, or employee website from scratch, you are reinventing the wheel and creating one offs in your implementation or integration of these architectural elements. Rather than spending your efforts on the unique value your website brings, that is, the functionality and content, you focus on re-creating foundational elements of user experience.
By this time in the conversation, I can turn the question around and ask, “Why not use a portal framework to create your website?”
In this article, imagine you’ve just asked me the question, “Why portal?” I’ll walk you through my answer and at the end turn the question around back to you and ask “Why not portal?”
A Typical B2C User Experience
You can begin by examining a business to consumer website that is typical of one you might regularly visit.
Figure 1: Typical Home Page for B2C Website
This is the home page for a wireless phone company. If you navigate to the site from a search engine, an email link, or by typing in the address, you would reach the company home page. If you already have a relationship with the company, you can register for use of the website. If you are not a customer, you can navigate through the site, explore content, search for items of interest, and consider establishing a relationship with the company.
Once you’ve become a customer, you may register for the site, log on, and view your account., This is depicted in Figure 2.
Figure 2: Typical “My Account” Page for B2C Website
At this point, your identity has been authenticated, and you are authorized to perform certain activities on the website to manage your account. The content you are displayed now becomes more targeted to you and your relationship with this company. You are allowed to set communication preferences that further customize your experience.
A Typical Implementation of Web Apps
The user experience you’ve just seen is typical of thousands of websites. To create such a website, these common elements of the user experience need to be implemented. Some elements such as security, content management, search, and the integration of business applications are not trivial. If you were to have a business to consumer, business to employee, and business to business website, it is likely that you may have three or more disparate implementations of these elements in your organization.
Figure 3 depicts one-off implementations of these architectural elements in multiple web applications, versus a consistent implementation through a commercial or open source portal framework.
Figure 3: Multiple Web Application Implementations versus a Portal Framework
Knitting Together the User Experience Architecture
A portal framework knits together the common architectural elements related to user experience. The framework may not implement these functions directly, but integrate other implementations.
You might obtain a portal framework from a commercial or open source provider. Then, you will focus on knitting your security, content management, search, business applications, business intelligence, and business process solutions into that framework in a consistent way.
Please examine these architectural elements in more detail.
Security
As with your B2C example for a wireless phone company, a portal website is often available for guests or potential customers. A login portlet is a common user interface component that allows an end user to register for access and to log in to the site. The login portlet would be configured to access an external identity store, or you might use an identity store that comes with the framework you are using.
Once a user is authenticated, entitlement rules would be configured in the portal framework to authorize the user to perform certain activities versus their account. As with the identity store, the entitlement rule implementation that comes with the portal may be used, or an external entitlement solution may be integrated. Entitlement rules are applied to different elements of the information architecture of the website, including navigation, pages, or portlets so that a user is only seeing the functions he is allowed to perform.
An end user might be allowed to maintain personal preferences for screen content and layouts, to set communication medium preferences, or even to assign delegates for processing transactions on their behalf. The portal framework provides a means to maintain personal preferences, and to configure the information architecture according to those preferences.
A portal framework provides a consistent way for knitting the security elements of authentication, authorization, and personalization into the user experience.
Information Architecture
A website must be designed in a way that allows users to find the needed information in a way that makes sense to them. A portal pulls together what may be disparately located content, information, and applications in a coherent way that allows users to discover and learn. A portal framework helps to structure the site and to create a suitable information architecture for the audience.
Portal frameworks provide tremendous flexibility in the area of information architecture. Audience-specific views of the same resources can be easily created and branded. The end user may even be given the capability to customize and configure his own information architecture.
End user analytics are an essential element to managing B2B, B2C, and B2E websites and are used to measure their effectiveness. If the information architecture needs to change based upon user feedback, the portal framework allows navigation, layouts, colors, content, and applications to be reconfigured very easily—perhaps even in real time through drag and drop functionality.
Content Management
A large portion of many websites is content. Because a lot of the value of the website is related to the content, it must be kept fresh, relevant, and targeted toward the end user. A content management system that allows the content to be frequently updated is an essential element of a consumer, partner, or employee website.
Portal frameworks come with a built-in content management system or can be easily knitted together to use a content management system from another open source or commercial provider. The portal framework makes it easy to consume the content from the provider, to skin the content, and expose it through different templates in the portal. It also may provide the user interface to update the content.
Content from external sources can also be woven into the user experience through syndication.
Search
The information architecture, content management, and search architecture elements are all related in that there is an overall business taxonomy that influences the design of the site and tagging of content to make it intuitive for the end user.
All content must be tagged with meta data to allow it to be viewed in various contexts. The way content is queried in content management and search is different, although the meta data used to query the content is the same.
When integrating content management into a portal, the query logic and parameters needed to retrieve the content are known at design time. This is used to bring up relevant content given the context of where the end user is in the website. With search, the query logic and parameters needed to retrieve the content are known at run time. The user is supplying the context for the information they are interested in. The same meta data allows content to be integrated into the portal and to be searched.
As with many of the other architectural elements related to user experience, a portal framework will come with its own search implementation, or provide the ability to knit together an external search provider into the overall user experience, perhaps with a search portlet.
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.
Portlets are pluggable user interface components that can be configured in the portal. Three types of portlets you might use include custom portlets, iframe portlets, or standard portlets.
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.
Business Intelligence
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.
Summary
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. |
