SNP / Glue Cloud

During an SAP transformation, data doesn't move in one large batch - it moves continuously, in structured streams, between source and target systems, across multiple platforms and environments simultaneously. Managing this process requires visibility at every level: which pipelines are running, which objects are syncing, which have failed, and what the status of each individual data record is.

Glue Cloud is the CrystalBridge module built to own this layer. It is the operational hub where transformation teams create and configure data replication pipelines, monitor their progress in real time, manage field mappings, set schedules, and respond to errors - all from a single interface, without switching between external tools or dashboards.

Unlike the Organization Structure module, which existed in some form in CrystalBridge 1.0, Glue Cloud was built entirely from zero - a new product within an established platform, with no prior version to reference and no legacy patterns to inherit.

Starting from zero is both an opportunity and a constraint. There were no existing patterns to audit, no user complaints about a predecessor to address - but also no established mental models to build on, and no interface heritage to draw from. Every decision, from how pipelines would be represented, to how monitoring data would be structured, had to be made from first principles.

The users of Glue Cloud are not typical application users. They are primarily transformation consultants and technically proficient clients - people who understand SAP system architecture, care about data volume and sync timing, and need to diagnose problems quickly in high-stakes project environments. The tool had to match their level of technical literacy without becoming opaque to less experienced stakeholders also using it.

Three specific design problems needed solving. First, the pipeline lifecycle is long and multi-stage - creating a pipeline involves configuring a source, a destination, selecting and mapping objects, defining field mappings, setting sync schedules, and managing gateways. This had to be broken into a clear, step-by-step flow without losing context or making the user repeat steps unnecessarily.

Second, monitoring needed to scale to large datasets. A single pipeline can contain thousands of objects, each with its own sync progress, status, and history. The monitoring views had to present this data meaningfully without collapsing into tables of undifferentiated rows.

Third, the tool needed to work for both a technical expert and a less experienced client - the same interface had to be clear enough for a project stakeholder checking status, and precise enough for a consultant diagnosing a sync error.

Glue Cloud was my sole responsibility within the CrystalBridge 2.0 design team. The same workflow applied as with the Organization Structure module: JIRA-driven sprint planning, pre-work refinement with stakeholders, wireframes for logic validation, hi-fi built from the shared design system, and handoff to a dedicated group of developers.

The nature of Glue Cloud - a greenfield product rather than a redesign - meant that a larger proportion of the work happened in the early discovery and wireframing stages. Defining what the tool even contained, before designing how it looked, required more upfront conversation with stakeholders and more iteration on information architecture than a typical feature-level task.

Glue Cloud is organised around a clear information hierarchy: the module starts with a dashboard that gives an immediate operational overview - upcoming scheduled syncs, recent execution history, and quick-access actions. From there, the user navigates into Pipelines, Gateways, or individual pipeline detail views, each with its own set of tabs and tools.

The central concept is the pipeline - a configured replication job between a source system and a destination, containing a defined set of objects, a field mapping layer, a filter configuration, and a sync schedule. Every other screen in Glue Cloud either helps create a pipeline, monitors one in progress, or reviews its history.

The four-step wizard for creating a pipeline was the most structurally complex design problem: it had to guide a user through connection setup, settings, object selection with dual-pane browsing, field mapping across potentially thousands of source fields, and schedule definition - without ever feeling like a form dump. Each step was designed to be independently useful and self-contained, with progress preserved across steps.

Glue Cloud shipped as part of CrystalBridge 2.0 - a new module with no precedent in the platform's history. It became the operational interface through which transformation teams manage the data replication layer of live SAP projects.

Greenfield is discovery-heavy by nature. When there is no prior version to react to, a larger share of the work is definitional - figuring out what the product is, not just how it looks. Investing more time in the refinement and wireframing stages, before any visual design begins, pays off disproportionately when the scope is novel.

Wizards are a UX commitment, not a shortcut. Breaking a complex configuration flow into a wizard feels like a solution to complexity - but it only works if each step is genuinely self-contained, progress is truly preserved, and the user can freely move backwards without losing work. Designing the Glue Cloud pipeline creation wizard revealed how many edge cases emerge when you take that promise seriously.

Monitoring UX is a distinct discipline. Displaying the status of a running process is a very different problem from displaying a data record. Time, progress, failure modes, and alerting all introduce design decisions that don't appear in static data interfaces. The Monitor tab took more iteration than any other screen in the module.

The design system is an anchor, not a constraint. Designing a new product within an existing system could feel restrictive - but the CrystalBridge 2.0 design system provided a consistent baseline that made every decision faster. When a new pattern genuinely couldn't be satisfied by existing components, that was a signal worth examining: it usually meant the problem wasn't fully understood yet.