Evaluating the BI Environment for Extranet Deployment - Part 1
By Michael Jennings
Is your business intelligence environment ready for safe, reliable, scalable accessibility via the Internet? How are you addressing this challenge?
Typically, business intelligence (BI) environments are initially constructed and deployed to internal clients across the corporate local area network or Intranet. Warehouse manager and architects have a reasonable sense of security knowing that their data, the corporate knowledge base, is located many levels away from outside access protected by various network security mechanisms. Evaluation of BI access components is made with a focus on performance, scalability, and reliability. Very few initial BI architectures take in account the possibility of making the data warehouse accessible and secure via an extranet. This lack of foresight often results in changes to the network architecture or replacement of the BI access tools due to incompatibility with extranet deployment security needs.
This article is the first portion of a two-part series, which examines some of the questions that need to be asked before making a BI access environment accessible to the Internet. These questions, or group of questions, should be used in a feasibility assessment of a BI access environment, whether in existence or being evaluated for purchase, to determine possible risks. These questions are not all encompassing but when answered together they should provide a good sense of whether your BI access environment is ready for extranet deployment. Note, the assumption here is that the user is accessing the BI environment across the Internet through a web browser on their client PC.
1) What are the hardware and software requirements for installation and administration of the BI access product on an infrastructure consisting of web server, application server, and database server?
Figure 1
In this first question, determination can start to be made whether the product is compatible with hardware and software standards for your firm. Are the hardware platforms supported by the vendor recommended by your internal infrastructure and network administration groups? In some cases, hardware platforms acceptable for internal LAN use may not be acceptable for extranet use by these administrators due to security and/or other concerns. The operating systems (versions & patches), web server applications, application engines, and databases supported by the vendor need again to be also supported for extranet use by your internal technical administrators.
Look for any requirement that mandates installation of the web server, BI access application, or database on the same physical server. This may limit your network security options around deployment of firewalls and demilitarized zones (DMZ) in which typically physically separate the web, application, and database server (see figure 1). A firewall is hardware or software system designed to prevent unauthorized access to or from a private network. A DMZ is a combination of two or more firewalls that sits between the Internet and an internal network.
Finally, look for the requirement for any third party applications (e.g., infrastructure management application, framework application, other) that may be recommended by the vendor to support this type of extranet infrastructure. The purpose for these products in the solution needs to be thoroughly explained and understood by your internal technical administrators to determine applicability in your environment.
2) Does the product use leading industry database management systems (DBMS)? Is connectivity achieved through ODBC or native drivers?
In this, second question, look for the requirement for any proprietary, non-industry leading database requirements. These databases are usually used in conjunction with the product's meta data repository. They are usually described as low to zero maintenance and are transparent from an administration and maintenance standpoint. Use of these proprietary databases means your technical administrators have little to no documentation on their operation, have not means of performing backups or optimizing performance. These databases are also typically characterized by having to be installed physically on the same server as the application, which may limit flexibility in the architecture.
Finally, look for support of native database drivers versus Open DataBase Connectivity (ODBC) standard for database connectivity. Database performance through ODBC is typically slower than native drivers due to the addition of middle layer that translates application queries into commands that the database can perform.
3) Does the BI access product interface seamlessly with industry leading enterprise information portal products?
This question is optional depending on whether you intend on using an enterprise information portal (EIP) to present content beyond BI access (e.g., news, collaboration, community content, other) or need to integrate other applications. Look for the BI access product to have the capability to communicate the content of its directory or BI portal seamlessly to the EIP through some interface method (e.g., XML). This product capability will mean that a single user experience method will be used to present content to the user regardless of whether it originated from the BI access product or other means. If this capability does not exist, the BI access product will simply be launched through a URL on the EIP. In this case, the user experience through the browser will vary depending on which product is being currently launched from the EIP.
4) Does the BI access product integrate with single sign-on products?
This question is also optional depending on whether your infrastructure is using a single sign-on (SSO) product to automate access to all web and enterprise applications. Once the user is authenticated against an entitlement store (e.g., LDAP, ADSI, NT, NDS) by the SSO product their credentials are saved for the duration of the session thereby, making re-authentication by the user for access to subsequent applications unnecessary. Look for support by the BI access product with your preferred SSO product and entitlement store authentication method. In some cases, the BI access product's native security method may be sufficient for your security needs without requiring interface with a SSO product.
5) Is any software other than industry leading browser required to be loaded on client PC (e.g., plug-in, applets, other) in order to access full capabilities of the product?
In this question, look for any requirement for software to be installed on the client PC beyond the native browser. Typically, these software plug-ins or applets are needed on the client PC to provide enhanced graphical, printing or product functionality capabilities. While your firm's own internal policy may permit download of plug-ins or applets from the Internet, your clients, partners, or other external users own network security may prevent this type of transfer to occur to their internal PC's. Additionally, the size and the amount of time to download the plug-in or applet should also be examined.
6) Can the product components (web server, application server, database server, administration) be configured to use specific ports through a firewall?
Response to this question will indicate the whether or not the BI access product was designed with intention of being deployed on an extranet. If access through a firewall cannot be limited to a specific port or range of ports many of the security advantages of having a firewall are diminished. Additionally, monitoring of firewall activity becomes more problematic.
Part two of this series will examine questions around the reliability and scalability of the BI access environment deployed on the extranet.
About the Author
Michael Jennings is an architect and manager specializing in business intelligence, enterprise performance management, and web based delivery strategies & architectures at Hewitt Associates. He has more than eighteen years of information technology experience in the manufacturing, telecommunications, insurance, and human resources industries. Michael speaks frequently on business intelligence issues at major data warehousing conferences and is an instructor of information technology at the University of Chicago's Graham School. He is a contributing author to the book "Building and Managing the Meta Data Repository" published by John Wiley & Sons.
Michael F. Jennings
Hewitt Associates LLC
100 Half Day Road, MS: 3OP-5S
Lincolnshire, IL 60069
(847) 295-5000
Fax: (847) 442-5353
Email: mjennings@igcom.net
mike.jennings@hewitt.com