Down­load the full inter­view here.

Robert Her­nan­dez spent near­ly 20 years at SAP, ris­ing to Vice Pres­i­dent of Inno­va­tion Solu­tions, before join­ing Microsoft as a Prin­ci­pal Prod­uct Man­ag­er in 2021. His cur­rent role sits on both sides of the SAP-Microsoft rela­tion­ship: he over­sees a team of prod­uct man­agers in Wall­dorf work­ing with SAP on infra­struc­ture design for RISE with SAP, Busi­ness Tech­nol­o­gy Plat­form (BTP), and Suc­cess­Fac­tors on Azure, while coor­di­nat­ing co-devel­op­ment of offer­ings like Analy­sis for Office, Joule Copi­lot, and cross-plat­form sin­gle sign-on. 

In a con­ver­sa­tion with ASUG, Her­nan­dez laid out how SAP Busi­ness Data Cloud (BDC), Microsoft Fab­ric, and the Data­bricks part­ner­ship fit togeth­er for cus­tomers whose data extends well beyond the SAP estate, and made a case that iden­ti­ty man­age­ment, not secu­ri­ty archi­tec­ture, is the foun­da­tion most orga­ni­za­tions still haven’t laid. 

This inter­view has been edit­ed and con­densed for length and clarity.

Q: From your per­spec­tive, what is SAP BDC, and what prob­lem is it solving? 

BDC is SAP’s go-for­ward solu­tion for ana­lyt­ics across the SAP stack. SAP will use BDC to uni­fy infor­ma­tion across its Suite appli­ca­tions to enable end-to-end ana­lyt­ics. With­in BDC, SAP will deliv­er pre­built ​“data prod­ucts” for ana­lyz­ing busi­ness objects from its cloud suite. This enables uni­fied views of enti­ties that span appli­ca­tions — such as a cus­tomer across Com­merce Cloud and S/4HANA, or a ven­dor across Ari­ba and S/4HANA — by bring­ing those def­i­n­i­tions into a con­sis­tent data foundation. 

Many of the com­po­nents with­in BDC are capa­bil­i­ties cus­tomers may already have in place today, such as SAP Data­s­phere, SAP Ana­lyt­ics Cloud (SAC), or SAP Busi­ness Ware­house (BW). With most ver­sions of BW reach­ing end of main­te­nance in 2027, cus­tomers can instead deploy BW into BDC to extend its sup­port­ed lifes­pan while plan­ning a tran­si­tion to new­er capabilities. 

Q: BDC uni­fies ana­lyt­ics across the SAP suite. But what about cus­tomers whose data extends well beyond SAP? 

Data uni­fi­ca­tion across dif­fer­ent appli­ca­tions is a chal­lenge for many cus­tomers — espe­cial­ly as we talk about AI. 

That can only work if you have reli­able data across the enter­prise. SAP solves that for SAP busi­ness process­es with BDC, but what if a process spans mul­ti­ple sys­tems? Siloed, dis­con­nect­ed infor­ma­tion cre­ates a chal­lenge for humans to inter­pret, let alone for AI. 

I had a con­ver­sa­tion with a cus­tomer ear­li­er today, and he said, ​“Hey, Robert, 85% of my data is SAP data. I do not have a lot of data out­side SAP in my orga­ni­za­tion.” Well, I said, ​“Hey, you’re going to be one of those cus­tomers who wants to take that 15% and put it into BDC, because you’ve got all your SAP data in there already.

If, how­ev­er, you are like a lot of cus­tomers I talk to, who say, ​“Hey, my data is 50/50 or ⁶⁰⁄₄₀ SAP,” now we have to talk about how to bring togeth­er SAP with the rest of the data. Because frankly, my data grav­i­ty is not in SAP, but I need to bring it togeth­er with the oth­er pieces. And I real­ly want to be able to con­sume it with some of these tools. How do I do some of that?

Q: For those cus­tomers who need to go beyond BDC, what is Microsoft bring­ing to the table? 

We brought Pow­er BI into Fab­ric because peo­ple found that with Pow­er BI, it’s easy to ana­lyze, gath­er, and pull data togeth­er. In addi­tion to that, we cre­at­ed a capa­bil­i­ty called OneLake, which makes it a lot eas­i­er to uni­fy data from mul­ti­ple sources and mul­ti­ple loca­tions. I can bring togeth­er infor­ma­tion from dif­fer­ent loca­tions and var­i­ous sources and con­sume it with­in Fab­ric — with­in Pow­er BI, but then also with­in the Microsoft data stack for ML, fore­cast­ing, all those capabilities. 

With OneLake, not only do I have access to Microsoft data— data that exists in Azure — but I can also con­sume data that may exist in AWS or Google Cloud Plat­form (GCP). We can con­nect to that data in GCP as if it were in Microsoft, with­out hav­ing to pull that data across. It real­ly becomes this nexus point where I can bring togeth­er infor­ma­tion across my enterprise. 

