SAP BW4/HANA, under the covers.

Jan van Ansem lifts the sheets in a tell-all exclusive with Cal Loudon and dishes the pillow-talk on what an SAP BW/4HANA implementation is really like.

Back at the writer’s desk again but this time for the mothership on blogs.sap.com instead of my usual home on the Bluefin website. And Since we last caught up at TechEd in Vegas, a lot of things have happened – Lumira has transitioned again, Kim Kardashian had another baby, Altiscale now wants to be called SAP Cloud Platform Big Data Services (what a mouthful!), Kendrik Lamar won a Pulizer for Damn and I’ve moved to Germany where I’m extremely fortunate to be working on one of the hottest BW4/HANA projects going on.

I’ve had the privilege of interviewing my esteemed friend and colleague Jan van Ansem  who’s also on the project, and asked him about his first-hand experiences implementing BW4/HANA. What’s it like? What are the potential pitfalls? How does it compare to other SAP BW migrations? All will be revealed – let’s jump straight into the questions!

Cal Loudon (CL): You’ve been involved in a great number of BW projects, but you’re currently on your first greenfield BW/4HANA implementation – what would you say you’ve noticed as being the biggest difference compared to that of a BW or BWoH project?

Jan van Ansem (JVA): The customer for whom I am currently implementing BW/4HANA really understand that BI projects can now run in a different, more agile way. SAP BW/4HANA is a great enabler of working in an agile way, you can sit down with the business users and look at the data from day 1. You start with a simple model and play that back to business users and, as you go along, you refine and expand your model. That is a great way of working; it ensures business user buy-in and the adoption rate of the solution will be much better as a result.

CL: I know you always try to stay up to date with the latest changes, but were there any specific areas you found yourself needing to upskill on to help you with this unique project approach?

JVA: With many of my past projects requiring some ABAP, programming isn’t new to me. But the switch to SQL and SQLScript when writing AMDP procedures for transformations and table functions (which interestingly have largely taken the place of SQL Calculation Views) was definitely a change. Luckily SQL has been around for long time and I’m had my fair share of exposure to it, so this wasn’t too much of an issue. There are some slight syntax changes but the HANA SQL Reference guide is very comprehensive.

CL: I’ve noticed that even the inbuilt help within HANA Studio can be quite handy. Shocking I know.

Implementing BW/4HANA is a completely new process, with very few customers having first-hand, let alone productive experience with this technology. Did you experience any teething issues at the start or were there any persisting issues you want to mention?

JVA: Okay then, just between you and me, there were a few issues when we just started the project back in Q1.2017. Most of them were resolved very quickly by SAP; the messages we raised we could really tell how much of a priority BW/4HANA is for SAP. In the ‘now resolved’ bucket fall (in no particular order): problems with Error DTPs and the ability to modify data in error stack; reporting on non-cumulative key figures. We are also still using a workaround for issues related to the use of the Multitenant Database Containers (MDC).

One of our unresolved issues is with the DTP package size when using Semantic Groups. SAP have advised that there is a solution in SP08 but we haven’t had a chance to patch our system yet. Hopefully the MDC related issues will also go away with SP08.

CL: How have you found working (almost) exclusively in HANA studio compared with developing BW via SAPGUI?

JVA: Obviously the Eclipse-based HANA Studio is much ‘prettier’ in terms of aesthetics but that’s not to say it’s a complete improvement. There are some regularly performed processes which have a very different approach to what we were used to in the old GUI.

CL: I can attest to that. It took me an embarrassingly long to find the Manage DSO screen!

JVA: I also find that HANA Studio requires a substantial amount of system resources and a big screen to use effectively. I’m lucky to be using a very powerful laptop and have a dual-screen setup so it’s working nicely right now. Obviously only relating to Native HANA development, but I’ve also had some interactions with the WebIDE and XSA  and I definitely prefer the former. In fact, there are situations where I far prefer the WebIDE over within Studio – creating Design Time Roles is a perfect example. We can use the GUI modeller in the WebIDE to make hdbroles where otherwise we’d be forced to write code and remember syntax. All that aside however, it is a very powerful tool which, when you’re used to it, enables an almost all-in-one approach to most BW tasks. It also allows you to seamlessly transition to and from Native HANA modelling and administration. That’s super handy in a BW/4HANA landscape.

