Business Thursday – Page 2 – EduDataSci – Educating the world about data and leadership

Beyond Automation: Using SAMR to Explain AI Value in Property & Casualty Insurance Services

Most conversations about AI in property and casualty insurance start with the same promise: “faster, cheaper, smarter.” But in practice, the real question is where AI is being used.

Is it just doing the same work a little quicker… or is it changing the way underwriting, claims, and loss control actually run?

One of the cleanest ways to explain that difference is to borrow a framework from education technology: the SAMR model—Substitution, Augmentation, Modification, Redefinition—originally articulated by Ruben Puentedura. In SAMR, the first two levels are typically “enhancement” and the latter two are “transformation,” because they represent meaningful redesign (or reinvention) of the work itself.

In this post, I’ll map SAMR to the kinds of operational and strategic value AI can create across P&C insurance services (intake, underwriting, claims, fraud, and risk/loss services), staying away from customer chatbots and focusing instead on business process change that actually moves KPIs. Along the way, I’ll flag where AI and Insurance leaders tend to underestimate the “operating model” work required to reach the top of the SAMR ladder.

Straight Through Processing for Documents: When “Touchless” Becomes the Cost-Saving Feature

Most organizations don’t drown in documents because they lack OCR.

They drown because every document creates work-in-the-middle: a person opens an email, downloads an attachment, checks a value, rekeys it into a system, compares it to a second system, and routes it to a third. Multiply that by thousands of invoices, claims, onboarding packets, and compliance forms, and your “document workflow” turns into a labor model.

That’s where Straight Through Processing (STP) comes in.

In this post, I’ll lay out what STP actually means, why it’s the most practical way to think about cost reduction in document-heavy operations, and what “STP-ready” AI document automation requires beyond basic extraction—without anchoring the conversation to any single vendor.

Perfect AI Is the Wrong Standard: Automate the Happy Path and Take the Win

One of the most common complaints I hear about Artificial Intelligence—both from the public and from professionals—is some variation of: “It’s not 100% perfect.”

That reaction is understandable. But it’s also revealing.

In most areas of work, we don’t demand perfection. We demand progress. We accept that humans make mistakes, that processes have variance, and that edge cases exist. Yet the moment a workflow becomes automated—especially when it has “AI” stamped on it—many people quietly shift the standard to flawless execution.

Here’s what I want to do in this post: unpack why “100% perfect” is an unhelpful expectation for AI, and show why automating the happy path (the most common case) can deliver meaningful returns even if exceptions still require human attention.

The Chief Risk Officer’s Quiet Obsession: Data Platforms and Data Products

A Chief Risk Officer (CRO) at an FSS Corporation rarely wakes up thinking, “I can’t wait to talk about data architecture today.”

But they do wake up thinking about something that inevitably leads back to it:

Can I trust what we’re about to tell the Board, the regulator, and the market—especially when conditions get ugly?

That question is why the CRO cares deeply about your Data Platform and your Data Products. Not as “tech initiatives,” but as the machinery that turns risk from opinions and spreadsheets into repeatable, auditable decisions the business can stand behind.

In this post, I’ll connect the CRO’s mandate to the practical realities of platforms and products—and why getting this right is a risk control, not a nice-to-have. Along the way, you’ll see why risk management and operational resilience don’t live in policy binders—they live in data.

Syntax Was Never the Hard Part: What AI Coding Misses in Legacy Modernization

There’s a familiar storyline making the rounds right now: point an AI coding assistant at a legacy application, translate the COBOL (or FORTRAN, or PL/I, or SAS, or VB 6.0), and watch a modern system emerge on the other side.

It’s a comforting idea because it frames modernization as a language problem. And language problems are the kind of problems we’re used to solving with tools.

But most modernization programs don’t fail because the engineers can’t learn the syntax. They fail because the organization can’t recover the intent.

In this post, I want to make a simple case: AI-assisted coding can absolutely accelerate modernization, but it doesn’t remove the hard parts of modernization. Those hard parts live upstream and downstream from “write code”: the “why,” the evidence, the governance, and the operational reality of running real systems under real constraints.

When Facts Don’t Live in a Domain: Why Data Products Beat Pure Domain-Driven Data Engineering

There’s a pattern I see in mature analytics organizations: as soon as the data platform gets big enough to feel “enterprise,” someone reaches for domain-driven design (DDD) as the organizing principle for data engineering and governance.

It’s an understandable move. DDD gives us language for ownership, boundaries, and “this team is responsible for that thing.” And when you’re trying to untangle a spaghetti warehouse, that sounds like oxygen.

