Reuse and the Portal Onion
A colleague and I wanted to convey a message about how thoughtful reuse of front-end web application assets through use of a portal framework would improve user experience while reducing development and maintenance costs. We struggled at his whiteboard to show how applications and content were exposed to multiple user audiences with a set of common underlying services and infrastructure. Although we knew there was a compelling reuse story, we struggled with coming up with a simple way to convey this to executives, business partners, and IT staff.
One of the principles I follow as a front-end architect is to always begin with the end user and then work backwards toward the solution. I decided to put this principle into action and start peeling away the layers, beginning with what the end user sees. Through this "outside in" approach, I found that an onion was the simplest way to explain what portal reuse was all about.
Normally, when peeling the layers of the onion, you can't help but tear up. I promise I won't make you cry as you peel away the layers of the portal onion and examine how a portal framework enables thoughtful reuse of web application assets.
The Portal Onion
Please examine the four layers of the portal onion, as shown in Figure 1.
Figure 1: The Portal Onion
The four layers consist of the user experience, portlet catalog, common services, and foundation layers. I'll explain each of these layers in more detail in the following sections.
User Experience Layer
The outmost layer of the onion, what one appropriately calls the skin, is the user experience layer. This is where portal assets are configured into an optimal user experience for consumers, partners, and employees. The assets are organized and branded according to the needs of a given user audience. This layer is where user experience is optimized and reuse is realized.
Portlet Catalog Layer
Just below the surface, you'll find the second layer, which is called the portlet catalog. This is the layer that includes all of the applications and content available to be exposed to various user audiences as portlets. The portlet catalog provides a rich set of sales, service, billing, content, and other functionality that can be reused and configured across user experiences at the user experience layer. These portlets may be created by multiple teams within the organization. When new portlets are created, they are done so with an eye toward leveraging them across user experiences.
Common Services Layer
The third layer of the onion is the common services layer. This includes all of the underlying services that are required of the front-end portal applications. These services are integrated into the portal framework and reused for all front-end applications. These services include identity management, entitlements, content management, search, and information architecture services.
Finally, at the core of the onion, must be an overall architecture which is used to define, guide, and govern the creation of front-end web application assets through use of the portal framework, as well as a common infrastructure that provides the development and runtime environments for these assets. This is the seed from which all of the other layers grow.
Implications of the Onion
If you are thinking about reuse of front-end assets, and using or considering the use of a portal framework, there are many implications to consider. This time, you'll take an "inside out" view and work your way from the core of the onion back out.
First of all, you need a common architecture defined for all front-end applications, and a governance mechanism to ensure the architecture is followed. One way to encourage use of the architecture is to have a robust development environment (portal factory), and runtime environment (portal farm) available for use that can be shared by all development and support teams.
Second, on behalf of all development teams, you should develop the common set of services needed across all your front-end applications. There should be a common set of security, content management, search, and other services available for reuse. These may be developed opportunistically based upon the needs of key projects.
Third, you should think about documenting your portlet catalog so you know exactly what features are available to be reused, and which are being developed, and which will be developed in the future. Portlets, developed through the portal factory, should be created so they may be re-skinned and used in various contexts, supporting the needs of the different user audiences.
Finally, you should constantly look across user groups for any new functionality you are considering. This way, you can design these assets with reuse in mind from the start. It is rare for a particular function to be required by only a single audience; this is why there is so much opportunity for reuse in front-end web applications in the first place.
Reuse is the holy grail that many IT shops search for to reap the benefits of lower development and maintenance costs. When it comes to front-end web applications, a portal framework can enable assets to be reused across customer, employee, and partner websites.
The portal onion is a conceptual model that shows how a portal framework enables reuse across user experiences through a shared portlet catalog, common services, and foundational architecture. This is a simple model that can be understood by executives, business partners, and IT staff.