DCRM

DCRM — Denim Customer Relation Management — is the web portal for Diamond Fabrics’ Denim division. It is built around two kinds of module: ones that are integrations of SAP, surfacing data that already lives in the ERP, and ones that track the business process the division runs on.

The client is React styled with MUI; the server is Express.

It’s an internal tool. The people who open it are Denim division staff and management who need what’s already sitting in SAP, from wherever they happen to be — not a fixed desk with a Windows machine and an SAP seat in front of them.

Problem

Real facts, so far: SAP’s client at Diamond Fabrics is SAP GUI, a thick desktop application that only runs on a Windows machine — there is no getting to SAP data without sitting down at a machine that has both a Windows install and a licensed SAP seat. Licenses are limited, so only a fixed number of people can be in front of that machine at any time. Leadership wanted the data reachable over the internet, from portable devices, including phones, by people who were never going to get a Windows box or an SAP seat of their own.

DCRM exists to answer that constraint, not to duplicate SAP. It is a web front end that sits in front of SAP: one side holds the SAP integration — the one piece that actually needs SAP access — and the other side fans that data out to browsers and mobile devices, so many more people can read and act on SAP data than could ever hold a license to it directly. It doesn’t replace SAP; it is a single, controlled point of entry to it.

TODO(zain): How many SAP seats existed relative to how many people needed the data — even a rough sense (“a handful of licenses, most of the division needed access”) makes the constraint concrete instead of abstract. And which SAP data/modules does DCRM actually front — sales orders, inventory, customer records, something else?

Research

TODO(zain): How did you learn the Denim division’s business process well enough to model it? Who taught you — a domain expert, a manager, documentation? What did you get wrong in your first mental model of the process, and how did you find out?

TODO(zain): How did you learn the SAP side? Was there an existing integration layer, documented endpoints, RFC/BAPI, an OData service, a middleware team — or did you have to reverse-engineer it? This detail is genuinely impressive if you tell it; leave it out and the reader assumes it was easy.

Architecture

Real facts, so far: React + MUI front end, Express API, modules that integrate SAP alongside modules that track business process. The SAP integration is centralized on the server: Express is the one piece that holds SAP access, so the license constraint from the Problem section lives in exactly one place, and every browser or mobile client behind it reaches SAP data without needing an SAP session of its own.

That server reads from the ERP through a single, controlled integration point that the team maintained — a narrow surface exposing only the data DCRM needed, rather than DCRM reaching into the ERP’s internals directly. Keeping that surface deliberately small is what makes the rest of the system tractable: the integration can change on its own schedule without every screen changing with it, and there is exactly one place where access to the ERP has to be guarded.

That guarding is the real work. When you read a system of record at this level, you’re responsible for the checks it would otherwise apply for you — so the boundary has to be treated as the security perimeter it is, not as a trusted pipe. It’s the same centralisation point as above: one guarded connection in, many browser and mobile clients out, none of them needing a seat of their own.

TODO(zain): List the modules. Which are SAP integrations and which are homegrown process tracking? What happens when SAP is unreachable or slow? Is DCRM ever the source of truth, or always a mirror?

TODO(zain): What’s the data store, and what’s in it that isn’t in SAP? How is auth handled — SAP identities, an internal directory, or DCRM’s own user table? How do roles map to modules?

Development

TODO(zain): Team, timeline, your scope. This ran alongside the Invoice Portal — were they the same team, the same codebase conventions, the same deployment pipeline? How does a change get to dcrm.dfl.com.pk today?

TODO(zain): Pick the hardest module and walk a reader through it end to end: the screen, the API call, the SAP hop, the write-back, the edge cases. One module told properly is worth more than ten module names in a list.

Challenges

TODO(zain): The SAP integration is almost certainly the story here — say what actually made it hard. Auth? Data shape mismatches? Latency? Rate limits? A system you couldn’t test against safely? Also worth covering: keeping the UI responsive when a call downstream is slow, and reconciling process state that lives half in DCRM and half in SAP. Three concrete problems, three concrete resolutions.

Results

DCRM is working — it’s still running.

Lessons learned

TODO(zain): Now that the reason DCRM exists is on record — one licensed integration point standing in for many SAP seats — what did building that boundary actually teach you? Would you draw the line between “the service that holds SAP access” and “everything else” in the same place again, or split it differently? And what’s the one thing from DCRM you’d bring to the next system where a limited resource — a license, a legacy desktop client, a rate-limited API — has to be fanned out to more users than could ever hold it directly?