“Developing in SAP BW is rubbish”. This was the statement made to me by a colleague who felt that with the evolution of in-memory capabilities provided by HANA, then HANA Enterprise would be the “natural choice” for an EDW solution. It was further argued that the agility in development within HANA Enterprise gave it an apparent edge over development in BW. I wanted to get a further understanding of what I considered to be potentially game-changing statements. Game-changing in the sense of impacts for clients and solution implementers alike, i.e. As well as the standard points around SAP licensing, hardware and infrastructure, what about the aspects of information and data governance strategies – are they still relevant, retraining of developers from BW to HANA, change control processes and release management approaches?
I’m not going to tackle all of those elements within this blog (that’s potential future material), however, as I questioned my colleague further regarding this statement, I initially focussed on a bottom-up comparison of technical capabilities. My colleague has worked on a project which had BW7 on an Oracle DB and they had migrated to BW7.4 on HANA. So the standard migration provided the capability whereby InfoCubes and DSOs were in-memory and were able to generate SAP HANA Views. In parallel, he had access to a HANA Enterprise system in which he was utilising SLT and SAP BusinessObjects Data Services. It was at this point that I had to stop him as I could clearly see the underlying key factor for his statement.
His view of developing in SAP BW was based on continual development of the migrated configuration which was based on the “classic” pre-HANA Layered Scaleable Architecture (LSA) approach, i.e. dividing the reporting business view of information from the source data and the layered persistence of data objects to reflect structural and information changes as it flows up the final view. (See Figure 1)
Figure 1: Classic LSA Data Flow
When compared side-by-side to modelling in HANA Enterprise (See Figure 2).
Figure 2: Comparison of Data Flows
It would appear to add weight to the argument that developing in SAP BW is “rubbish”. The reasons being the SAP BW development would consume more time and effort and with greater impacts in terms of ensuring reconciliation between the various layers. If the flow was already live and the development was due to a change request it would be considered even more expensive: For example the change required was to include a new field from an underlying SAP ECC Table into a transactional data source. From a SAP BW perspective this would involve:
1) Changing the SAP Extractor on ECC.
2) Possibility of including custom code to ensure population or delta handling of the field.
3) If the field is a characteristic object then possibility of creating attribute and text datasources as required.
4) Replicating the datasources into BW
5) Creating an infoobject (and potential attribute infoobjects) that would be the target for the newly added field and it’s attributes
6) Adding the field to infosources, DSOs, InfoCubes and MultiProviders as required and re-activating objects. Being wary of whether data has to be deleted from the targets or not (depending on the assumption of whether that field is to be filled with historical data or not)
7) Amending transformations and re-activating as appropriate (depending on step 5 as to which transformations have become de-activated).
8) Re-activating Data Transfer Processes to allow data to flow.
9) Updating process chains to include new attribute and text flows if required.
The above does include the overhead of transports and cutover to quality or production environments, but every organisation should have a change board and approval process which would approve the movement of configuration through the landscapes. In addition, if this type of information required an outage, then that has increased the effort and complexity elements for developing within SAP BW.
In comparison, the HANA Enterprise approach seems considerably lightweight:
· Stop replication
· Update a couple of calculation views
· Update a couple of stored procedures
· Re-replicate the data via SLT
And hey presto – the development is complete. The migration of the HANA config is also considered more straightforward than the application of BW transports.
But wait a moment….as I mentioned at the start the BW is on a shiny new HANA database, so why are we still thinking in terms of “old” world BW development? Why hasn’t the flow been re-engineered to leverage the HANA capability, reduce data persistency and proliferation, why, why, why?
My opinion is that the dataflow could be re-engineered to be more HANA-fied (See Figure 3)
Figure 3: Leveraging HANA Capabilities in BW
The above has not yet even begun to take into account the use of Open ODS Views, Advanced DSOs, Open Data Provisioning Framework, SLT’ing in BW on HANA or even the HANA Modeller within BW on HANA which affords even more favourable advantages when just considering HANA Enterprise.
An extreme example I grant you, as I can hear you murmuring about “depends on complexity” etc etc, but the point is: A BW on HANA dataflow (not a BW dataflow), could arguably be developed, tested and productionised in timelines which are now more comparable with developing dataflows in HANA Enterprise. In addition, there are still some tricks that BW on HANA has up its sleeve that to try and reverse engineer into HANA Enterprise would be considerably more painful such as dealing with time dependent master data, treatment of non-cumulative key figures and even Planning!
The upshot of the above is simply to point out that although many organisations are migrating their BW to a HANA platform, they are effectively performing a “lift and shift” which invariably involves DSOs and InfoCubes being HANA Optimised, but missing the bigger opportunity of considering how a dataflow could be re-engineered to leverage full HANA capability and the subsequent advantages that this could bring.