The open nature of SAP Datasphere’s architecture is very much like Sergio Leone’s epic spaghetti Western film, “The Good, the Bad, and the Ugly” for no reason other than how some designs can be described as such.

One of Datasphere’s biggest strengths is the flexibility and speed with which a new solution can be built. From the initial replication of SAP tables to an Analytical Model ready for consumption, the development time is a fraction of prior efforts. Unfortunately, these same strengths when unharnessed can lead to an excessive number of objects that will clutter and ironically slow down development.

If you’re considering SAP Datasphere as a BW replacement or if you’re already kicking the tires with a pilot project, this quick guide can help save you months of rework.

The Issues

• Production models using Development data
• Transports of objects between spaces break
• Navigation and development become a chore

If you’re considering SAP Datasphere as a BW replacement or if you’re already kicking the tires with a pilot project, this quick guide can help save you months of rework.

Throughout my experience working with SAP Datasphere implementations, I’ve encountered limitations of the common, initial setup (The Bad) and worked through the growing pains of architecting the landscape to a scalable design that accommodates multiple teams and lines of business (The Good).

The First Design – Initial Approach

• 1-tenant
• 1-space per environment

Your initial design might look like this, which isn’t all that bad, but there is a better approach that I will explain later in the guide.

This design is a simple concept to understand. The development objects are drafted in a Development space (DEV). The refined objects are imported and tested in a Quality Assurance space (QA). The approved objects are reviewed and imported into a Production space (PRD).

This approach isolates the objects based on their maturity along the development, testing, and approval process. It also helps the technical team to explore the core SAP Datasphere concepts, such as graphical versus SQl views, relational vs. fact, dataflow vs replication flow, and so forth. It’s a good start.

The First Issues

Things started out ok, but we started running into trouble, during the promotion or “transport” of objects between spaces.

Because each space uses a different database schema, we had to take special care when exporting the CSN file that contained our object definition. We needed to manually edit the source space technical name via a text editor before importing it into the target space.

Additionally, we sometimes found objects in the Quality Assurance or Production space were referring to objects from the Development space. Unraveling the references became a pain point in our architecture.

This issue was compounded as our scope grew and required additional coordination across multiple teams. Several key questions emerged:

• How could we ensure that the business analysts didn’t change objects that were already developed and tested by the IT team?
• How could we define security so that only approved personnel could view sensitive information?
• Would everyone follow the same approach for development, testing (quality assurance), and production?

Our SAP Datasphere architecture had to be flexible and adapt, while at the same time meeting the needs of a growing IT team with the addition of new business groups and their requirements. The number of mistakes increased as the teams grew. We had to find another way.

The Second Design – Our Revision

• 2-tenants (PRD and DEV/QA)
• 1 inbound-space
• 1 modeling-space

Our second design of the Datasphere Space architecture separated the inbound tables into their own space.

This design allowed us to refine the role of the modelers, separating the ones who were developing the master data dimensions and relational datasets apart from those who had additional access to maintain system connections and monitor data flows and tasks chains. This can be considered an IT-centric approach: more data engineers from the IT team were brought on board to help with the workload. Additionally, roles and responsibilities could be defined by the activity in the associated space.

With a second SAP Datasphere tenant, the transport process to the productive environment was much smoother since we no longer had to manually edit CSN files and could simply export/import from the source tenant to the target tenant. Another benefit achieved was that we no longer faced issues with mixing Production and Development objects because the objects now belonged to different tenants.

I imagine that most teams stop here, and that this approach works well for IT-centric organizations where the data engineers are responsible for most if not all of the data modeling in Datasphere. This approach also allows the larger group of data engineers to focus on building the data models while a smaller group maintain and coordinate the data loads as not overwhelm the environment.

The Third Design – Our Current Architecture

• 3-tenants (PRD, QA, and DEV)
• 1 inbound-space
• 1 modeling-space
• 1 admin-space
• n business-space

Our third design of the SAP Datasphere architecture grew from the initial success of our reporting and data project.

The business teams were excited with their new dashboards and the speed at which our team was able to deliver new models.

The business teams were excited with their new dashboards and the speed at which our team was able to deliver new models. However, the demand from the business community quickly exceeded our team’s ability to deliver due to the volume of the requests. Around this time, a concern about data sensitivity especially around the company financial information became a major focus.

The Admin Space allowed us to define row-level security via Data Access Controls (DAC). Once defined, these objects could be shared to the Modeling Spaces. Very few people on the team were granted access to maintain objects in the Admin Space.

The Modeling Spaces remained the same, for the most part. Data engineers continued to build their propagation views and fact views, maintaining the relationships and semantic enrichment. What changed was the omission of Analytic Models.

When ready, the fact views were shared to the Business-Owned spaces. This allowed the business analysts to further refine the models for their specific needs, such as adding custom restrictive measures, calculations, or aggregations.

This 3-layered approach (inbound, modeling, and reporting) allowed the data engineers who were familiar with the source SAP table relationships to build a strong foundation in the Modeling Spaces while at the same time allowing the business analysts to consume and tailor the output to their specific needs.

Next Time

If I were to build another SAP Datasphere tenant from the ground-up, I would keep the spaces to a minimum but allow the tenant to expand dynamically with the growing pains of new requirements and additional use cases. In essence, it would be a slimmer version of the third design, focusing on scalability, flexibility while retaining control.

The Space Template

• 2-tenant (minimum), 3-tenant (recommended)
• 1 inbound-space
• 1 modeling-space
• 1 reporting-space

Now that SAP Datasphere (formerly Data Warehouse Cloud and recently packaged under SAP Business Data Cloud) has been released and used by customers for several years now, I’m curious to hear how it’s been deployed on other implementations. How are you organizing the Spaces (by domain, team, or lifecycle)? Who owns the metric definitions across Spaces? How do you package the Datasphere models so that the SAC teams can consume them easily?