Ask anyone who’s wrestled with SAP, which may sit at the heart of most enterprises, and they’ll tell you its data model is a linguistic and architectural minefield. Understanding the data is one thing. Making it useful? That’s something else entirely.
For instance, tables like MSEG, VBAK, and LFA1 aren’t just cryptic—they’re rooted in SAP’s German heritage.
- VBAK = Vertrieb Beleg AnKopf (“Sales Document Header”)
- MAKT = Materialstamm Kurztext (“Material Short Description”)
To most English-speaking users, and probably plenty of Germans, these names might as well be ancient runes. SAP’s internal logic is brilliant for optimizing enterprise resource flows, but try telling a business analyst they need to join BKPF, BSEG, and SKA1 just to get a general ledger view, and you’ll see why analytics teams lose the will to live.
SAP’s architecture is built for transactions, not for analysis. It is ruthlessly normalized, highly interdependent, and structured for integrity, not visibility.
Enter Angles: An Opinionated Semantic Layer for SAP
Angles for SAP from insightsoftware was designed to be a kind of Rosetta Stone — not just to make SAP data readable, but to make it usable by people who don’t eat advanced business application programming (ABAP) for breakfast.
It does what SAP itself won’t, meaning it interprets, abstracts, and translates. It maps SAP’s raw schema to real-world business concepts. It understands the time logic between order creation and delivery fulfillment. It knows that On Time in Full (OTIF) means more than just “orders shipped” — it encapsulates expected dates, promised quantities, and delivery tolerances that differ by region or customer.
What makes Angles for SAP powerful isn’t just that it exposes data — it exposes decisions. It lets people ask real business questions such as “Why did lead times increase last month?” “Which vendors consistently deliver late?” “How do backlog and capacity interact across manufacturing plants?”
And it does so without requiring users to reverse-engineer the sales and distribution (SD), materials management (MM), or financial accounting and controlling (FI) modules to get there.Under the hood, Angles for SAP is built with pre-modeled joins, filters, time windows, exception logic, and domain-specific KPIs. Essentially it’s a curated semantic layer built by people who’ve actually suffered through SAP implementations and lived to encode the logic.
The Model in Action
For insightsoftware, the model worked. Business users loved the abstraction. Customers loved getting faster, more trustworthy insights from their SAP systems. But the technical architecture powering the product didn’t keep up with its success. Redshift wasn’t failing because the product was badly built. It was failing because the architecture was fundamentally misaligned with what Angles for SAP needed at scale:
- Per-customer isolation: Redshift made multi-tenancy a pain. Customers needed their own dedicated instance to ensure security and performance isolation. That made onboarding slow and expensive, resulting in a scaling tax.
- Heavy refresh workloads: Large customers needed frequent data loads and materialized view rebuilds. On Redshift, that meant more than two-hour refresh cycles, especially when view complexity and data volume stacked up. SLAs were at risk. Real-time insight wasn’t real anymore.
- Query unpredictability: Even when data was fresh, query latency could vary wildly. One dashboard load might take five seconds. The same query 10 minutes later? 50. Redshift’s concurrency model made the experience inconsistent, which is deadly when your essential pitch is “self-service analytics.”
- Soaring Costs: Most importantly the economics didn’t scale. Cloud costs were increasingly untethered from customer value. Usage spikes meant surprise bills. Each new customer meant more infrastructure, more spend, and tighter margins.
The Solution: Swapping the Engine without Rebuilding the Car
Rather than rewrite Angles for SAP, insightsoftware swapped out its data warehouse layer. It moved from Redshift to Yellowbrick on AWS, and everything that was fragile started to feel solid again.
Here’s what changed:
- True multi-tenancy. Yellowbrick’s architecture allowed for efficient customer isolation without dedicated clusters. Onboarding times dropped. Infrastructure sprawl was tamed.
- Faster refresh. ETL times shrank from hours to minutes, even for the biggest customers. That alone bought back enormous headroom across engineering and ops.
- Consistent query latency. Whether under light or heavy load, Angles for SAP users now experience sub-second to low-second response times. No surprises. No queue thrashing. Just reliable performance that made the front-end feel snappy and responsive.
- Better economics. insightsoftware cut total cost of ownership (TCO) by 50%. That mattered more than ever because Angles for SAP was onboarding 12x more customers and doing it without blowing up the infrastructure budget.
All of which meant Angles for SAP could scale profitably.
Analytics You Can Trust – Without the Headache
The best part? The Angles for SAP product didn’t need to change. The business logic, the semantic layer, industry-specific KPIs, the curated relationships between order, delivery, invoice, and payment all stayed intact.
What changed was the execution engine. The plumbing. The layer that takes the abstracted logic and pushes it through terabytes of SAP data fast enough to keep the illusion alive — that analytics should be easy.
That’s what a good data platform is supposed to do. It doesn’t just make things faster, it makes the product feel like it always should have.
The Bigger Lesson
There is a reason that SAP analytics is such a mess. The data is valuable, but it’s buried under decades of ERP logic, financial controls, and idiosyncratic extensions. Angles for SAP solves the “what does it mean?” problem. Yellowbrick solves the “how do we run it at scale without going broke?” problem.
It’s a pragmatic, boring kind of progress. But it’s the kind of progress that moves the needle.
Sometimes digital transformation isn’t about AI or digital twins or whatever. Sometimes it’s just about making SAP useful, and not punishing your margin in the process.