Q: What is the piece of this puz­zle that cus­tomers tend to overlook? 

Peo­ple under­es­ti­mate this com­po­nent: the first piece you must think about is iden­ti­ty. Even before I start talk­ing about secu­ri­ty, I’ve got to talk about iden­ti­ty, because while those two seem sim­i­lar, they’re actu­al­ly two dif­fer­ent con­cepts that you need to bring together. 

I can go out there and cre­ate secu­ri­ty, roles, autho­riza­tions, and per­mis­sions. But if I do not know who you are, it does not do me any good to cre­ate that. 

This has tripped up so many of our cus­tomers who have tried to deploy AI as well. They say, ​“Hey, Robert’s logged into Copi­lot or Teams, and he’s try­ing to con­nect over to Joule, or he’s try­ing to con­nect over to the back-end source sys­tem,” and when it pass­es my ID from Copi­lot to what­ev­er, if that thing can’t asso­ciate that user ID across both, you’re going to stop right there, and the process is going to break down. And it will not be a sit­u­a­tion where I get access to things I should not; it is where I do not get any access. 

Peo­ple under­es­ti­mate this com­po­nent: the first piece you must think about is iden­ti­ty. Even before I start talk­ing about secu­ri­ty, I’ve got to talk about identity[…]

We want to be in a sit­u­a­tion where, as much as pos­si­ble, we dri­ve the authen­ti­ca­tion back into that source appli­ca­tion. That is not always pos­si­ble. I had a cus­tomer who was join­ing togeth­er SAP data and some IoT data. The prob­lem is, to bring those things togeth­er, they had to trans­form them, because the def­i­n­i­tion­al ele­ments that came out of SAP were not con­sis­tent with their well­head infor­ma­tion that they were get­ting from their off­shore plat­forms. In that case, we need­ed a dif­fer­ent secu­ri­ty mod­el in Fab­ric because def­i­n­i­tion­al­ly, I could not bring those things togeth­er at the lev­el and ele­ment that SAP secured and autho­rized it. 

The goal would be to push that autho­riza­tion back down to the source appli­ca­tion if I can. But even if I do, I need to think about: is my user ID the same across those two? Do I have sin­gle sign-on authen­ti­ca­tion? I am with Microsoft, so take it with a grain of salt, but do I have Entra ID? Do I have that same ID, that same user across all those applications? 

If I do, my life will be pret­ty easy. If I do not have that same ID, that same user across all those appli­ca­tions, then it is a night­mare just to try to get the sys­tems to talk to each oth­er. That is one thing that you aren’t think­ing about right now, if you want to try and do one of these projects, and you should think about lay­ing some of that ground­work before you do.

Con­nect with Robert Her­nan­dez on LinkedIn. 

Q: Where does Data­bricks fit into this, and what does the Microsoft-Data­bricks part­ner­ship mean in practice?

When I deploy Data­bricks with­in Microsoft, Microsoft treats Data­bricks as a first-par­ty prod­uct. When you get the bill, it comes in as a Microsoft prod­uct. You would be hard­pressed, if you cov­ered the name Data­bricks, to rec­og­nize that what you are deploy­ing is not actu­al­ly the Microsoft offering. 

Data­bricks is impor­tant as we talk about inte­gra­tion with BDC because SAP launched a tight part­ner­ship with Data­bricks, includ­ing the con­cept of Delta Shar­ing. There are a cou­ple of dif­fer­ent ways to bring Data­bricks togeth­er with BDC. One option is SAP Data­bricks, which runs with­in your BDC sub­scrip­tion. If you do not have Data­bricks yet and want more advanced AI capa­bil­i­ties along­side SAP data in BDC, that is one route. 

At Microsoft, since we have such a big Data­bricks foot­print, we have been hav­ing more con­ver­sa­tions with cus­tomers who already have Data­bricks up and run­ning. They have the stand­alone Data­bricks, or what we call native Data­bricks, and that has more func­tion­al­i­ty and capa­bil­i­ty than the SAP Databricks. 

SAP has this func­tion­al­i­ty called Delta Shar­ing, where I can take data that is loaded into BDC. I do not copy the data over to Data­bricks. It remains with­in BDC. But via Delta Shar­ing, I can view that infor­ma­tion that is stored in BDC, and I can use it as if it were res­i­dent with­in Databricks. 

If you do not have Data­bricks today, you have to fig­ure out which route to go. A lot of the extract/​transform/​load (ETL) to bring the data in is turned off in SAP Data­bricks. If you need those capa­bil­i­ties for the non-SAP data, you need to go native. SAP Data­bricks may be eas­i­er if all you need are the fea­tures and capa­bil­i­ties that come with it. 

