How a Portal Factory Simplifies Development
In my previous article, "Reuse and the Portal Onion," you were introduced to the conceptual model of a portal onion that illustrates how a portal framework enables reuse of front-end web application assets across the user experience, portlet catalog, common services, and foundational architecture layers of the onion.
In this article, you will turn your attention to the foundation or core of the onion, as depicted in Figure 1, to study the portal development factory.
Figure 1: The Foundation or Core of the Portal Onion
The portal factory is a prescribed set of people, processes, and platforms through which front-end web application assets are created and reused across multiple user experiences. The portal factory simplifies development by following a common reference architecture and by leveraging a common portal farm that meets the performance, scalability, and availability needs of the hosted portal applications.
What Is a Software Factory?
If you are like many IT professionals, the notion of a software factory may be new to you. Simply stated, a software factory is an efficient and consistent process to build software components and assemble them into systems.
An area of software engineering related to factories is software product lines.1 A product line is a set of related systems that can be built from a set of common assets. You might set up a development factory for each product line.
In this case, B2B, B2C, and B2E web sites can be considered systems that are part of the same product line. A portal development factory prescribes the people, process, and platforms for efficiently creating front-end components and assembling them into these websites through use of a portal framework.
Does your organization have a variety of ways to build and maintain customer, partner, and employee websites? If so, there are multiple factories for assembling products in the same product line. This results in inefficiencies due to the redundant and inconsistent implementations of security, content management, application integration, information architecture, and other front-end components.
The benefits of using a single development factory for a given product line versus multiple perhaps ad hoc methods should be obvious, whether this factory is based on use of a portal framework or not. However, a portal framework will help speed the factory startup time due to its many out of the box components for integrating the architectural elements related to user experience.
The Three Ps: People, Process, and Platform
A software factory requires three Ps: the people to run it, the process by which systems are built, and the development and runtime platform to create, assemble, and run applications. Examine each of the three Ps of the portal factory.
The First P: The People
The first P in a software factory is the people. The use case diagram below represents key roles and responsibilities that are needed to run a portal factory.
Figure 2: Portal Factory Roles
Lead Portal Factory Roles
Beginning on the upper right, the User Experience Owner defines the overall user experience and governs the evolution of that experience over time. Essentially, the User Experience Owner determines the "what" or overall requirements for the portal applications assembled through the factory.
On the upper left of the diagram, the Portal Architect is responsible for defining the overall reference architecture for the portal. The Architect's job is to define the "how" or overall solution that meets the User Experience Owner's requirements.
Both the User Experience Owner and Portal Architect roles span the factory design and runtime environments to some degree.