As enterprises embrace the operational simplicity and convenience of SaaS services, there’s been one major holdout. Classic back-office ERP systems have largely proven resistant to cloud migration because of the question of what to do with all the customizations? Back in the Y2K rush to modernize backend systems, typical practice was to put all the changes inside the core application code. And that’s why, a couple of years back, we posited that classic enterprise systems would be the last frontier for cloud adoption.

And that’s where we get to SAP. When it comes to ERP and similar back-office applications, nobody touches SAP’s footprint. According to the company’s own figures, 77% of the world’s transaction data by revenue touches SAP systems. While that doesn’t necessarily mean that SAP Business Warehouse (SAP BW) touches all that data, it still has an enormous footprint with operational reporting, and there are decades of code that’s just too costly and disruptive to change. And so, if you were an ECC or BW user who wanted to ditch your data center, your choice was managing your own deployments in AWS EC2, or the like.

Answer for the Installed Base

Last fall, SAP unveiled SAP BW Bridge, its SaaS answer for the classic SAP Business Warehouse (BW) installed base. SAP BW Bridge provides a way to re-platform to the cloud while keeping all the ingrained business logic and customizations intact. It creates a new workspace (“space”) on SAP Data Warehouse Cloud (DWC), with the goal of enabling the vast SAP BW installed base to lift and shift, taking the operational advantages of cloud deployment minus the disruption, or at least, the brunt of it.

Read More:   AIRGOGO WEBSITE

Supporting BW versions from 7.3 and later, BW Bridge is an environment inside DWC supporting the classic ABAP code and artifacts used in BW, operating directly attached to a customer DWC tenant. The good news is that BW Bridge takes advantage of an existing DWC to construct: the space. DWC was set up with the idea that different line organizations would want their own workspaces, so legacy BW environments may as well be one of them.

So that will allow the customizations that are typical of legacy SAP BW implementations, such as customized revenue reporting periods, to stay intact. It avoids the task of rearchitecting customizations that would otherwise be necessary for moving BW apps to DWC. In classic SAP apps (including BW), they were implemented in the core ABAP code, whereas with SAP cloud SaaS services, such as DWC, the base code is left untouched with customizations implemented as configurations atop it.

Not surprisingly, given that this used to be called BW Bridge, it keeps ABAP code intact. Customers can either just convert and migrate the metadata of their existing BW implementation (a “shell” conversion) or send both metadata and data itself (a “remote” conversion) to the DWC space target.

Developer Nostalgia Tour

But the flip side of maintaining the classic environment is that the development experience is a nostalgia tour back to an Eclipse-based environment, with a toolchain that is fairly complex sporting the look and feel of something out of the early 2000s. Data and processes are managed within a cockpit using Eclipse-based classic SAP data modeling tools. Connections to the BW on-premises source require the use of:

  • Smart-Data-Access (SDA), which instantiates read-only views of tables that are to be moved to the cloud;
  • SAP’s Operational Data Provisioning (ODP), the connector for legacy SAP systems, which performs the data extraction; and
  • DWC’s Data Builder, which imports tables into the DWC space.
Read More:   How Legacy Compliance Strategies Fail Cloud Native and How to Fix Them – InApps Technology 2022

Once BW data has been populated to DWC in its own space, customers can run their existing operational analytics and reporting programs, and they can also share BW data with other spaces via Cross-Space-Sharing. And sharing is not just limited to the BW Bridge space; data assets loaded into the BW Bridge space can be shared and transformed for use in spaces with the more modern DWC data models.

Data Acquisition and Staging

As currently designed, SAP BW Bridge is primarily intended as a data acquisition and staging layer — which has been the mainstay for BW. Other capabilities, such as planning, are outside the scope of BW Bridge; instead, SAP directs BW customers to SAP Analytics Cloud (SAC) Planning, which for now is a separate offering; later this year, SAP will add support SAC planning on top of DWC based data models.

The scenarios for SAP BW Bridge are, not surprisingly, centered around bringing SAP legacy data sources into the modern cloud data warehousing world. It could include those that want to replicate their existing BW environment and operational reports but in a managed cloud environment. And of course, it could involve migrating more modern BW/4HANA on-premises as well. And, as noted above, with cross-space sharing, BW data could be shared with other greenfield analytics, and mixed with data from other sources, developed in DWC.

SAP BW Bridge is an acknowledgment that, for classic or legacy systems to make it into the cloud, cloud SaaS providers have to provide more flexibility to accommodate the types of customizations that permeate legacy systems. That was the rationale behind AWS’s recent introduction of RDS Custom that gives customers control of more knobs for their Oracle and SQL Server implementations compared to AWS’s standard service.

It’s a careful balancing act, because at what point do customizations compromise the economics of scale in the cloud? That was what doomed the prehistoric generation of Application Service Providers (ASPs) that emerged during the ERP adoption wave of the 1990s. The going notion then was to unburden enterprises under the pressure to modernize systems for Y2K by at least having their ERP systems hosted. The degree of customizations for every customer made it too costly for service providers to offer meaningful savings.

Read More:   Update Software Engineers Use Spreadsheets; Data Engineers Use the Cloud

Guardrails for the Cloud

The solution in the cloud has been to put guardrails, such as the spaces that SAP has adopted with DWC. As noted above, SAP is appealing to the crowd of ABAP developers who’ve been maintaining BW instances. On the horizon, SAP plans to automate migration with a toolset that checks readiness of SAP BW and BW/4HANA objects (such as data transfer processes (DTP), DataStore objects, InfoObjects, transformations, process chains, etc.) and then automatically move those greenlighted.

That’s a good start. But of course, because we’re never satisfied, here’s our wish list. We’d like such a tool to also troubleshoot, and to the extent possible, automate fixes of objects into compliance. Actually, let’s take that one further. We’d like to see tooling that automatically replicates a snapshot of the existing environment, encompassing data and code, and automatically perform the necessary conversions to make the objects ready for moving. That’s with the notion that in the future, developers who are going to be charged with moving and maintaining BW instances, may not have the same ABAP skills.

Either way, SAP BW bridge is a good example of how to get those stubborn legacy systems into the 21st-century cloud.

Featured image via Pixabay.