CL: What are you looking forward to in the latest Service Pack (08) and what would be in your wish list for future SPs?

JVA: Wow, where to begin? So much cool stuff is coming with this latest service pack. For a start, and despite my previously described issues with it, I really like that there is more BW functionality performed directly in HANA Studio – rather than in an embedded ABAP frame – specifically Transformations and DTPs. The Web Administration for Process Chains and object maintenance looks like it’ll be useful from day one too.

Ultimately though, I like to have a single interface, without the hassle of client tool installation. Web based IDE for BW/4HANA is high on my wish list. From a modelling perspective, I would like to have an easy way to include calculated columns and key figures in my Composite Provider. Even for simple functions, I now have to put a Calc View between my ADSO and Composite Provider in order to use HANA functionality. If I could just use some HANA functions directly in the Composite Provider, I would not need to create this additional layer.

From a business functions perspective, top of my list is more support for GDPR requirements. HANA 2.0 offers data masking, which is great, but does not integrate with BW/4HANA. Data masking is only part of the tools required for getting a Data Warehouse GDPR compliant. There is much more that could be delivered out of the box.

CL: Looking ahead to your next Bluefin BW/4HANA project, if you had a customer with an existing SAP BW landscape – would you suggest that they complete a greenfield like you’re doing now, or would you guide them towards an upgrade path?

JVA: There is not an answer that suits every customer. If you have kept a tidy house and are reasonably up to date with your BW implementation and just want to benefit from, for example, better Hadoop integration, then an upgrade could work well. If you have lots of obsolete objects and a data warehouse which has organically grown, then a greenfield implementation might be a better option.

CL: Good answer. I’m also heavily in favour of the Remote Conversion option which allows for a part, say a specific functional area, being independently upgraded into its own brand new greenfield implementation. I think this gives customers the opportunity to flexibly see and taste the power of BW/4HANA and experience the value it’ll add to them and the rest of their business.

When you think about the idea of establishing a Big Data Warehouse vs an Enterprise Data Warehouse – or even a ‘Mixed’ Mode Data Warehouse, such as you’re doing now with taking the best parts of Native HANA and BW – do you believe there is one “right” way of approaching the Data Warehouse challenge?

JVA: I think a clear indicator is to look at the variety of data sources that your business users require for their reporting and advanced analytics functions. If your business users are happy with reporting based mainly on data which comes from SAP ERP and other SAP systems with a ‘native’ integration to BW/4HANA, then BW/4HANA is still a great platform. When other sources become more important, for example sensor data or social media, then you are much better off with a combination of HANA native capabilities for integration and embedded advanced analytics and BW/4HANA.

CL: Given SAP’s current love affair with “Simplification” and as such BW/4HANA is a ‘simplified’ version of SAP BW (i.e. the number of modelling objects is reduced). Is there anything you think shouldn’t have been cut?

JVA: Perhaps one thing – the Persistent Staging Area (PSA). Not that I liked the PSA so much, but it acted as the integration layer for tools like SAP Data Services. Moving to BW/4HANA from a BW implementation which uses SAP Data Services is not as straightforward now as I would have liked this to be.

CL: I definitely agree with you there. I did like having the option of switching on the PSA in BWoH, at the very least for debugging purposes.

Ending on a sombre note and I’ve got some tissues here, so please be honest – do you miss BEx? Do you have anything you’d like me tell her for you?

JVA: BEx is a product with a great history. It was incredibly rich and capable of doing very complex BI reporting. It also relies on what is now very old technology and obsolete for business users, as the BOBJ toolset is much more capable at providing the right toolset for the right use case. From a developer’s perspective, BW Queries in HANA Studio offer the same flexibility as BEx. So, in short, I don’t miss it but I would like to make a case for getting it included in the Hall of Fame, somewhere in between floppy disks and WordPerfect 5.1.

CL:  Aw that’s nice, so you can still be friends.

Well thanks Jan, this has been enlightening and I think it’s clear that, while BW/4HANA is definitely the way of the future from a Data Warehousing perspective, it still has a lot of room to grow and improve. But who’s perfect, right? As always feel free to reach out to Jan or myself, or in fact any of my other Bluefin compatriots, if you have further questions about BW/4HANA. We’re always happy to chat.