Implementing E-Portals: The Technical Issues
- Technical Infrastructure Design
- Applications Architecture Design
- Implementation
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Chances are that some existing e-portal package already meets all your business and technical requirements. (If you've reached this point without fully exploring all the business and technical requirements, or without considering the options available on the market, read my other articles in this series before continuing.) However, if you're decided that building your own e-portal is the best alternative, or you're simply interested in the issues involved in doing so, this is the article for you.
Technical Infrastructure Design
The technical infrastructure on which the e-portal will run is crucial to its success. These are some of the issues:
Network over which the e-portal will operate
Server hardware to be employed
Routers, firewalls, and any built-in redundancy must be able to handle predicted load (load-balancing and message queuing may be needed)
Performance targets
Availability requirements (often 24x7x365)
The topology design requirements for building an e-portal are similar to those for building a corporate data warehouse from scratch.
Take into account the business strategy/goals of the e-portal, and how those goals affect all user types—employees, customers, business partners (suppliers, distributors, warehouse managers, shareholders), and so on. Just as in a data warehouse, a completely different view of the data will be required for each different e-portal user class.
You may design the technical infrastructure of the e-portal to map to geographical locations (for example, one e-portal for each country), or it may make more sense to have a centralized e-portal for each user class (such as one e-portal for employees behind the firewall and one e-portal for suppliers in the demilitarized zone). In B2B situations, these issues may be further complicated by having the e-portal cross organizational boundaries as well as geographical boundaries; business partners may need to keep some of their e-portal data private but share selected data. A further complication is the need for redundant hardware—failover sites, clustering, etc.
In addition to the physical locations of server hardware, when designing the technical infrastructure you must consider the locations of web server software, database software, and LDAP directories, and how they map onto the server structure—and the need for firewalls, routers, VPNs, and so forth (hardware or software).
Although the web servers themselves are best placed in different geographic locations, much of the data may be held centrally on a single LDAP repository or database. If splitting the data, consider carefully how that data should be split:
Horizontally (see Figure 1). For example, data about German employees is held in Germany, while data about English employees is held in England. This structure is often sensible for reasons of data-protection legislation.
Figure 1 Centralized login via one web server, accessing many e-portals,
each with its own data.Vertically (see Figure 2). Data that doesn't change often—for example, reference data, such as part numbers—is held centrally, while data that is changed most often at the locations, such as purchase order data, is held at those locations.
Figure 2 Decentralized login and decentralized data by country.
)
Figure 1)
Figure 2Much of the data being made available via the e-portal probably was previously considered company confidential. Therefore, good security measures must be built into the technical infrastructure. The use of the demilitarized zone (DMZ) is a common means of protecting internal systems and data while providing access to certain data only to authorized business partners or customers. Servers within the DMZ must be "locked down" to avoid providing a backdoor into the internal systems for hackers. For example, any services not required on those servers should be switched off—particularly FTP. Firewalls protecting the internal systems can check that only internal IP addresses have access to those systems, and can restrict access for all other IP addresses to accessing machines within the DMZ.
If you decide to use existing e-portal software rather than write your own e-portal from scratch, investigate to what extent that decision will determine your technical infrastructure. Some e-portal software makes it easier to have a centralized e-portal than a decentralized one; other packages don't deal very well with access controls/security operating from different locations, or with single-sign-on requirements.
You also need to determine which supporting software the e-portal software requires: which web servers, LDAP servers, and/or databases the software can work with; which version of the JDK it uses for any Java implementations. Nail down suppliers to determine which actual versions of JDK, LDAP, and web server software have been used successfully for requirements similar to yours; some e-portal software is very sensitive to the versions of software supporting it. (For example, Tibco/Yahoo! Portalbuilder version 4.0 is very sensitive, with known issues involved in using IPlanet Web Server v6, some IPlanet LDAP versions, some JDK versions, and Microsoft Active Directory.)
If you intend to extend the e-portal software yourself, work out how such extensions will be implemented. Is a Java API made available? If so, it may be important to know that the software is J2EE-compatible to ensure interoperability with other code you may write. Is a COM, COM+, Web Services (WSDL), XML/SOAP, or CORBA interface the primary method of extension? Do your programmers have the requisite skills to use such interfaces?