Future of BODI ?

[chesl73]

If you go on the SAP website you can find product roadmaps for all the BO products.
DI is definitely here to stay and will continue to provide both SAP and non-SAP support. With the latest release of Data Services, the tight integration of both DI and DQ give the Data Services product a real edge over it's rivals.
SAP are also looking to integrate the DQ component into its Master Data Management (MDM) offering as well.
SAP used to OEM and partner with INFA for ETL but no longer and would also work with Trillium for any Data Quality work. Data Services will now be pushed by SAP to fill these gaps so overall, DI and now Data Services, will be around for a long time.
Also, the whole end-to-end BI sales pitch is used extensively by BO which is also a key driver in sales situations and getting rid of DI would drive a big whole in the overall product capability of the company.

[JeffT]

I genuinely post these questions with the utmost respect, but I think they deserve answers.

Question 1:
How long do you think that SAP will allow BOBJ to continue to operate as an independent business unit? Those days are numbered. Eventually SAP will merge the parts and pieces (and people) of BOBJ that they want to keep into SAP-proper (20%) and they will get rid of the rest (80%). This happens all the time (see ORCL-PSFT, ORCL-JDE, SAP-TopTier, SAP-A2i, etc, etc, etc). All software companies do this.

The BOBJ sales reps must know that their days are numbered and they need to make hay while the sun is shining - which is exactly why they are pushing BODI in all SAP accounts. They don't care that Informatica was chosen by SAP to be embedded within SAP MDM just a few short months before SAP acquired BOBJ and that now the SAP sales reps have done a complete 180* turnaround and are pushing BODI for their own financial gain.

Question 2:
Please use your analytical thought processes when looking at SAP's roadmap for BODI. If you really look at it, SAP is promoting you to use Netweaver ETL-like capabilities for R/3 sources and BODI for non R/3 sources. Why in the world would they think that an IT organization would want to support two DI/ETL tools just because they both have an SAP logo on them?

Further to this point, I asked this question to a long-time SAPer in Product Management (no offense Werner, but the BOBJ perspective doesn't hold much water to me), and the response was that SAP is waiting to see if BODI is a financially surviveable product or not before they make the decision to keep it or axe it. They were not as cautious with BOBJ reporting/dashboarding/EPM because those technologies were a clear market leader while BODI has always been a niche/challenger (per Gartner) and had low market share (~3% of the entire ETL market).

Werner even notes that only 10% of the R&D spend for BODI will be SAP-related. Isn't that proof enough that SAP is still waiting to see the viability of BODI in the marketplace? Werner, you seem like a good man, but I'd freshen up your resume if I was you.

Question/Point 3:
Notice the difference between Werner's posts in Feb vs. September. In Feb immediately after the acquisition was official, he was optimistic that BODI was going to be integrated into BI (circumventing SAP's API layer), that Rapidmarts were going to magically get migrated into BI-proper, that BODI would be a part of ERP migrations and MDM, etc. Then look at his perspective in Sept...a very light level of integration (only 10% of BODI R&D spend) with most of the "integration" between BOBJ and SAP being at the sales rep level.

Also, if you read the whitepapers on BODI for ERP migrations and MDM, they are almost word-for-word copy-paste from Informatica's website and IBM-Ascential's website. It looks like copyright infringement, truthfully.

Furthermore, SAP is NOT looking to dive head first into the ERP/data migration business. SAP quickly and quitely killed their "Safe Passage" program (ERP migration with partners such as Informatica and IBM) after TomorrowNow got them tied up in a collossal lawsuit with Oracle. SAP does not want to get back into the ERP migration business and risk further litigation. Larry Ellison already has SAP right where he wants them.

My assertion is that BOBJ is acting independently of SAP on BODI. By continuing to fund BODI and keeping it off of SAP's radar, John Schwartz is acting in his own best interest, not the long term best interest of SAP's customers. Do not bet on BODI's survival long term.

Lastly, using FirstLogic inside of SAP MDM for DQ is comical. FirstLogic has and always will be a customer-centric DQ tool (despite the UCM efforts, which are like putting lipstick on a pig). SAP MDM is a product master/PIM tool. How in the world is it that SAP plans to take a customer-centric DQ tool and use it to cleanse master data in a product-centric MDM tool (A2i)? Not to mention the fact that while SAP MDM sports a laundry list of customers who have purchased it, there are VERY FEW live implementations of SAP MDM - probably zero that were delivered on time and on budget because of bugs in MDM. A SAP consulting exec told me that SAP MDM is the hands-down worst product SAP has ever sold...and now they are going to repurpose FirstLogic to do product-centric data quality?

Don't drink John Schwartz' kool aid. Reason for yourself.

[wdaehn]

Interesting

But let's go through your points by priority....

1. I do light housekeeping tasks, would answer the door bell, I am generally nice to my employer, liked by everybody and I don't ly in a cv


2. When answering questions like those I have to be very careful. On the one hand, I'd like to tell all SAP customers BODI is the only ETL tool and soon will be integrated perfectly, the none-SAP customers that we are still a generic ETL with light SAP integration but all our development is focusing on pure play ETL. I would love to show you the list of things we are working on, on the other hand I am not allowed to say anything from a company policy perspective, a competitive reason and legal reasons (SEC rules). To cut a long story short, I am walking on ice here.


