- Technical Infrastructure Design
- Applications Architecture Design
- Implementation
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Applications Architecture Design
Once the topology and technical infrastructure of the e-portal have been determined, you can begin designing the applications architecture. You can use an existing package to carry out one or more of the applications architecture functions (see my next article comparing e-portal packages), or write your own. Typical applications architecture functions required include the following:
User registration
User authentication
User access control
Personalization
Content management
Document/workflow
Newsfeeds
Look-and-feel templates
Collaboration (via chat rooms, discussion groups, document sharing, messengers, process pipelines, etc.)
Enterprise integration architecture/interoperability
Browser compatibility
Mobile/wireless computing
Writing your own portal software from scratch may make it easier to tailor the portal to your exact requirements, to maintain it, and to upgrade; however, these benefits must be weighed against the cost of the initial building, writing, testing, and implementation of the software. It's likely that using an existing e-portal product would considerably reduce the time required to build the e-portal and would reduce the risks involved in implementation, because the technical applications architecture has already been fully tested and presumably meets performance, availability, security, and other requirements. It's likely that access control, personalization, workflow, EAI, and other features are already built into the product.
Enterprise Application Integration (EAI)
Unlike in data warehousing design, where most data is obtained from an RDBMS, the e-portal designer has to take into account the need to bring together data from many sources—both structured and unstructured—email, discussion groups, bulletin boards, spreadsheets, XML, HTML, and so on.
NOTE
For a good discussion of the issues involved, see the InfoWorld article "Web Opens Enterprise Portals."
The designer of an e-portal therefore has to design enterprise application integration (EAI) functionality that enables data from disparate sources to be aggregated in some way. Portal software typically facilitates this need using portlets, gadgets, EJBs, CORBA, COM, etc. If you're designing your own applications architecture, it's a good idea to choose a technology that's used elsewhere in your organization already, and for which you have plenty of skills. If all your programmers are Visual Basic gurus, it's no use choosing EJBs just because you like the technology!
However, it's also important to consider openness when devising your EAI mechanisms. The method you choose must work with all the data sources from which you want to capture data.
Flexibility within your technical infrastructure and applications architecture is key when building an e-portal. Use a parameter/configuration file for setting as many variables as you can; this strategy will keep you from having to stop the web server or the e-portal to make changes to the way in which your e-portal works. The following kinds of configuration information change regularly for e-portals:
URL for the e-portal
Web server IP address
LDAP configuration information
Database connection information
Connection information used to connect to other data sources
JDK path information
User Registration
Your e-portal is useless if users can't get in, so the registration process is key to the success of your e-portal. The process shouldn't be so complicated that it turns away prospective users, but it should enable you to gather all the information you need about a user before he or she can access the e-portal.
Carefully determine which registration information is mandatory. This may differ by location and/or user type. You may be able to use an employee's payroll number to automatically look up a great deal of information about that employee, saving the employee the need to type it all in, whereas it's unlikely that you would have that information about a supplier. Different departments or countries within the same organization may require different information to be gathered. For example, state or ZIP code may be required fields in the U.S. but not in other countries.
The end result of the registration process is usually a unique ID and password that will be used to identify the user to the system. How this is generated should be carefully determined, and is by no means as simple as it may sound.
User Authentication
Another major consideration when building your own e-portal is the means by which you will authenticate users. You may decide to use operating system authentication (such as NT/2000 authentication), web server authentication (cookie/SSL), database authentication, or implement some mechanism of your own. Issues affecting this decision include whether the preferred mechanism will work—firewalls may not allow cookies or SSL, users with Netscape browsers may not be able to use some Microsoft-based authentication methods, and so on.
If your organization already uses a single-sign-on solution (such as Netegrity Siteminder), this will affect the authentication mechanism you choose.
User Access Control
Once users are authenticated, which data and information can they see/manipulate, and how will it be displayed? An access control layer of functionality or set of objects must be designed. This can be as simple as a database table lookup to determine which users (or user roles to which a user can belong) have access (read, write, create, or delete) to which objects, data, or pages within the e-portal. It can be very complex if the same user can play many roles and the different roles can affect different data/objects. It's also possible that it's appropriate to use LDAP or Microsoft Active Directory for implementing access control. Determine the true business requirements before designing the access-control mechanism.
Availability, Scalability, and Performance
Because an e-portal is available 24x7x365, your technical infrastructure must support such requirements. One method of ensuring this is by using hardware redundancy, from having a failover site with a separate router, ISP, network, servers and so on through to using RAID on your server's hard disks and implementing server clustering. Another tactic is building "de-coupling" into the software so that a failure in one component of the software doesn't cause other parts to fail. A third strategy is providing administrative functions built into the e-portal that don't require stopping the web server or the e-portal; built-in parameters or files containing options can reduce the number of times the e-portal is unavailable to the user due to system changes.
Using load-balancing, message queuing (such as IBM MQ), transaction servers (e.g., Microsoft MTS or Sun JTS), and object/connection pooling technologies can help to ensure that the e-portal can cope under increased load. But good capacity planning and sufficient hardware (and memory) availability for high-load times is also necessary. Work out in advance how many users will be expected to use each e-portal (now and in the future), at which times of day the usage peaks are likely to occur, and what times of the month/year will put excessive load on the system.
Load-balancing, good capacity planning, and good hardware selection can improve the perceived performance of the e-portal, but you also need monitoring software to check for bottlenecks within the network or on the web site—and protection against malicious activity downgrading performance.