In the previous article, Creating a new portal, Part 1: Getting started we described the first steps teams would typically need to take when starting a new portal project. In this article, we describe an activity, called a portal workshop, in which all of the project's stakeholders come together to plan the portal. In this facilitated meeting, the team refines requirements, discusses how the portal's features map to the requirements, reviews or begins to define an architecture, identifies potential gaps in the to-be architecture, and discusses the interfaces between the portal and other systems.
A portal workshop runs between 3 days and 2 weeks; usually it is a focused and intensive 3-day session. The goals of the workshop are for all of the project stakeholders to identify and to agree on the high level aspects of the portal.
Limiting the workshop to just a few days is a good idea because:
- You need to make sure that the project's stakeholders are able to attend without interfering too much with their daily jobs. During the workshop, attendance by all of the project's stakeholders is critical to ensure success. Without their full participation and agreement, the resulting portal plans might not represent the entire team or it may lack required functionality, which ends up being identified and resolved later at greater cost.
- You can focus the energies of the stakeholders to arrive at decisions within a set amount of time. Parkinson's Law states, "work expands to fill the time available for completion". The 80/20 rule (which states that 20% of what you do will produce 80% of the results). Applying these principles to the portal workshop encourages you to create a short, well-defined workshop agenda, and the participants can spend their time productively.
To make sure that the workshop sticks to the agenda and runs as efficiently as possible, use a facilitator, whose role is to:
- Keep the workshop on schedule
- Make sure the workshop addresses the appropriate topics
- Make sure each topic receives the appropriate amount of attention and detail
- Involve the appropriate stakeholders in each session
- Guide the discussions and prevent any stray topics or tangents from interfering with the workshop's goals
- Provide demonstrations of the portal product or proofs of technologies to help clarify portal functionality (if possible)
- Provide portal best practices
- Help the stakeholders get to consensus on conflicting requirements or functionality
A portal consultant with deep technical skills in WebSphere Portal is often asked to perform the facilitator's role.
Table 1 shows an example schedule of a workshop.
|Day 1||8:00 am - 9:30 am||90||Introductions and review requirements|
|9:30 am - 9:45 am||15||Break|
|9:45 am - 10:45 am||60||Identify portal features|
|10:45 am - 12:00 pm||75||Map features to requirements|
|12:00 pm - 12:30 pm||30||Lunch|
|12:30 pm - 1:00 pm||30||Finish mapping features to requirements|
|1:00 pm - 3:00 pm||120||Define integration scenarios|
|3:00 pm - 3:15 pm||15||Break|
|3:15 pm - 5:00 pm||15||Review architecture needs|
|Day 2||8:00 am - 8:15 am||15||Review agenda|
|8:15 am - 10:15 am||15||Basic topologies|
|10:15 am - 10:30 am||15||Break|
|10:30 am - 12:00 pm||90||Define environments|
|12:00 pm - 12:30 pm||30||Lunch|
|12:30 pm - 1:30 pm||60||Define security and LDAP needs|
|1:30 pm - 2:30 pm||60||Size hardware requirements|
|2:30 pm - 2:45 pm||15||Break|
|2:45 pm - 4:00 pm||75||Lay out general development scenarios|
|Day 3||8:00 a.m - 8:15 a.m.||15||Review agenda|
|8:15 am - 10:15 am||120||Discuss migration|
|10:15 am - 10:30 am||15||Break|
|10:30 am - 12:00 pm||90||Discuss content and search|
|12:00 pm - 1:00 pm||60||Lunch|
|1:00 pm - 2:30 pm||90||Consider additional components|
|2:30 pm - 2:45 pm||15||Break|
|2:45 pm - 4:00 pm||75||WebSphere Portal catalog|
|4:00 pm - 5:00 pm||15||Wrap up workshop|
So, to summarize, the portal workshop:
- Is meant to quickly help your team develop a portal strategy, including identifying and agreeing on high-level requirements.
- Provides a forum to identify a common set of building blocks for use by the initial and future releases.
- Needs to include active participation of all stakeholders to gain the proper "buy-in" of each organization for a successful portal project.
While we won't cover every aspect of a workshop in this article, you can get a good idea of what a typical workshop includes, you might discover gaps in your current portal plan that need to be discussed before you move too far ahead. For more information on IBM conducted portal workshop and jumpstart offerings see LINK to SERVICES page on dW WS, and NEED LINK FOR Global Services.
Getting ready for the workshop
Before the workshop, you should create an initial set of requirements (both functional and non-functional), design constraints, and specify the scope of those requirements. See Creating a new portal, Part 1: Getting started for help on gathering these workshop inputs.
Regardless of your methodology, requirements are a very important aspect to any portal. By capturing and classifying requirements early in the project you have a guide for the portal. The prioritization of the requirements indicates when specific functionality will be available and in which portal release. Like any software project, portal project requirements are used to generate test cases, to perform validation and verification tasks (â€œdid we build the right thing and was the thing built correctly"), and as part of customer acceptance testing. In short, requirements are critical to insuring the success of the project. Numerous texts on the subjects of requirements analysis and requirements management state that the earlier errors and issues are identified and resolved, the lower the cost to resolve them.
Let's review what we introduced in Part 1. What types of requirements are useful for portal projects? A portal project is no different than any other software project in that you need to define functional requirements, non-functional requirements, and any design constraints imposed by the customer. Functional requirements describe what the portal will do. Non-functional requirements describe the attributes of the portal system. Design constraints indicate anything unique in a customer environment to which the portal will need to conform.
Some common examples of functional requirements that we have seen with our customers include:
- "The portal must provide the current date and the company's current
stock price on each page."
Or perhaps it should be provided on the home page in the form of a stock portlet.
- "The portal must allow the end user to customize the view of the portal to that user's preferences."
- "The portal must show the end user personalized content based on that user's registered profile."
Some common examples of non-functional requirements include:
- "The portal must be available to all users from 7 am to 7 pm GMT."
- "The portal must be available 99.999%." More on this topic later!
- "The portal must respond to any user interaction within 7 seconds."
We typically classify the non-functional requirements into several categories:
- Performance - measures throughput and response times
- Scalability - measures the number of users and quantity of data that the system can handle
- Availability - measures the system' up-time, and includes high-availability and disaster recovery
- Maintainability - measures the flexibility of the system
- Security - measures the adherence to security protocols and mechanisms
- Manageability - represents how the system will be managed
- Usability - measures characteristics of the portal's user interface
- Accessibility - measures the compatibility of the portal to assistive technologies OR measures the adherence of the portal to assistive standards
- Data integrity - represents data retention policies and other data lifecycles responsibilities
Closely related to the non-functional requirements are the design constraints. We separate out the design constraints from the non-functional requirements because they can vary widely, depending upon the customer's environment. Some examples of design constraints include:
- "The portal must use a specific vendor's database system for the storage of data."
- "The portal must run on the AIX 5.2L operating system."
- "The portal must conform to the company's IT corporate standards for application development."
During the first morning of the workshop, the participants review the requirements that were collected beforehand; this session is a "review and refinement" activity. Alternatively, if the requirements, design constraints, and scope of the requirements have not yet been defined at this point, the workshop must take on a different course. Customers who are new to WebSphere Portal are often not aware of what is needed to design and build a portal. In this case, the workshop can be used to flush out these requirements and constraints, and to help the entire team understand the issues surrounding a portal project.
Assuming you have collected requirements ahead of time, during the workshop you refine any that require refining, and then you map them to the portal's features. (See Reviewing requirements for more on "reviewing" and "refining" requirements.) In order to do these exercises efficiently, and to help the overall project, use some sort of system to contain and manage the requirements. Many companies typically have a requirements repository or management system. If you do not, at least store and manage the requirements in such a way that anyone needing the requirements can gain access to them and view them. We have even seen customers manage all their requirements in spreadsheets and use CVS for version control. So, whatever your mechanism or system for storing and managing requirements, we recommend that you at least have one.
Now that you know what your requirements are, you have classified them (functional, non-functional, and design constraints), and you have a place to store and manage them, let's jump into the first day of the workshop.
During the first day of the portal workshop the team sets the foundation for the rest of the workshop. This foundation is composed of reviewing the requirements, identifying portal features, looking at what systems the portal needs to integrate, and determining the architectural needs of the portal.
Before jumping directly into the requirements review, there are some standard meeting rules that the facilitator must administer. The first of these is introductions. Depending upon the size of the company implementing the portal, this workshop could be the first time that many of the stakeholders are meeting face-to-face. After the introductions, the facilitator goes over the administrative rules of the workshop, such as how long an off-topic discussion can occur, the process for speaking or asking questions, capturing parking-lot issues (topics which are not on the agenda but are still important, and the team wants to revisit later), duration of lunch and break periods. Finally, the facilitator reviews the agenda with the team and starts the first topic.
Before we discuss the activities associated with the review and refinement of requirements, let's address "why" you need to do this. After all, you have already created the requirements, categorized them, and placed them into your requirements management system; why do you need to discuss them again in the portal workshop? The simple answer is that by reviewing and refining the requirements, and defining the scope (or prioritization if you think in terms of releases), you ensure that all stakeholders are thinking of the same functionality for the portal for the remainder of the workshop (and beyond).
These activities provide an opportunity for all stakeholders to ensure that their specific requirements have been aggregated into the holistic set of portal requirements, and that there are no remaining gaps or issues that need to be addressed. On some of our customer engagements, we have observed that the stakeholders can read the requirements and not have any questions or issues. However, when each requirement is reviewed during the workshop by the stakeholder who submitted it, then the intent of the requirement can inspire a lot of discussion. Sometimes other stakeholders realize that their requirements are duplicates of others and can be withdrawn.
You can see from this discussion of why the team needs to refine and review requirements that we have inadvertently defined what we mean by review and refine. To summarize, the review portion is simply going through each requirement to resolve any issues with it. Issues might include the scoping, prioritization, or ambiguity of the requirement. The refinement portion comes about when the team re-words, re-classifies, or removes a requirement, or decides to add a new requirement (which then needs to be classified and prioritized).
Depending upon time and the number of requirements, the facilitator can review each requirement individually, have the person who submitted the requirement speak about their requirement, or simply address specific requirements that are under question. After all requirements have been reviewed and possibly refined, the next activity is to discuss portal features.
Identifying portal features
Portal features are those capabilities of the portal that the team members want to see in their portal. Examples of features include the portal's overall appearance, navigation capabilities, the look and feel of portlets (other portal products might call them gadgets or widgets), and layouts. Features also include functional and non-functional aspects such as single sign-on (SSO), security, web clipping, and the credential vault. Identifying and listing features includes those features which the specific portal product offers as well as those features which the customer would like to see as part of their portal.
For example, WebSphere Portal offers a credential vault, which portlets can use to store credentials for programmatically accessing other systems on behalf the user. Using the credential vault alleviates the user from being challenged for authentication to each separate system from which the portal aggregates data. This is a form of back-end single sign-on (SSO) which you can use with many different systems (for example, PeopleSoft).
You might have one or more requirements which specify that SSO is a capability required in the portal. However, the requirement(s) will most likely not specify that the portal should use a credential vault versus another solution such as Tivoli Access Manager. Determining the implementation components is the domain of the architect who can use one or more of the available technologies to satisfy the requirement(s). For more on this topic, see Mapping features to requirements.
The facilitator needs to keep this session on track. It is easy to get caught up in discussions about how the different features will map to the requirements, instead of identifying what the desired features should be. The way in which the different features will satisfy the requirements is part of the next activity, Mapping features to requirements.
Mapping features to requirements
Mapping the features of a portal to the requirements is probably one of the more enjoyable aspects of the workshop. Most of the customers we have worked with enjoy this part the most because the stakeholders can get a firm grasp of how and to what degree their requirements will be satisfied.
In the previous section, in which the team identified portal features, the facilitator will have listed the out-of-the-box features of the specified portal technology, and added any features that the stakeholders identified. During the mapping process, the facilitator helps the stakeholders walk through each of the features and map it to one or more requirements which the feature might satisfy.
For example, a team planning to use WebSphere Portal might consider:
- Does the Bookmarks portlet fill your needs for creating a list of Web links for your users?
- Can Web Clipping or the Web Page portlet be used to include an existing site that you won't be able to migrated for awhile?
- How can we create a set of tabs and pages to provide the navigation, or access control, which different groups of users require?
- How should custom portlets be designed to be useful in several places for different groups users, involving a minimal amount of administration effort?
Even though this exercise might sound trivial or feel like work that one or two individuals could do on their own, this activity is very important to do with all the stakeholders in an open forum.
Stakeholders need to:
- Identify and discuss which out-of-the-box features are important to them.
- Identify and discuss additional features that are important to them so that cross-organizational features are identified and prioritized.
- Identify how and to what degree their requirements will be satisfied.
- Identify any gaps in functionality or requirements that should be addressed quickly.
After you have completed the mapping, the next step is to consider scenarios in which the portal needs to integrate with other existing systems, or with other systems being built. The team usually discusses what custom functionality needs to be built to handle any gaps that are likely to occur.
Defining integration scenarios
The concept of a portal is to act as an information aggregator for its end users. The portal can access disparate systems, aggregate content and data, and then present it to the end user with one common look-and-feel. Information aggregation is the key value that this part of the workshop brings to the overall development of the customer's portal.
With the facilitator helping to guide the stakeholders, slowly all of the customer's systems with which the portal will interact are identified. Stakeholders often need to bring in technical resources to identify systems that are part of particular business processes. The purpose of this activity is to identify those systems with which the portal needs to interact and how the portal might interact them. However, this should not be considered a technical design session in which the portal's interface to each back-end system is designed and documented. The interface contract between the portal and each system is designed and documented during the design phase of your methodology.
There are two outcomes from this activity:
- A system context diagram (for example, Figure 1) that shows the portal in context with the other systems.
- A mapping of the requirements to the identified systems to ensure that the portal will not have any functional gaps.
Let's walk through a very quick example to see what this session may produce. In our example, a portal for a local cellular phone provider, which would like a self-service portal to enable its end users to:
- Review their past and present billing information
- Add new features and services to their account
- Add additional phones to their service
- See their phone product information
- Browse for a new phone
- See the latest information about the company
Now, in the real world, the customer's portal would do much more than this, but for the sake of simplicity, we will just consider these six requirements.
During the session, we discover that these six requirements are covered today by three disparate systems:
- One system covers the financial aspects of the customer's account and addresses the first two requirements.
- The second system covers the products offered by the company and addresses requirements 2-5.
- The third system is a content management system that provides the company information.
Together these systems and requirements form the integration scenarios which the portal needs to address to provide a unified view to the end user. You can diagram this scenario using a system context diagram, such as the one in Figure 1.
Figure 1. Example system context diagram
The diagram in Figure 1 is an over-simplification of the system context diagram. However, the diagram is able to convey the value of this activity. It also acts as a logical segue into the next session, Reviewing architectural needs.
Reviewing architectural needs
After the team has reviewed and refined the requirements, identified and mapped the portal features to the requirements, and identified the integration scenarios, the next step is to investigate the architectural needs of the portal.
In our experience, each client has a different architectural environment in which they operate. There are also many abstracted commonalities as defined by general IT standards, such as network firewalls and security. However, even with the commonalities, the number of different permutations of architectural environments is vast.
So this leads us to what we term architectural needs. What are the architectural needs of the customer? What environment must the portal work with? What are the corporate architecture standards of the customer? To take this one step further, the portal will have its own architectural needs that the environment must supply in order for the portal to operate. Discussing these topics helps to set the foundation for the remaining two days of the workshop.
As was necessary in the previous sessions, the stakeholders need to involve their IT department in this session because it is the IT department who has intimate knowledge of the rules and existing architecture.
Now let's discuss why this session is necessary. To use an analogy, if you did not have this session, it would be like building a house without considering the environment in which you are building the house.
- What are the local, state, and federal regulations that need to be heeded?
- What kind of soil will the house be built on?
- Is it pure rock?
- Is it on sand?
- Is it on an island in the middle of the ocean?
- How close will you build your house to your neighbors' house?
- What about water and sanitation?
If we relate this to the portal, we need to know:
- What are the IT standards?
- What kinds of operating systems can you use to implement the portal?
- What zones are available to place the portal?
- How close is the portal's zone to other system's zones?
- What network protocols does the portal need to work with?
The final outcome of this session is a list of documentation detailing your architectural standards (such as network, security, accessibility, and manageability) and the different architectural environments available;in other words:everything needed to identify the characteristics of the portal's operating environment.
After a full day of learning about the portal and mapping the features and functionality to your project requirements, it is time to look more closely at the infrastructure that will support your portal. Day 2 is designed to do just that. It is never too early to start looking at your non-functional requirements and to understand some of the basic topologies that your infrastructure might follow.The team needs to discuss integration with existing enterprise systems, such as LDAP and your database infrastructure. These systems are usually defined in the corporate architecture discussion on Day 1.
By this point in the project the organization often has an idea of the topology for their production environment. However, if you are new to IBM WebSphere Application Server or WebSphere Portal infrastructures, you have a lot to learn. A complete overview of portal topologies is a complex topic; we will cover the basics here. In many cases the discussion will be about the layers within the infrastructure. You must ensure that each layer can scale as user load increases, and that each layer allows for continuous availability with failover, if necessary.
Figure 2 illustrates a sample topology that could be discussed within the workshop. Simpler portals might drive a much different discussion. Many small group or division portals are set up on one, or maybe two, servers, and these are valid options. You just need to have some discussion about configuration to help ensure that other decisions about your portal will allow the project to continue.
Figure 2. Sample topology
Some general discussion can be insightful to the technical participants. For example, there are often questions about users connecting directly to the HTTP transport of the Application Server, and about not setting up a separate HTTP server. While this might seem like a valid option, there are many reasons why an HTTP server in front of the portal is an important layer in the infrastructure. This component can provide additional scalability and tuning capability, and performs as a true HTTP server unlike the transport in WebSphere Application Server. Even if the two components are on the same server, an HTTP Server will add value to the environment.
One reason that topology discussions are complex is that participants need information about multiple components, not just the portal server. Understanding the failover and scaling capabilities of WebSphere Application Server, IBM HTTP Server, content management, LDAP, and database servers can be daunting to anyone. The point of the workshop is to help identify some of the requirements for continuous operations, and to assess the willingness of the business to pay for this capability.
This activity provides a good opportunity to discuss architectural constraints (such as which operating system and hardware platform will be used for each layer), validating the versions of the different software components, and the interoperability of different components.
Most people understand the need for the production environment, and maybe one or two other environments for their portal. For large projects, especially, where there are many releases on an ongoing basis, you might need more environments. The Ideal WebSphere Development Environment (published in the IBM WebSphere Developers Technical Journal) that outlines several examples of how and why you might need multiple environments in your plan.
Some companies need many different environments. There are several reasons that multiple environments can be necessary, especially on large projects with many teams. Having several environments reduces competition among the environments, so that, for example, user acceptance testing does not interfere with performance testing. Multiple environments enables a team to take new releases through a full vetting process before being released into production where problems can become readily apparent. These multiple environments can include:
- This environment provides access to the application from all the intended users. This is the most stable and monitored environment.
- This environment should be set up identical to the production environment. This environment is where the final install and user acceptance test takes place. Failure and recovery tests should also be performed here so there should be at least two servers for each tier. Obviously, production may have many more than two so it can handle the intended load, but this staging environment need only have enough servers to adequately test the failure and recovery scenarios. This environment is also used for performance tests. The performance team should benchmark each release and ensure that the performance of critical areas does not degrade from one release to the next. It is important to run performance tests in an environment that is as close to production as possible (stable hardware/network, isolated environment) so the tests are more accurate.
- Quality Assurance
- This environment is where the QA team sets up and executes its own tests to ensure all functional requirements are met and to ensure that no regression has occurred. This environment is quite often combined with either Staging or Integration.
- This is usually the first environment that contains all the code for a particular release. All the different components in the system should be tested together to ensure they do not adversely affect each other.
- The development environment is a place for each development team to test their code in a more real runtime configuration. Developers normally code and perform their initial tests in the RAD/Portal test environment on their own desktop machine. This server gives the developers a more production-like server to ensure there really are no differences between the test environment and a real runtime environment. Depending on the size of the development team(s) there can be many development environments.
- This environment is used as an initial test bed for new releases of dependant software. For instance, when the next version of WebSphere Portal arrives it is installed on this server first to test out the install procedures and compatibility with the other components in the system before recommending that all development teams start using it.
Considering setup, configuration, and testing
It would be unwise to assume that setting up and configuring your environment is going to be a small task. For the uninitiated, setting up a full-scale production portal environment can be quite daunting. The process is not extremely difficult, especially with the recent advancements made in the installation and configuration. However there are a lot of moving parts, and making sure that each one is configured correctly, and interacts correctly with the other components, takes time.
If a configuration problem hits your system because of a non-standard or uncommon configuration or integration, then a bottleneck can occur within your setup which can take days or weeks to resolve. The point here is to not let this activity wait until the very end. Of course you need to wait until the hardware is in place, but ordering should occur early in the cycle to ensure that you have time to resolve any setup or configuration issues.
Once your production environment is in place, you need to perform baseline testing against the out-of-the-box portal to make sure that any infrastructure bottlenecks are uncovered. Database or LDAP configuration problems are the most common issues to resolve. If you know your base infrastructure is operating efficiently, then it makes it that much easier to diagnose application problems when you do full performance testing later in your project.
Defining security and LDAP needs
Security is one of the most important topics to discuss early in your project, so is worth the time in the workshop. You also need to have the right people involved with these discussions early on. Enterprise security is an important topic in every large organization and usually there are security mandates that all new applications must adhere to. Only by involving your security representatives early in the process can you ensure that everyone understands any security issues raised by the portal.
Some topics are pretty straightforward. Does the portal need to use SSL? If the answer is yes, then you can add line items to the project plan for the ordering or creation of certificates and for installation and configuration on the infrastructure.
Other questions are not so easy, or open up a can of worms that can quickly lead to problems. For example, which user repository (read: LDAP) are you going to use? This might be an easy question if you are among the fortunate ones who have a single corporate LDAP in place. For others, where there are multiple repositories within the organization, this becomes an interesting issue. Many times the first response is to use several and have the portal check all or some of them in real time for user login and attributes. As the portal continues to evolve this can become a real possibility for many customers, however it does raise some management and performance issues for the portal.
Many customers decide to put in a new LDAP that is specifically used for the portal. They develop a data migration scheme to merge existing user data and keep it updated on a continuous basis. While this approach works from a portal perspective, it adds yet another repository to the enterprise LDAP soup, and might cause more long-term problems. Some customers don't have any LDAP, or they wish to migrate their current repository to a single enterprise LDAP, using the portal project as a reason to begin this effort. This is a fine idea, however creating or redefining a corporate LDAP should not become part of the portal project. Make sure that this task is an independent project with independent management.
As part of the topic of LDAPs and user repositories, you need to discuss the existing, or to-be designed LDAP schema. What object classes and attributes will the system have, and where in the Directory Information Tree (DIT) will users and groups be located? For users new to these questions, see Everything you wanted to know about LDAP but were afraid to ask, to help bring you up to speed on many LDAP ideas and topics.
In a few cases, corporations are currently evaluating new technology for LDAP or a Security solution for the company. In those cases, everything is in flux and it is hard to design a solution. Our advice in these cases is to design a simple schema that everyone can agree on to use as a fallback so that the release of the portal is not delayed. If corporate security is going to take longer then is possible for your portal release, then you have something available and agreed upon to use for release 1 of your project. As the corporate standards are released, you can plan to migrate the portal to the new standard.
Sizing hardware requirements
Now that you've been overwhelmed by all the different environments you might need to set up, the next step is to size the environments to fit your needs. Sizing is basically determining how many machines you will need and how powerful each machine needs to be. You need to include these factors need in the sizing calculations to make sure that you determined the correct configuration for your environment:
- Number of registered vs. unregistered users, concurrent users, and peak user load
- Required response time
- Size of the application, number of pages, portlets, number of portlets on a page, and complexity of the portlets
- Additional factors such as backend systems, LDAP, database, and Web Content Management
- Type of OS being used, such as Windows, Unix, Linux
We suggest that you work with your IBM sales representative to assist you in sizing your production environment. He or she can guide you through IBM's well-defined sizing process. Sizing is a "garbage in, garbage out" activity, so be sure to put your best effort forward on this task so that toward the end of your project, so you don't suddenly realize that the machines are undersized and you need to go back to management for more money.
Likewise, spending too much money up front for capacity that won't be used is a waste of resources that could be used for other projects. You could grow into extra capacity over time, but too much extra can waste time and money in terms of excess hardware, setup and configuration, and ongoing management of the infrastructure.
Almost all portal customers want 24x7 availability, especially if the portal has a worldwide audience because there is no real downtime. So, availability is often discussed as a percentage of how much downtime the system can actually have. Starting with the assumption that the system is available 99 percent of the time within a single year, yields this table.
|Percent available||Actual downtime in hours|
(about 5 minutes)
Unfortunately, true "5 nines" (99.999%), which is virtually 24x7 availability, is very costly to attain because it means that the portal must be available even during upgrades. In addition to being available during upgrades of the portal configuration, you would need availability during upgrades of the WebSphere Portal and WebSphere Application Server products, and even the server hardware. Fortunately, 24x7 availability with a maintenance window can be much easier to attain.
You can use algorithms to assist you in determining the cost of a system being down to help you decide if less downtime is really worth the additional cost. To get an understanding on what it can take to have high availability with minimal downtime, read Maintenance procedures for WebSphere Portal V5.0 with 24x7 availability.
Laying out general development scenarios
At some point during the workshop the focus shifts toward the design and development of the system. Setting the stage initially with this major topic can get development teams pointed in the right direction. Many of the topics that can be discussed are generic to J2EE development; however, some involve portal-specific issues. Topics include:
- Development standards and standardization across the organization
- Portal and J2EE development best practices
- MVC frameworks, Struts, Java Server Faces (JSF), JSR 168, and WebSphere Portal extensions
- Build and deploy best practices and management of the development team and development process
Depending upon the experience of the development team, development discussions can take many twists and turns. For less experienced teams, or teams which are new to Java or portal development, you can use the workshop as a good opportunity to get the teams started on the right foot. For more experienced Java or portal development teams, use the workshop to discuss deeper technical information about the portal and available APIs. Recent developments with JSF will prompt a lot of discussion about what is the best approach and which framework the team should adopt. The current trend seems to be evolving toward JSF development, which offers a lot of advantages for J2EE developers including those who develop for WebSphere Portal. For an introduction and example of JSF development with WebSphere Portal read Developing JSF Portlets with Rational Application Developer 6.0 and WebSphere Portal Server 5.1, Part 1.
There are way too many topics to cover in this article in any type of detail. It is pretty easy to get the point that your team needs to put together its strategy for many of your enterprise systems. While you don't need to decide on everything before you implement your portal, Day 3 is the time to begin creating a long term strategy and a migration plan from any existing systems that you currently have in place.
WebSphere Portal is a full-featured product and provides enterprise capability that can support many portal environments. What's new in WebSphere Portal 5.1 outlines many of the latest capabilities that are available with in WebSphere Portal. Your workshop should include sessions that focus on many of these topics so that you can factor them into your architecture.
Discussing migration, content, and search
In many cases, you need to discuss the migration of existing systems to the new portal environment. For a new project, migration is often a secondary objective. However, when the portal is replacing an existing system it becomes a very important aspect of the project. Experience has shown that customers and end users are most critical of a migration of an existing system. Loss of current functionality is often the most common problem, and it is hard to overcome without deep expertise in the current system. See the blog WebSphere Portal in Action for additional information on migration.
The second issue is usability. End users are used to doing things in a certain way. Many users will embrace the new portal technology and agree that the migration will pay dividends over time. However, some users are resistant to change. Planning for end user education, support, and some hand holding is probably wise.
Any organization that has been on the Web for a reasonable period of time probably has their content in some centralized location, and has some search capability. Whether these are commercial systems or home grown, many customers are concerned about how to best leverage their existing systems and content. Plan to have initial discussions about the required capability during the workshop to make sure the team has the complete picture before moving too far forward.
WebSphere Portal includes integrated Web Content Management and Search capability. If you expect that these items will be major components in your portal, then plan to have a thorough discussion of available functionality as well as the migration effort to use them. You could also discuss some of the other options which IBM provides for content management and search space; these also integrate well with the portal.
In many cases, however, customers want to stick with their current systems because they have made a sizable investment in infrastructure and effort. In these cases, use this discussion period to determine how you can leverage the system within the portal. You might be able to take advantage of other integration efforts of this type, or you might need to come up with a new design based on your platform and requirements. You can complete design for integrating with your existing systems after the workshop, if necessary. Remember, the workshop is not designed to answer every question; rather it is to help you get started on the right foot.
Considering additional components
As with any new product, it is important for the architect to understand all the various components and features that are available to you. See WebSphere Portal Product Family for a description of the various portal releases and related offerings.
The Additional Components topic on the agenda is to give the team an opportunity to consider some of the many specific application features that may be helpful or even necessary when designing your portal architecture. For example, you might consider IBM Translation Server or IBM WorkPlace Collaboration Components as add-ons to your portal.
New features and standards that are supported within the portal, such as Web Services for Remote Portlets, provide opportunities for integration with a portal environment. Read Introduction to Web Services for Remote Portlets, along with additional articles, to help you decide if you want to include these capabilities as part of your overall architecture.
WebSphere Portal catalog
In addition to the components and portlets that are included with the WebSphere Portal product, you can download samples, commercial portlets, tools, and other add-ons from the IBM WebSphere Portal Catalog, many of which could be useful within your enterprise. Many of the most popular portlets in the catalog are IBM components that are designed to enhance portal functionality or provide you with additional learning capability.
Many third-party portlet providers are constantly adding new portlets to the mix. Many industry solutions are available from Aerospace & Defense, Banking, Education, Retail, and Wholesale solutions.
You might discuss the WebSphere Portal catalog early in the workshop to assist with mapping features to requirements and readily available portlets. Because you have so much to discuss and learn early in the workshop, you might want to defer the detailed discussion until later in the workshop when the team has more of a collective understanding of the portal and what is available.
As you can see the workshop covers such a wide array of topics that the audience has to be just as broad. Incorporating this diverse group of members within a three-day meeting can be quite a challenge. Fortunately, the diversity also leads to some lively discussions as different representatives discuss topics of importance to the project.
There are many additional topics that you could include or which could come up in the workshop, depending upon the organizational and portal requirements; for example, ongoing operations and monitoring of your portal environment, training and experience of various roles that are needed in support of the portal, and additional or deeper discussion into various technical topics. Discuss the agenda before the event, to tailor it to your specific needs so that the facilitator can prepare for additional topics that might enter into the discussion.
In the next article in this series, we discuss the details of project planning and estimation for your portal project.
|Sample agenda||SamplePortalWorkshopAgenda.zip||6 KB|
- developerWorks WebSphere Portal zone: Find more resources to help you develop portals and portlets.
- Developing JSF Portlets with Rational Application Developer 6.0 and WebSphere Portal Server 5.1, Part 1: Provides an introduction to the use of Java Server Faces for portlet development.
- Everything you wanted to know about LDAP but were afraid to ask: Get questions answered about the Lightweight Directory Access Protocol.
- IBM Global Services: Learn about service offerings related to IT services.
- IBM WebSphere Services: Describes service offerings available for assessing, designing, creating, and maintaining WebSphere based applications and portals.
- Introduction to Web Services for Remote Portlets: Get an overview of the WSRP standard and how to use it.
- Maintenance procedures for WebSphere Portal V5.0 with 24x7 availability: Learn how to apply maintenance to a portal without having to bring it down.
- The Ideal WebSphere Development Environment: Gain an understanding of what you need to set up for development enterprise applications such as a portal.
- WebSphere Portal in Action: Read Joey Bernal's blog on developerWorks.
- WebSphere Portal Product Family: Learn about the products and configurations included in the WebSphere Portal family.
- What's new in Portal 5.1?: Find more resources to help you develop portals and portlets.
Get products and technologies
- IBM WebSphere Portal Catalog: Download portlets, tools, and other add-ons for your portal.
- Rational Application Developer V6. : Download a trial version from developerWorks. Includes the portal tools and a test runtime copy of portal that you can use to develop a prototype.
Dig deeper into WebSphere on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.