There has been much discussion in the twitterverse, in blogs, on podcasts, and elsewhere I’m sure, about the place of SAP BW. Those discussions have really morphed over the last few months from the flurry of tweets over the perceived death of SAP BW at the hands of its little sister SAP HANA (now hopefully put to rest…or is it???), to the value for non-SAP ERP customers. In one of this year’s episodes of the Diversified Semantic Layer, one question we tried to tackle that and I’m just not sure we got to was: what is the value of SAP BW to SAP BusinessObjects customers? While we had a really great discussion, I think there is still more left there to uncover.
One of the things Steve Lucas drew us to, and later Ethan Jewett brought us back to, was the rift between BW-types and BOBJ-types in terms of utilizing their respective tools as a semantic layer. I think to tackle that rift, you have to take one step farther back. This is going to be an interesting topic I hope. Ethan and I have shot a few emails back and forth since that podcast and are going to each broach this subject from our own points of view in separate, yet connected blog posts. If you haven’t noticed, I am a BOBJ-type only because my number of years as a BOBJ-type dwarf those working with BW. I hold nothing against BW-types. We were just brought up a little differently if we didn’t already have BW in our organization. Will we bring it back to the podcast? Perhaps. But for now, read on.
The value proposition that has come out more recently is that SAP BW makes for a great, out of the box data warehouse. If you are an SAP BusinessObjects customer today not using SAP BW, you have either a) developed a ground up warehouse on something like Oracle, Teradata, etc., or b) have purchased some other 3rd party warehouse solution specific to your vertical. Neither of those solutions are wrong. But champions of the SAP BW platform have suggested that SAP BW is a candidate for this type of solution as well. Remember, I’m still back at the data architecture side of my random train of thought.
Knowing that, I don’t know many SAP BusinessObjects developers that also wear the hat of being a data architect. Yes yes I know you are out there. There are many of you. But I think the majority of organizations follow team models of data architecture, ETL, and business intelligence. Teams may flex and bend around those three key personality types, but it is just what you see predominantly. That said, knowing that when we talk about why SAP BusinessObjects customers should care about SAP BW, shops are going to fall into a few camps:
- I already have a warehouse, but hey, thanks.
- Warehouse? What warehouse? SAP BusinessObjects is used to mash up data from all over an enterprise.
- I’ve had SAP BusinessObjects and SAP BW singing along in harmony for years. It’s rough, but it works. I hope BI4 will make it better some day.
- I’ve had SAP BusinessObjects and SAP BW for years but never mashed them up. I <3 BEx 4 eva.
- What is SAP BusinessObjects?
I’ll be the first to admit that I’m not the sharpest knife in the drawer when it comes to SAP BW with only a few years under my belt. But I’ve actually worked with teams that run the gambit there on numbers 1 through 5. I’ve been on the “Oracle or nothing” project. I’ve also been a part of a project with a Fortune 50 company that literally had both SAP BW and SAP BusinessObjects for years and had never put the peanut butter and jelly together. But I do dig the effort of the two teams (BW-types and BOBJ-types) trying to figure it out and work together.
So with the stage set, why does the rift exist still? BOBJ-types are used to ultimate control. You have a table or view you wanted added? Suuuure. I’ll just put that in the universe and export, then you can drag/drop/slice/dice and have a sexy report. But that control has become a little disrupted.
I’ve been on a few projects now, integrating with SAP BW, where the Basis team, or some other BW dev team controls their semantic layer. What? They create their own views of their data and pass it to BOBJ. I can’t just scrape up a column from the underlying cube any time I want in these efforts. I have to explicitly work with that team to expose the data I want through cubes made available for reporting. Is that much different from abstracting a database table in a view? Well, yes, but in concept, no. A DBA has to update a view and expose a piece of data for me to build my universe against it. But I think the big difference is that SAP BW-types are all-too-familiar with exposing that data through a BEx query as that semantic layer for consumption by users, and part of the value of the universe is lost.
I have read thoughts of a BW-type that the new semantic layer in SAP BusinessObjects has no value to SAP BW customers. I’ve also met customers that have both SAP BW and Oracle or other data sources and welcome it with open arms in the right use cases and as a part of a broader semantic layer strategy.
So where do you fall? What do you do differently if you are being thrust suddenly into a world in which you have more tools to choose from. First, there is some essential reading. Ingo Hilgefort wrote a great presentation on selecting the right tool for the job and continues to give this talk around the world. You also have to put careful thought into where to go direct to BW or where universes in SAP BusinessObjects meet the needs of your business.
The fact that SAP BOBJ-types and SAP BW-types are each passionate about their own semantic layers is not going to go away. But we can certainly learn to work better together as these projects arise to understand the core requirement, the capability that each tool provides the user, and ensure that IT aligns to fulfill the requirement within that realm of capability of the selected tool.
In more recent news, Josh Fletcher and Ethan got together to start a new series over on DSLayer.net to get down and dirty with SAP BW for SAP BusinessObjects customers.
Over to you, Ethan.