Multiple BW Instance question

Question

Getting lost wading through the plethora of information available, so any direct pointers to information that directly addresses the following would be appreciated, in addition to any direct answers of course!
Consider a multiple BW instance, with a staging layer, and integration layer, and multiple analytic layers (one large one, and a couple smaller ones that operate at different service levels).
If we upgrade staging to 3.5, do all the rest have to tag along (staging feeds integration and one other, integration gets data from staging and feeds all the rest).
If we upgrade to 7.0, or whatever they are going to call it, will every system have to upgrade, or are the BW to BW connections backwardly compatable.
Major reason for considering this architecture is the ability to have a couple target BW's at higher or lower releases/service pack levels as warranted by the specific applications using them (e.g. SEM wanting SP's faster than the uber BW can test and apply them).   However, if we have to keep all systems in synch, then this is NOT a viable option.
Mark Marty
EBIS Architect
Mckesson

Answer 1

This is based on some work being done by another member of the Terabyte club, and we have similar sized landscapes.
The key concerns are, with a single instance of BW, and ~ 10M rows of raw transactions migrating into the system each night (SD - BO, DD, SO's, MM, COPA, it all adds up), it is not clear to us that BW could handle all data rationalization, transformation and dissemination tasks. We have significant legacy transactions and master data that needs to be merged with a good portion of the R/3 data.
In our current environment, 90% of this is done outside of BW, using Datastage and a Data Provisioning Area.  Even with sending only clean, merged, ready to load to target data, our load windows are increasing, and our backup window is scary.
This new effort is an attempt to separate key data needs so that certain things that need to be more responsive can be made available earlier.  Additionally, this landscape is going to test out and prove or disprove the ability to do this volume of ETL wholly within a BW environment, rather than leveraging on other marketplace tools and techniques.  Needless to say, this is a hot topic, internally we have a slant towards best in breed, and consultatively everyone wants it all to be the SAP suite of tools.   Hence, we will build it and see.
Splitting Staging from Integration is not necessary (likely) from a purely technical need, however it has proven useful at another company, and we are going to explore it and determine the efficacy ourselves.