Installation Options for SAP Business Objects Planning and Consolidation, version for Netweaver
Updated October 10, 2011
There are two main installation paths that can be chosen for your SAP Business Objects Planning and Consolidation, version for Netweaver (BPC) implementation: you can install BPC within your current BW system (the “Add On” method) or you can install BPC on a separate BW system (the “Stand Alone” method). Each installation method has pros/cons that should be considered prior to deciding upon an implementation path.
SAP Business Objects Planning and Consolidation 7.5, version for Netweaver (BPC75NW), must be installed on a suitable Netweaver platform. For BPC75NW Support Pack 08 or earlier, the Netweaver platform version must be Netweaver 7.01. Based upon customer demand (SAP listens, and SAP delivers), BPC75NW will be supported by Netweaver 7.3 in the near future. The current anticipated timing for NW 7.3 support is SP09 (end October 2011), please review SAP Note 1639341: “BW 7.3 support on BPC 7.5”.
Which is better: Add-On vs. Stand Alone? The answer varies for each customer since it depends on a number of factors that need to be evaluated for each implementation:
- Hardware Investment
- Administration Costs
- Integration Development and Maintenance
- Upgrade Considerations
- Support Pack Considerations
- BWA Investment
- Data Movements
There is typically some increase in hardware investment when implementing any BPC project. The Stand Alone scenario will lead to some additional cost for servers required for creating the new instance of BW that will be used to support the BPC application. However following an “Add-On” implementation scenario will also require additional application servers to accommodate the anticipated incremental BPC user load on the existing BW system. The net hardware cost differences between “Stand Alone” and “Add-On” may be negligible.
On initial reflection, the Stand Alone scenario may be presumed to inherently have superior performance; however this is not necessarily to case if the Add-On scenario is properly sized. In addition, load balancing is also an important consideration to ensure overall system responsiveness (for example, BPC processes can be isolated from the BW processes, from a load balancing perspective, if desired).
System Admin costs may be greater with a Stand Alone implementation since an additional host system will need to be maintained, tuned, monitored, etc.
However if the administration support is provided using in-house resources, the additional cost may be negligible by being easily absorbed into the existing in-house administration support model.
If system administration is out-sourced, then additional cost should be anticipated (as most external support contracts charge by system instance).
Additional consideration should be anticipated to keep your out-sourced system up to date with current support packs and corrections. Failure to maintain the system can result in increased administration and operational costs through the need to research and implement corrections that have already been developed for more current support pack levels.
Integration Development and Maintenance
There are a variety of ETL tools to pull master and transactional data into BPC, but these tools typically point to BW objects (info cubes and info objects) within the hosting BW for source input. Following a Stand Alone implementation path, additional processes will need to be developed to load the source data into the BPC supporting NW environment. This additional configuration will need to developed and, of course, maintained.
New BW functionality is continuously being deployed and customers struggle to determine the best timing to upgrade their systems. In a Stand Alone deployment, it may be easier to upgrade your main BW system while leaving your BPC hosting BW system at an earlier revision. One of the main benefits to the stand alone path is the elimination of many of the dependencies between BW upgrades and BPC upgrades. This decoupling may be a significant consideration since currently BPC 75 NW is currently only supported by Netweaver 7.01. If you have a BPC75NW system today deployed using the Add On approach, you cannot upgrade your NW environment to NW 7.3 since BPC is not supported by this version of NW.
Recognize that system upgrades depend on a number of business environmental factors: corporate politics, the needs and schedule of the end user work streams (i.e.: Finance, Sales, Marketing, HR, etc.), and the technical capacities to perform the work. Some companies elect to upgrade their systems on regular basis, others are more conservative and will upgrade infrequently if the system performance is acceptable.
Support Pack Considerations
Certain highly regulated industries require extensive regression testing of all BW processes after implementation of any support packs. Even companies that are not specifically bound by industry regulations should always consider some planned regression testing after any system change is introduced (i.e.: support pack, individual correction, SAP kernel updates, OS kernel updates, DB patch updates, etc…). Similar to the discussion surrounding “Upgrade Considerations”, a decoupled system approach allows timely support pack implementation for BPC without the need for extensive regression testing of the main BW system.
Many SAP BW customers are currently enjoying the benefits of speed enhanced processing provided by BW Accelerator (BWA). In an Add On approach, the BWA can very easily be extended provide performance enhancement for BPC. The Stand Alone approach requires additional BWA hardware to be installed since BWAs are typically setup to service a specific BW instance using a 1:1 connection between the BW instance and the BW Accelerator (reference slides 24-25 of http://www.sdn.sap.com/irj/sdn/bwa?rid=/library/uuid/3604c604-0901-0010-f0aa-b37378495537 ).
As discussed in the “Integration Development and Maintenance” section a Stand Alone approach will require additional data extraction configuration and maintenance. Most customers will load master/transactional data into their main BW systems for general reporting purposes. Following a Stand Alone process will require at least two sets of data to be generated (one for the main BW system, and a second set for the host BW system). When data is pulled into the BPC application a third set of data can be generated as well. All this data requires storage and has to be periodically backed up. In a high availability system, additional copies may also be generated by the mirrored backup systems.
- Creating and installing a “system copy” (i.e.: to establish a quality test environment) will be incrementally easier with Stand Alone approach. The copied system will be much smaller due to its segregation from the main BW processes.
- Data Manger is by design constrained to one BW instance (the instance upon which BPC is installed) , so the ability to create a master process chain to update all data will require addition separate steps for a stand-alone system. Additional BW configuration, such as additional staging cubes and the potential for redundant data with both BW systems should be anticipated.
This blog does not provide a final recommendation for one implementation path over the other. There is no best implementation path that can be generalized for all customers. The choice for Add On or Stand Alone should be thoroughly evaluated by your system architecture group along with project goals and appropriate cost considerations.