3. Let me divide the DI development team into three areas. SAP development, pure-play-ETL and DQ. SAP customer benefit from the SAP work we do and participate a little bit on ETL and DQ developments, e.g. if the engine is 10% faster it helps SAP accounts as well, when DQ is more powerful and used, it would help an SAP customer also. For a pure-play-ETL customer all the SAP related work we do is of no interest to them.
So the big question is, what the ration of developers on SAP related tasks vs. pure-play-ETL is. We doubled that ratio two months ago, from 4% to 8% of the developers working on SAP-only features. And it will remain this way. So this is actually bad news for the SAP customers, that the amount of resources we put into SAP features is so little. On the plus side though, we always have been strong on SAP and with little work here we can do a lot. Right now we streamline the BW load better, we will support more interfaces SAP provides.


4. I have spent quite some time at SAP and we compared the SAP NW ETL with the DI ETL capabilities, methods and functionalities. It was very obvious that DI is much more mature, starting from pushdowns, over Data Validation, partitioning support, bulkloader support, parallel processing, engine overhead. NetWeaver is completely built on top of the ABAP stack and you are limited there. As a result, we have three implementation options, keep DI a 3rd party tool to SAP with its own GUI; keep the NetWeaver GUI but replace the backend from ABAP to DI engine; merge the GUI so that BW dataflows and DI dataflows use the same GUI.
What development is working on is the first, the 3rd party level. SAP wanted to get to the second level and use the DI engine, you know, BW generating ATL and we execute it. But we quickly figured, to make sense you would need to add the DI transforms to the BW GUI and reinvent the wheel, so we will probably do level 2 (DI engine used in BW) and level 3 (merge GUI) in one step. (The backend will **not** get merged!)
And what would a none-SAP customer get? He will still have the DI Designer pretty much as it is today. But in addition he will get modelling help, e.g. if the DWH should support multiple languages, you have to build the star-schema that way yourself. In BW the datamodel is fixed, it is a Snowflake of some kind. So as soon as you say "Need multiple languages" and "I want a star schema", the DI Designer will let you chose to either have n-text fields, one per chosen language. Or you can say "support all languages" and DI Designer will create the text-lookup table for you as a template table or ......
If you tell DI Designer you column QTY is actually a Quantitiy measure with its Unit-of-Measure being the UOM column, you could ask the DI Designer to add the code that converts metric tons to kg, deal with non-additivity of "pieces" and "gallons" and "kg".
If you have monetary measures, the code to convert it to one or two common measures inside your fact table in addition can optionally get added for your.
If the source has a new column, you do not have to start SQL*Plus, add that column yourself, reimport the table, add it in all queries of the dataflow - the Designer can do that automatically or semi-automatic at least.
We merge the Data Integration tasks with Data Modelling and other options SAP BW brings in but remain open. Do not force users into the BW model, but offer their modelling techniques plus Star-Schema design techniques.



And finally a few thoughts on your questions
"How long do you think that SAP will allow BOBJ to continue to operate as an independent business unit?"

SAP had a deficit on BI visualizationand on loading none-SAP data into SAP BW. How much money would you have spent to solve that?
a) No money at all, Informatica, Ascential, BODI all can load BW and there even is an OEM partnership with Infa. And for the BI both, BO and Cognos do very well visualizing off SAP BI.
b) SAP wants the revenue itself. So spend a few millions on one of the few ETL companies like Kettle and you get BI as well. Or even better, jump on the boat with one of the OpenSource vendors and toot that message.
c) For some reason, SAP decided to spend not 10 millions but more than a billion. And what do they get? Okay a more mature ETL and BI tool, a brand name, a huge organization to integrate and a tool that supports the none-SAP market. By your statement they do not need the brand name, not the none-SAP market, not the many people BO has in sales. So spend 100 times more money for a more mature tool which is bigger and more difficult to integrate? That does not make sense.

"SAP is promoting you to use Netweaver ETL-like capabilities for R/3 sources and BODI for non R/3 sources. Why in the world would they think that an IT organization would want to support two DI/ETL tools"
That's the point where I failed. I wanted to have one BODI tool with level 3 integration as stated above. But that would be a too expensive feature to be done at once, need to go step by step, level by level.
And to be frank, these are two different people. The BW person knows all about ABAP and R/3. He might not even know what a relational database really is or what kind of SQL statements one can create or what data modelling is!

"BODI has always been a niche/challenger (per Gartner) and had low market share."
Gartner just added us into the market leader quadrant so that there is Infa, IBM and us. They did that because of the progress we made with the tool, with sales alignment, vision and because of what DI customers reported to them.


"Notice the difference between Werner's posts in Feb vs. September."
Yeap, reality did bite me.
MDM: MDM doesn't have any APIs other than Java. Using the DI Java Adapter SDK for millions of rows, in a end-user facing environment (User clicks on save-new-customer-record and MDM will popup with a list "Isn't that a duplicate with this record?"), with low latency? No, certainly not with the Adapter SDK. So we had to stick with a light integration only. MDM has to provide a useful interface first, before we can start the tight integration - in progress.
RapidMart: On track, but we need to be able in DI to consume the same DataSources like BW does - development is in progress on the SAP side. Once that is done we can change the RapidMarts. And for now, ABAP generation DI does is not liked by SAP but that's the only issue with them. Actually, we see a quite lot of RapidMart deals these days...
Migration: DI brings the flexible mapping into the equation but the key issue is SAP ERP has no high performance batch interface to load the data. Every record has to be checked by SAP ERP, it impacts multiple SAP tables, lots of exception cases depending on what kind of record loaded etc. And for Enterprise Integration via a Message Bus, there is SAP PI product which is well suited for that.

Aynthing else?

[rogerm]

Hi Werner

Thanks for the very informative update. Since your last post, three month are gone, are there any updates you are allowed to communicate on the integration road map?

Thanks, Roger

[wdaehn]

If only programming the ideas I have would be equally fast....

[srinivas_t]

[johnwxyz]

does BODI have future with the SAP takeover, i am thinking of getting some training on it