Data Integration in SAP Datasphere
Giving each data flow in SAP Datasphere a clear purpose
Client
SAP
Service
UX Design
Role
Designer
Year
2021 – 2023
Between 2021 and 2023 I worked on two of the flow types in SAP Datasphere’s Data Builder: Replication Flows, which copy data from source systems, and Transformation Flows, which reshape it on the way. Both started from the same problem. Users couldn’t tell which flow to use for which job, so they reached for external tools instead. My work helped give each flow a clear, narrow purpose.
Work Details
Context
Replication Flows and Transformation Flows are part of the Data Builder in SAP Datasphere, alongside Data Flows. Replication Flows provide high-performance data copying from source to target systems, with a focus on reliable, governed replication. Transformation Flows let Data Modelers load data from one or more sources, apply SQL-based or graphical transformations, and write the results to target tables. They fill the gap between simple data loading and advanced modeling.
Problem Statement
Users were missing two things. They had no straightforward way to replicate large datasets from ABAP and other systems into Datasphere, and no straightforward way to transform data as it moved between sources and targets.
The workarounds were the same in both cases: external ETL tools, or overloading flow types that weren’t built for the job. That led to confusion, inefficiency and governance gaps.
My Role
Replication Flows (2021): I supported the UX design by defining user journeys for replication use cases, building prototypes of the flow canvas and replication settings in UI5 with Sketch and Figma, running usability tests with Data Engineers, and working with PM, Engineering and QA to refine requirements.
Transformation Flows (2023): I led the concept definition and early design exploration. I researched user needs, defined the first user journeys, prototyped in Figma and UI5 in line with the Data Builder canvas, scoped feasible solutions with PM and Engineering, and ran moderated usability sessions with Data Modelers.
In both cases, I handed the work to another designer for final delivery, with a full handover of concepts, flows, specs and design rationale.
Tools & Methods
Sketch and Figma for design explorations and UI prototypes.
UI5 prototyping for interaction testing.
Moderated usability testing to validate mental models and the clarity of settings.
The Design Journey
What Users Told Us
Users mixed up replication and transformation, which made the earlier flows confusing.
For replication, they wanted to “set it and trust it”: reliable runs and clear monitoring.
For transformation, they wanted to reshape data inside Datasphere instead of moving it out to external tools.
One Pattern, Two Decisions
Both projects went through the same pivot. We first tried adding the new capability to existing flows, and both times it made things harder to understand. So both became distinct flow types, each with one clear job.
Replication Flows: Embedding replication into existing flows was rejected as too complex. We pivoted to a dedicated flow type with a simplified UI.
Transformation Flows: I compared extending Data Flows with introducing a new flow type. Embedding transformations into existing flows created confusion, so we defined Transformation Flows as a distinct category.
Final Designs
Replication Flows: Source and target nodes on the familiar canvas, a replication-specific configuration panel for initial and delta loads, and monitoring hooks for reliability.
Transformation Flows (handover point): Consistent with the other Data Builder flows, with transformation-specific capabilities added on top.
Challenges & Resolutions
Challenge: Keeping Replication, Transformation and Data Flows from overlapping.
Resolution: Replication Flows were scoped strictly to copying data, with flexible scheduling and monitoring. Transformation Flows were scoped to modeling and delta logic.
Key Deliverables
Figma prototypes and UI5 demos.
Usability testing reports.
Annotated design specifications for Engineering.
Impact
Clearer flow taxonomy: Separating Replication, Transformation and Data Flows reduced user confusion and made adoption easier.
Transformation Flows shipped covering the most common data modeling needs, with SQL-based transformations directly in Datasphere and support for delta tables inside the existing flow canvases.
Community feedback: Users in the SAP community describe Replication Flows as “indispensable for ABAP to Datasphere replication.”
Looking Back
Customer feedback gathered years after my handover is a useful check on these decisions. Users still value Replication Flows as the way to move data into Datasphere, which supports keeping replication focused on one job. The feedback also shows where that focus has a cost: some users want light transformations before data lands. Users also keep asking for clearer failure details and logging, which matches the “set it and trust it” need from our original research. If I worked on this again, error handling and recovery would be the first things I’d test with users.
Know more: SAP Datasphere – https://www.sap.com/products/data-cloud/datasphere.html
