Continue in 2 seconds

The Internet Accessible BI Environment, Part 2

  • October 01 2002, 1:00am EDT

Is your business intelligence environment ready for safe, reliable, scalable accessibility via the Internet? How are you addressing this challenge?

This is the second column of a three-part series evaluating business intelligence (BI) applications for Internet-facing deployment. This segment will examine some of the issues around security, software life cycle management and client-browser requirements that need to be considered.

5. Is any software other than an industry-leading browser required to be loaded on the client PC (e.g., plug-ins, applets, other) in order to access full capabilities of the application? 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 application functionality capabilities. While your firm's own internal policy may permit download of plug-ins or applets from the Internet, the network security of your clients, partners or other external users may prevent this type of transfer to occur to their internal networks. Additionally, the size and the amount of time to download the plug-in or applet should be examined for feasibility if pursued.

6. Can the application 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 application was designed with the intention of being deployed on the 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.

7. What are the levels of security available through the BI access application? Determination needs to be made as to whether the application's security access levels are sufficient to meet the business and administration needs of your company. For example, if the application will be deployed enterprise-wide, 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 application. 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 available to the group administrators. The group administrators should be capable of controlling access for users in their specific groups or departments only.

Additionally, the BI access application should provide security access not only at a user or group level but also to the row level. Unlike user or group security that controls what content, reports or groups of reports a user can see through the BI access application, 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 application which is used to customize the where clause in the SQL that is generated to run the report for the specific user. As a result, if managers A and B run the same report option through the BI access application, through the use of row-level security, the information provided to each manager is specific to the manager because the data was constrained to meet the manager's security profile.

8. What methods are available with the application to manage migration of projects, groups of reports or single reports through development life cycles (development, quality assurance, user acceptance test and production)? This question addresses an area that is typically lacking in most BI products – 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 toward the use of secure copy protocol (SCP) to replace FTP. What are the vendor's best practices for migration of entire builds, projects, groups of reports or single reports through the development life cycle? Can your firm's software migration application work with the application? 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 application can be very labor-intensive and costly if it has not been addressed adequately for your needs by the vendor.

You should also consider whether or not multiple copies of the application be installed on the same server. This type of scenario is most typical when establishing your software life cycle 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 application can easily and successfully be installed on the same server – not just that you have the ability to separate development and QA environments. This distinction is important when new releases or patches of the application are released. This will allow you to test the vendor's new software against development, or maybe another test environment, before propagating to QA.

Part 3 of this series will explore questions focusing on disaster recovery, performance and scalability, and security capabilities to ensure successful Internet deployment of BI access application.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access