Q: Once you con­nect Data­bricks to BDC, can they under­stand the SAP busi­ness seman­tics, or are you just mov­ing raw data? 

What they will do is read the data prod­uct def­i­n­i­tion out of the BDC sys­tem. When you start talk­ing about seman­tic mod­els, this is where it gets more nuanced. If you think about SAP, you want to do things like cur­ren­cy con­ver­sion, or unit-of-mea­sure con­ver­sion, or you want to think about fis­cal cal­en­dars ver­sus cal­en­dar cal­en­dars, all those sorts of busi­ness seman­tics. If I want to con­sume that via Pow­er BI, the ques­tion is not just whether those data prod­ucts exist, but how can I con­sume them in a way that Pow­er BI can under­stand those elements? 

When you start think­ing about how you are going to report on this data, it comes down to use cas­es. If I am report­ing SAP data and talk­ing about SAP finan­cials, I may want to uti­lize BDC and SAC and the intel­li­gent apps that come with SAP. Those are spe­cial­ty-built tools, capa­bil­i­ties, and visu­al­iza­tions for the SAP com­mu­ni­ty. If I am a cus­tomer who runs Ora­cle Finan­cials and SAP Finan­cials, and I need to see the uni­fied busi­ness, then I am going to have to fig­ure out a dif­fer­ent approach.

Q: What does Microsoft offer to the cus­tomer who is run­ning SAP along­side Ora­cle, Sales­force, or Dynam­ics and needs a uni­fied view? 

This is one of those places where Microsoft, with our expe­ri­ence across a lot of these appli­ca­tions, is look­ing at bring­ing capa­bil­i­ties togeth­er for cus­tomers run­ning mul­ti­ple appli­ca­tions. In Fab­ric, we have brought togeth­er five busi­ness func­tions. We have brought togeth­er the var­i­ous enter­prise appli­ca­tions so that you can uni­fy those togeth­er: pre-built data mod­els, pre-built data flows, pre-built data map­ping, all con­sum­able with Microsoft Copilot. 

I can con­sume that data via Copi­lot in Teams, say things like, ​“What are my top five cus­tomers by rev­enue?” This is not to replace a dash­board or report, but if I have that data in Fab­ric, I can con­sume that via Teams, via Word, via Pow­er­Point, and bring that data together. 

Q: What are the options right now for get­ting SAP data into Fabric? 

You have a cou­ple of options right now. One piece we have is called Mir­ror­ing for SAP. That’s in pri­vate pre­view, where we mir­ror data from your SAP ERP sys­tem into Fab­ric. We also have a list of cer­ti­fied third par­ties that can load that data into Fab­ric. And then we have Data­s­phere repli­ca­tion flows, which can be writ­ten into Microsoft as well. I hope to be able to add Delta Shar­ing to bring the data togeth­er. These approach­es all copy data. 

Q: Get­ting the data into Fab­ric is one thing. How do you ensure Pow­er BI can make sense of it? 

SAP has its way of defin­ing data, and some of it is in the data mod­el, and some of it is in busi­ness log­ic. If I want to have the out­come, but I need it in Pow­er BI, I need to trans­late that SAP-ese into Pow­er BI-ese, if you will. That is what that com­po­nent is doing — tak­ing that data from SAP but trans­form­ing it in a way that Pow­er BI can con­sume, keep­ing the busi­ness seman­tics correct. 

The same is true for Ora­cle and for Sales­force. That’s one of the pieces that we’ve invest­ed in, because I have so many cus­tomers who run SAP and Ora­cle, or SAP and Sales­force, or SAP and Dynam­ics, and what I don’t want is a sit­u­a­tion where every sin­gle one of those cus­tomers has to rein­vent the wheel. 

Vis­it the Microsoft web­site. 

The idea would be that if I am run­ning Ora­cle Finan­cials and SAP Finan­cials, they come togeth­er into a sin­gle place. A sin­gu­lar mod­el across. My goal is not to have an Ora­cle Finance, an SAP Finance, a Dynam­ics Finance; that does not help any­body. At the end of the day, it does not mat­ter if I am 50% SAP or 50% Ora­cle or ⁶⁰⁄₄₀; I need to bring those togeth­er to a uni­fied finan­cial view across the enterprise. 

Q: When you are pulling finan­cials from SAP and Ora­cle into a sin­gle mod­el, how do you rec­on­cile back to the source? 

Well, here is the thing: it all must go into the same mod­el any­way, because who demands it? Wall Street. That is who I must deliv­er the uni­fied finan­cials to. It does not mat­ter what sys­tem it start­ed from. At the end of the day, if I can­not pro­vide rec­on­ciled finan­cials, my CFO goes to jail. It is not just about indi­vid­ual source sys­tems. It is about the over­all out­come of bring­ing it all together.