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.
Portal Design Time Environment Roles
The Portal Developer is responsible for creating front-end assets in the common services layer of the portal onion. These reusable front end assets include the security aspects of the portal applications, the content management and search integration, analytics, and other common services needed for consumer, partner, and employee websites.
The Portlet Developer is responsible for creating front-end assets in the portlet catalog layer of the portal onion including sales, service, billing, document viewer, work list, and content portlets. These portlets rely on the common services created by the Portal Developer and are created according to the architecture defined by the Portal Architect.
The User Experience Designer defines the content and creative design aspects of the portal, as well as the overall information architecture including the branding, look and feel, navigation, and layouts. These elements are part of the common services part of the onion, but manifest themselves in the user experience layer or skin of the onion.
Portal Run Time Environment Roles
The Portal Administrator‘s job is to configure portal assets into the desired user experience as determined by the User Experience Designer. In some portal implementations, for example iGoogle, the end user may actually perform this role by configuring their own user experience.
The Content Manager is responsible for creating and publishing the portal content. This is usually the most dynamic part of a website. As such, the Content Manager plays a critical role in the relevance and value of the website. As with the Portal Administrator, the end user also may perform this role to some extent; for example, the content in an Amazon product review is created by a customer, not an employee.
The Configuration Manager deploys portal assets across the testing and production environments. It is important for the Configuration Manager to ensure the quality of assets through a consistent deployment and change processes.
Finally, the Channel Manager‘s job is to monitor the user experience through web site analytics, and to influence the evolution of the user experience to meet user needs. To complete the circle, the Channel Manager provides key input to the User Experience Owner.
The Second P: The Process
The second P in a software factory is the consistent set of processes used to define, create, assemble, test, and maintain applications. Examine the Portal Governance, Software Development Lifecycle, Content Management Lifecycle, and User Experience Lifecycle processes within the portal factory.
Portal Governance is the process that guides the evolution of the portal over time. If you try to make the website everything to everyone, it will become difficult to use and inconsistent. Without a strong governance process and leadership, the website will devolve and end user productivity and satisfaction will diminish. The User Experience Owner and Portal Architect play important roles in the governance process by guiding what new features will be added and how they will be implemented.
The Software Development Lifecycle, or SDLC, is the process by which portal assets and applications are created, assembled, tested, and deployed. The development of new assets begins with governance approval.
Agile or waterfall methods may be used to create these assets. With a factory, it is not as important which process is used, but that a consistent process is followed. However, an agile process that delivers incremental functionality in weeks versus a waterfall process that delivers in months would be preferred to better respond to end user needs in an incremental fashion.
The Portal Developer, Portlet Developer, User Experience Designer, Portal Administrator, and Configuration Manager play key roles in the SDLC as assets are designed, built, and tested in the design time environment, and then configured and deployed in the run time environment.
The process by which content is authored, reviewed, approved, and published to the website is the Content Management Lifecycle, or CMLC. Whereas the SDLC may work in weeks or months, the CMLC needs to work in minutes or hours if needed. The Content Manager plays the primary role in supporting this process. The Portal Architect, Portal Developer, and Configuration Manager are responsible for the underlying content management architecture and environment supporting this lifecycle.
The User Experience Lifecycle, or UXLC, is no less important than the Portal Governance, Software Development, and Content Management Lifecycle. In fact, it intersects with all of these factory processes. Arguably, it is the most important process because the application, after all, is being created to meet certain end user goals and expectations.
The UXLC collects user feedback on a regular and consistent basis. This is a key input into the Governance process and assists with decision making. Usability testing is a component of the SDLC that ensures the defined end user goals are met by the software developed. Finally, the content being delivered in the CMLC is prioritized to meet the end user needs and expectations. The User Experience Designer and Channel Manager are the primary roles that support the UXLC.
The Third P: The Platform
The third P of the portal factory is the platform upon which assets are designed, created, assembled, and run. The portal factory platform encompasses both the design time and runtime tools and environments needed to support the factory people and processes.
The design time of the portal factory provides the tools and environments needed to support the Software Development and Content Management Lifecycle processes. Elements in the design time factory include: integrated development environment (IDE), configuration management tools, and testing environments. The front end assets to be reused and assembled into applications are an important part of the design time factory. These assets reside in the common services and portlet catalog layers of the onion.
The runtime environment of the portal factory provides the environment needed to meet the performance, availability, and scalability needs of the portal applications deployed to various user groups. This is another area where the factory provides efficiencies by creating a consistent runtime infrastructure that can be reused by many B2B, B2C, and B2E applications.
Summary
Organizations often have a variety of ways to build and maintain customer, partner, and employee websites. This results in inefficiencies due to the redundant and inconsistent implementations of security, content management, application integration, information architecture, and other front end components. Unfortunately, this also often results in a sub optimal user experience.
Software factories simplify development by defining the people, processes, and platforms to build systems that are in the same product line, such as web applications, from common assets. A portal development factory utilizes a portal framework to accelerate factory setup with its many out-of-the-box components for integrating the architectural elements related to user experience.
You examined the roles needed to staff a portal development factory, the processes these roles steward and participate in, as well as the design and runtime platforms used. The portal factory is at the core of the portal onion, and is the seed from which all the other layers grow and are sustained.
Does your organization have a standardized approach for creating websites? Are common people, processes, and platforms used? Has your organization adopted use of a portal framework, but failed to achieve the promise of a consistent and effective user experience, speed to market, and reuse? If so, you might consider defining a portal factory to consistently create, assemble, and deploy your front end applications. The rest is up to you!
References
- Software Engineering Institute, Software Product Lines
About the Author
 |
Jeff Ryan is an enterprise architect with twenty five years experience architecting and implementing thoughtful solutions to business problems. This article is Jeff’s 30th for Jupitermedia. Jeff has initiated software development factory efforts to address pain points and gain efficiencies using the concepts discussed in this article. Click here to browse Jeff’s catalog of articles on enterprise architecture, front end architecture, portal, SOA, Java, XML and XSLT. |
