SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox
Enterprise Portals
Join Senior Technology Editor Lori MacVittie as she begins work on a comparative review of Portals for our April 15, 2004, issue. Check out the test plan and product
February 27, 2004
4 Min Read
Evaluation Particulars
What Do We Consider Appropriate for This Review?
We will consider products offering Enterprise Class Portal functionality. To qualify for this review, products must:
Support deployment on Windows 2000
Include high-availability functionality (load balancing, failover) either directly or via deployment within an application server.
Real-World Labs Testing Scenario
All product testing is conducted under real-world conditions. We will judge products based on the following criteria:
Architecture
Framework
Management (distribution of processes, ease of use, etc.)
Implementation (platforms and application servers supported)
Standards (.NET, SOAP, JSR 168, XML, etc.)
Integration
Pre-built portlets/gadgets
Horizontal applications (Lotus Domino, Exchange, etc.)
Vertical applications (SAP, Siebel, PeopleSoft)
Identity Management (AD, directories)
Customization
Development framework
User personalization
Price
graded on a price per user basis
Security Features
This test will pit each product head-to-head for comparisons of development, deployment and performance. This includes a comparison of the components included (portlets/gadgets) as well as integration into our existing infrastructure (Active Directory 2000, SQL Server 2000, Oracle 9i, Exchange 2000, .NET and J2EE Web Services, HTML feeds).Our testing scenario is as follows:
Each product will be deployed on a Dell 2650
2.6 Ghz
1MB RAM
GB Ethernet
Windows 2000
We will test interoperability against "real" services and will include HTML and XML feeds, J2EE and .NET services for inclusion in a portal page.
The development framework will be evaluated on the amount of coding required and speed of development when developing a portal containing common gadgets including .NET, J2EE Web Services, HTML feeds, XML feeds and horizontal applications (e.g. Exchange 2000). NWC Inc. wants to build a portal that incorporates data from several sources, depending on the identity of the user.
Enterprise portals comprise a great deal more than gadgets to access data. An enterprise portal should support the following:
Collaboration (i.e., real time [IM], discussion forums, group calendaring, e-mail)
Search functionality
Traditional portal functionality (inclusion of data from disparate sources)
Value adds of significant interest:
Document management (including versioning, locking, etc.)
Knowledge management services (what type of documents/information can be stored, how it is accessed, notification, alerts of new knowledge, etc.)
We will be grading based on the first set of features and evaluating the second set of features if they are available.
If a product does not offer functionality in the "value add" category, we will, of course, not test that aspect(s).
Organizational Structure
At least three users each from Customer Service and Finance will be utilized to test the aforementioned functionality. Two of each of the users will be "normal" users and one will be management level to allow us to examine the security features and control within the portal.We will try to implement the following organizational structure in each portal:
Administrator, access to everything
One customer service "team" comprising all three customer service members, with the manager being the "owner" of the team.
One finance "team" comprising all three finance members, with the manager being the "owner" of the team.
One "companywide" team, which comprises all users, with the administrator being the "owner" of the team.
Evaluation of document management, knowledge management and collaboration
Each "team" will attempt to:
Share documents within the team only
Use any workflow processes present to require approval of one document by the team "owner" before being published for the team
Access documents shared by other team members
Access documents available to the "company"
Attempt to access documents not available to them through search functionality and other means
Use collaboration features to communicate with other team members
This part of the evaluation will include examination of the process required to share documents. What technical skills (if any) are required of the user? Is there a workflow process that allows us to require approval of specific groups of users and/or specific types of documents and/or on a project-by-project basis? Evaluation of Personalization
Each user will attempt to personalize the portal to fit his/her own taste in terms of layout, notifications and alerts for discussion threads, document categorization, etc.
Evaluation of Search FunctionalityUsers will use the search to determine whether security restrictions are upheld by:
Searching for documents known to be accessible
Searching for documents known to be inaccessible
Attempting to circumvent the controls placed on the user to access documents/information not allowed by security features
Search functionality will be evaluated in terms of how well it enforces security policies and how it is integrated into the product, i.e., is it integrated, can the user do federated searches, what objects within the portal are searchable (people, documents, discussions, portlets, free text, etc.)?
Evaluation of Customization Capabilities/Development of the Portal
To test the capability and standards compliance of each portal, we will attempt to design a portal that incorporates several internal and external sources of data. This will allow us to evaluate:
Compliance with standards
Interoperability
Breadth of out-of-box components
Development environment for custom portlets/gadgets
You May Also Like
More Insights
