Strategies for Business Intelligence on the Internet

By Mike 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 to account the possibility of making the data warehouse accessible and secure for Internet accessibility. This lack of foresight often results in changes to the network architecture or replacement of the BI access tools due to incompatibility with Internet deployment security needs.

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 Internet 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.

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 Internet 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 Internet 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). Typically, the web, application, and database server components are physically separate (see figure 1). A firewall is a 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 Internet 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.

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 no 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 a middle layer that translates application queries into commands that the database can perform.

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 API). 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.

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 an SSO product.

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.

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 whether or not the BI access product was designed with the intention of being deployed on an Internet. 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.

Describe the levels of security available through the BI access product?  

In this question, determination needs to be made whether the product’s security access levels are sufficient to meet the business and administration needs of your company. For example, if the product will be deployed enterprise wide within your company, the ability to delegate some level of administration authority to selected users in various business groups or departments may be a requirement for the BI product. This type of administration delegation should be controlled by the central administrator or main super user. This main administrator should be capable of controlling the amount of administrative rights each group administrator has available to them. The group administrator should be capable of controlling access for users in their specific groups(s) or department(s) only.

Additionally, the BI access product should provide security access not only at a user or group level but also down to row level. Unlike user or group security, that controls what content, reports or groups of reports a user can see through the BI access product, row level security allows control of what data is presented through the same report for two different users. Typically this is accomplished through information stored in the security meta data layer of the BI product which is used customize the WHERE clause in the SQL that is generated to run the report for the specific user. The results, manager A & B run the same report option through the BI access product but with row level security the information provided to each manager is specific to them because the data was filtered to meet their security profile.

What methods are available with the product to manage migration of projects, groups or reports, or single reports through development life cycles (development, quality assurance, user acceptance test, and production)?

This next question addresses an area that is typically lacking in most BI products areas not just access tools, migration. Has the vendor provided utilities products or methods for migrating source components between your environments? Do any of the vendor’s migration methods involve use of file transfer protocol (FTP); many companies are moving towards use secure copy (SCP) to replace FTP. What are the vendor’s best practices for migration of entire builds, projects, group of reports or single reports through the development lifecycle? Can your firm’s software migration product work with the product? Has the vendor considered migration of source components between environments or simply left this to the administrator to determine? These are just some of the considerations you should be looking at when reviewing the vendor’s response to this question. Administration of source components through a BI access tool can be very labor intensive and costly if it has not been addressed adequately for your needs by the product’s vendor.

Another related question you should consider in the vendor’s response: can multiple copies of the product be installed on the same server? This type of scenario is most typical when establishing your development and quality assurance (QA) environments. Budget constraints may require you to house both these environments on the same server. You need to make sure that two or more copies of the product can be easily and successfully installed on the same server, not just the ability to separate development and QA environments. This distinction is important for when new releases or patches of the product are released. This will allow you to test the vendor’s new software against development, or maybe another test environment, before committing to QA.

How does the BI access product support failover if an application server for the product goes down?

This question is optional depending on whether your business requirements dictate high availability due to criticality of the information, client business needs, or to meet other service level agreements. This question assumes your infrastructure is supporting redundant web servers, application servers, DBMS servers and possibly load balancers to support high availability (See figure 1). The vendor’s response to this question will give you a fairly good indication of how well the product was designed for Internet deployment for mission critical information.


Figure 1

Some considerations you should be looking for in the vendor’s response include the method for session re-establishment after failover to another application server. Does the user need to re-authenticate and start their session over from the beginning? How is session information (customizations, file saving, views, etc.) shared between the BI access product’s application servers? In some company’s installations, the administrator for network security may not accept the method of information sharing between application servers due to perceived risk in security. For example, UNIX application servers sometimes use a file sharing method called network file system/remote procedure call (NFS/RPC) to synchronize files/directories between servers. Many network administrators consider RPC a security risk in an Internet environment due to its perceived vulnerability to be hacked. If the vendor’s solution for file sharing between application servers includes use of RPC and your company’s polices restrict its use, alternative file sharing methods may need to be explored in order to deploy the product in your environment.

Finally, the BI access product may require installation of software on each of the web servers in order to facilitate failover. The functionality of the software installed on each of the web servers needs to be looked at from a security perspective to insure it meets your company’s Internet polices. Also, review what, if any, persistent data is ever populated on the web servers for security or confidentially risk. Any data that is stored on the web servers should be considered compromised due to its close proximity to the Internet.

How does the BI access product support load balancing in an Internet environment?*

This question is also optional depending on whether your business needs require support of high scalability and performance. Considerations include if and then how the product supports balancing of requests across multiple application servers during periods of increased traffic. The methods used for load balancing need to be reviewed for compatibility with your environment’s security, communication, middleware, web server, and application server standards. Requirements for particular web server’s applications (e.g., Apache,) or application servers (e.g., BEA Weblogic, IBM WebSphere) may make the product incompatible for your environment.

The BI access product may require installation of software on each of the web servers in order to facilitate load balancing. The functionality of the software installed on each of the web servers needs to be looked at from a security perspective to insure it meets your company’s Internet polices.

What single points of failure exist with the BI access product when deployed for failover?

In this question, look for potential point of failures in deployment of the product that may not be covered under a failover implementation or may require a hardware solution such as clustering. Look at each component in the implementation to make sure it is covered during a failover operation (e.g., proprietary DBMS, file system sharing, content directory, user personalization setting, etc.). The objective would be to have an automatic failover that is as seamless and undisruptive to the user as possible.

What data encryption methods are available through the product offering for authentication and component communication?

Response to this question will indicate whether or not the BI access product was designed with the intention of being deployed on an Internet. Typically BI access products support Secure Socket Layer (SSL), which is a common encryption protocol for transmitting confidential information across the Internet. Considerations for this question include whether the BI access product supports encryption to user entitlement stores such as LDAP, others). Beyond authentication, does the product support encryption of information between its components should also be determined to review any potential risks.

Use of these twelve questions when evaluating a BI access product for Internet deployment can help you avoid many costly pitfalls and issues commonly encountered.

About the Author

Michael Jennings is a recognized industry expert in enterprise information management, business intelligence/data warehousing and managed meta data environment. He has more than twenty years of information technology experience in government, manufacturing, telecommunications, insurance, and human resources industries. Mike has published numerous industry articles for DM Review and Intelligent Enterprise magazines. He has been a judge for the 2002 - 2007 DM Review World-Class Solutions & Innovative Solution Awards and 2003 Wilshire Award for Best Practices in Meta Data Management. Mike speaks frequently on enterprise information/architecture issues at major industry conferences and has been an instructor of information technology at the University of Chicago's Graham School. He is a co-author of the book “Universal Meta Data Models” and a contributing author of the book “Building and Managing the Meta Data Repository”. He may be reached at

Free Expert Consultation