A 3rd Technology for Your Data Platform - Case Study

Considerations on technology mix for data platforms

The following approach was already discussed at a former state here. Now several aspects are still discussed. The focus today is on the question should a 3rd technology - Microsoft Azure / Fabric - added to the holistic data platform approach.

Currently the concept is focussed on SAP, with SAP Datasphere as successor of the former SAP BW and AWS, the cloud platform used to build applications but including also data management / local data platform approaches. If they work together, the have a good fit of prefered capabilities:

Fig. 1: Data Capabilities of different platforms for best mapping of Data & AI needs

The following picture shows situation, typical challenges and some considerations about adding a 3rd technology for the “Data Platform” approach.

Fig. 2: Overview Situation and Challenges of the current Data Platform setting

Basically we evaluated different broadly discussed perspectives as follows to get a better understanding of possible strengths and weaknesses and a foundation for discussion:

Fig. 3: Comparing different technologies on common criterias

Such evaluations are necessary for a better understanding. But finally it wil lnot really show a differentiation. Every vendor have advantages and disadvantages but overall the basically can do most but not everything. And just something is possible, it doesn’t mean that it is easy or inexpensive. Therefore having more than one single vendor in your ecosystem is typically. And I see it more and more common especially for Best-of-Suite offerings like SAP. SAP optimizes on the own SAP ecosystem but is maybe not on top with every capability.

Some considerations especially for SAP:

• AWS is currently not part of the current SAP Data Partner Ecosystem, supporting native hyperscaler capabilities in SAP Business Data Cloud or zero copy between the platforms. They are partnering in different aspects like virtual access and data federation. AWS is also a typical hyperscaler for solutions like SAP Datasphere and SAP Analytics Cloud here in Germany.

• Microsoft Fabric has anounced SAP BDC Connect for Q3/2026 while connectivity to Azure services is already available in a similar way like AWS.

• Databricks could build a more agnostic bridge to the different platforms as it runs everywhere and is already well integrated with SAP Datasphere and even deeper integrated with SAP Business Data Cloud.

• In this customer case, the future outlook on SAP Business Data Cloud and AI usage via SAP Joule is an interesting aspect. Furthermore the S/4HANA system will have SAP Analytics Cloud as standard analytics tool for operational reporting.

Now, does it make sense to use Microsoft Azure as a supplementary solution within the context of a data platform? An additional platform ≠ additional capabilities, but rather additional integration efforts.

It is important to understand Azure / Fabric adds another comprehensive data platform:

• separate storage (OneLake)

• separate catalog (Fabric / Purview)

• separate security logic

• separate compute abstraction

• separate operating mode (SaaS)

Possible consequences:

• Data duplication (S3 ↔ OneLake)

• Semantics – Operation (Datasphere vs. Fabric Model)

• Governance fragmentation

Further considerations:

• Hidden additional costs due to duplication

• Skill fragmentation & greater dependence

• More complex governance and security

• Longer time-to-value for new use cases

• Power BI does not justify the need for an additional data platform

Essentially, both platforms (AWS & Azure) offer comparable capabilities, and certain aspects of one platform may have slight advantages or disadvantages compared to the other. Overall, no real distinction can be made between them.

The main advantages of not using Azure are:

—> A clear strategic commitment to an AWS-first approach ensures greater efficiency in decision-making processes and strengthens the organization’s ability to work with AWS.

—> The fact that projects have already been implemented and are running on AWS presents a barrier to switching, as, depending on the extent to which proprietary solutions are used, a certain degree of platform lock-in arises, which can only be overcome by investing significant effort.

—> For Azure Second, it is recommended that you clearly define which services are used on Azure and how your individual platform strategy should be shaped.

---

Overall strategy always means to decide what not to do. The discussion here can be complex. How would you decide?