But here’s the catch: the most valuable data in a warehouse—the fact tables in traditional star schemas—often doesn’t live neatly inside a single domain. It lives at the intersections.

In this post, I’m going to make three points:

why domain boundaries tend to break down precisely where the business value shows up (facts)
how a data product model handles “intersection data” without inventing reference domains and mega-joins
why Microsoft Fabric’s workspace + lakehouse + OneLake tooling makes the product approach easier to execute in practice (especially with shortcuts, security, and materialized lake views)

And yes—domains still matter. Just not as the unit of delivery.

From Warehouses to Products: SAMR for Your Cloud Data Platform

Financial Services, Insurance, Wealth Management, and Professional Services have a gift—and a curse—when it comes to data.

The gift is that these industries know how to run critical systems with discipline. The curse is that we’re so good at controlling risk that we often rebuild the same constraints in every new platform we adopt.

That’s why so many “modern cloud data platforms” in these sectors end up feeling like the old data warehouse with a new hosting model: better infrastructure, familiar bottlenecks. Slow change. Long planning cycles. A platform measured by what it ingests, not what it enables.

In the previous post on AI and SAMR, the point wasn’t that AI is inherently transformative. The point was that without a disciplined framework, we use new tools to reproduce old workflows. The same is true for data.

Here’s what I’ll cover in this follow-up:

Why cloud platforms in regulated, risk-sensitive industries so often replicate warehouse-era behaviors.
How SAMR can be used as a simple truth-teller for your data platform strategy.
Why data products are the most practical “unit of redefinition,” and why you don’t need Data Mesh to benefit from them—though mesh and product thinking dramatically expands your toolset.
How ground-up design thinking keeps your platform anchored to real business goals, not elegant architectures

If your cloud platform still takes six months to change a definition, you didn’t modernize. You relocated.

From “Should‑Do” to Done: Digital Workers for Wealth, Energy, and Financial Services

Every enterprise carries a shadow backlog—the should‑do work that never beats the urgent. It’s the reconciliation that almost closes, the control that’s “fine for now,” the evidence that exists but isn’t filed where audit will accept it. None of these items is existential in isolation; together they become trust debt: silent risk, rework, slower decisions, and reputational drag.

2025 amplified the problem. Compressed settlement cycles demand same‑day precision in wealth operations. Emissions and operational reporting remain high‑stakes in oil and gas, with timelines adjusted but scrutiny intact. Financial institutions face fluid sanctions and evolving data‑sharing rules, while beneficial ownership reporting shifted materially. In each case, the gap is less about intent and more about capacity. Digital workers exist to close that gap.

Digital workers are policy‑aware software agents that connect to the systems already in place, act on explicit rules (with narrow ML where safe), and hand back proof that the job was completed—consistently and auditable. What follows clarifies how they work and where they quietly create value in wealth management, oil and gas, and financial services.

From Substitution to Outcomes: How AI and SAMR Are Forcing a Rethink of Development Strategy

We like to say we’ve “transformed” how work gets done. But if you look closely at many enterprise systems, you still see the outline of a paper form hiding under a slick UI.

We replaced paper with terminals, terminals with web apps, web apps with SaaS—and then pointed automation at the whole stack. In too many places, we’ve simply substituted one medium for another, without asking whether the underlying process still makes sense.

In this post, I’ll do three things:

Introduce the SAMR framework as a way to think about how technology shapes work.
Show how many business processes sit on layers of substitution going all the way back to paper.
Explain how AI enables goal‑based processes, where we define the outcome and how we’ll know we’ve met it, and let AI figure out the path—without prescriptive step‑by‑step code.

And along the way, we’ll confront an uncomfortable idea: some of your “modern” processes may still be driven by the personal preferences of someone who retired more than fifty years ago.

Functional vs. Nonfunctional Requirements: Making the Split Work in Agile

If you’ve ever shipped a feature that “works” and still disappointed users, you’ve met the gap between what a system does and how well it does it. That gap is the space nonfunctional requirements occupy—and it’s where agile teams win or lose product trust.

In this continuation of our requirements series, we’ll clarify the difference between functional and nonfunctional requirements, show how to make nonfunctional requirements measurable, and connect both to practical agile habits—user stories, acceptance criteria, Definition of Done, SLOs, and pipeline checks. By the end, you’ll have a lightweight pattern you can apply this sprint. This is where #RequirementsEngineering meets Agile and DevOps.