This article will detail common BI360 Installation Architecture setups to help you decide how to best implement the BI360 solution based on available resources your organization has.
The following are some common BI360 implementation architecture diagrams.
The above configuration provides several advantages when compared to a converged system. One advantage is that testing can be done without impacting any aspect of the production system. These tests may include template building, budget write-back testing, and software version upgrades for both BI360 Planning and Reporting. Once these changes have been thoroughly tested, they can be implemented in the production environment in a controlled manner.
As mentioned above, the OSR_Repository version must match the Reporting application install on the client. The environment configuration presented in diagram A is the only scenario that will allow testers to upgrade the Reporting tool for testers without affecting the production environment since the client and repository are kept separate.
The configuration shown in diagram A implies two SQL server instances, which may not be feasible at all organizations. It is possible to obtain lower cost licensing for Development/Testing SQL servers from Microsoft, through the MSDN licensing program or by purchasing Development Edition SQL licensing which is far less expensive than traditional licensing.
An alternative approach to configuring a test environment is shown below.
The setup in diagram B differs slightly from the configuration in diagram A in that only a single SQL Server instance is required. In this particular setup, the Test BI360DW database resides on the same server as the Production BI360DW with a single Repository database.
This type of setup is common to create an environment to test the upgrade of the BI360 Planning tool since the test client and the Test BI360DW database can be upgraded without affecting the production BI360 Planning tool and the Production BI360 DW database. In addition, the write-back configuration of various Planning templates can be tested against the Test BI360DW database.
One drawback to this setup as compared to the first setup is that the upgrade of BI360 Reporting cannot be tested since there is only one Repository database. It is not possible to create two separate OSR_Repository databases on the same SQL instance because the application cannot be configured to change the OSR_Repository database name. Another issue that may occur is that since the single repository contains the connection for both Test and Production BI360DW databases, users and testers are able to freely change connections between the two databases. This may result in users saving their data into the wrong database by mistake. To prevent this from happening, security groups from Production and Test should be leveraged to only allow users to interact with the environment that they need to use.
The above installation types represent just a couple of the most common ways to deploy BI360. Not shown here are Citrix Server configurations and a single production setup but the concepts shown here can apply to those setups.
For further questions on how you are deploying BI360, please contact Solver Support.