General Information – EduDataSci – Educating the world about data and leadership

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.

Governed Innovation: Turning Learning Loops into Enterprise Strategy

Governance, done well, accelerates innovation. That sounds counterintuitive because “governance” often conjures gatekeeping and delay. But in complex systems, enabling constraints—clear aims, decision rights, evidence standards, and risk guardrails—reduce thrash. They let teams move faster with less politics, less ambiguity, and fewer expensive reworks.

Put simply:

Governed innovation = purposeful exploration + disciplined decisions + explicit guardrails.

Purposeful exploration means we start from outcomes the organization actually cares about (growth, safety, quality, equity, cost-to-serve) and frame hypotheses against those aims.
Disciplined decisions means we pre‑commit to how we’ll read the evidence and when we’ll stop, scale, or adapt.
Explicit guardrails means privacy, security, ethics, accessibility, and brand risk are design inputs, not last‑minute vetoes.

Improvement science provides the learning loop (PDSA, practical measurement, driver diagrams). Governed innovation provides the direction (what we test and why), the portfolio (how many bets across time horizons), and the legitimacy (we are learning fast and being good stewards).

Certifications in IT

I hold a lot of certifications. That’s a personal choice, not a creed. I like challenging myself against a test to prove I’ve learned something and lets me prove to myself that I’ve actually successfully learned something. The “certs or no certs?” debate is as eternal—and as spicy—as vi vs. Emacs (or “eMacs,” if you’re trolling your coworkers). Different corners of computing answer that question differently, for good reasons. A little history sets the stage:

CCIE’s origin (1993): Cisco launched the CCIE with a famously grueling, hands‑on lab. It quickly became the example of a vendor cert that feels like a license to practice, not just a multiple‑choice quiz.
MCSA’s era (retired 2020–2021): Microsoft’s MCSA/MCSE/MCSD defined the classic exam‑centric, product‑specific credentialing model before Microsoft pivoted to role‑based, cloud‑first certifications.
Software Engineering PE (ended 2019): In the U.S., the dedicated PE exam for software engineers was discontinued after the April 2019 sitting—closing a formal licensure lane some hoped would tie software to traditional engineering standards.

Slowly Changing Dimensions (SCDs): A Practical Guide for Your Star Schema

Star schemas shine when your facts (events) are analyzed through dimensions (who/what/where/when). But in real life, dimension attributes change—customers move, products rebrand, sales territories realign. Slowly changing dimensions (SCDs) are the modeling patterns that preserve analytic correctness as those attributes evolve.

Citizen Data Analysts, Citizen Data Scientists, and Citizen Developers—What We Mean (and How They Work Together)

If you’ve been reading along here, you know our north star is putting data to work—safely—where decisions actually happen. Three personas keep showing up in that mission: Citizen Data Analysts, Citizen Data Scientists, and Citizen Developers. They’re adjacent, not identical. Here’s how we define them, how they differ, and how to enable each without creating chaos.

Quick definitions (with Gartner links)

Citizen Data Analyst (CDA)
A domain expert who turns governed data products and a semantic layer into decisions using self‑service BI (dashboards, KPI views, ad‑hoc analysis). Not a Gartner term; it’s our practical label for the power user of curated data.

Citizen Data Scientist (CDS)
A business user who goes beyond visualization to prototype models with guided/augmented tools. Gartner’s definition is often quoted as: “a person who creates or generates models … but whose primary job function is outside the field of statistics and analytics.” See Gartner: Citizen Data Scientist for the glossary entry; a commonly quoted rendering is captured here.

Related Gartner context: augmented analytics “also augments the expert and citizen data scientists by automating many aspects of data science [and] ML.” (Gartner)

Citizen Developer (CD)
A business user who builds apps/automations on approved low‑code platforms. Gartner is concise: a citizen developer is “a persona, not a title or targeted role.” See Gartner: Citizen Developer.

Conway’s Law for Data Teams

Two Dashboards, One Truth

On Monday, Maya—head of a seven‑person data team—watched two dashboards disagree.

The executive dashboard showed $11.2M in MRR. Sales’ dashboard said $10.6M. Both pulled from “the warehouse.” Both refreshed nightly. Neither was “wrong”; they just measured different things.

Maya didn’t control how Sales Ops or Marketing were organized, who they reported to, or which tools they bought. She controlled only her data team—its models, interfaces, and operations. Yet the warehouse had clearly taken on the shape of the company’s communication patterns.

Conway’s Law, without asking permission, had moved in.

Foundational and Derived Data Products: Practical Guidance for Architects and Data Leaders

As we discussed previously, a data product is a reusable, self‑contained package that bundles data, metadata, access methods, and governance to deliver a clear outcome to users or other systems. Treating data as a product implies product management disciplines (contracts, SLOs, versioning, observability) and an emphasis on discoverability, interoperability, and security.

Within modern mesh-aligned architectures, data products must be interoperable and composable so they join predictably and can be assembled into higher‑order solutions. This is a first‑principles characteristic, not a nice‑to‑have.

Data Products Demystified: What They Are and Why They Matter

Data products are becoming a hot topic across industries, from classrooms to oil fields to trading floors. Yet the term “data product” can be confusing, conjuring images of complex databases or black-box AI. This blog post aims to clarify what a data product actually is in straightforward terms, and why it’s important for both technical and non-technical professionals. We’ll explore how data products turn raw data into useful tools, how they benefit organizations, and how they differ from other data concepts. Along the way, we’ll look at a couple examples to make the ideas concrete.

The most important skill

This can be modeled with the equation log(ExamScore) = 3.75(log(NumberOfStudents))-0.02(SEDPercent).

In order to create that fact table, with that grain, we’ll need 243kb of storage per record.

The way the MEDIAN function is implemented in this software, the execution time of the process grows exponentially.

For practitioners in the various domains that these statements come from, they’re all easily interpretable and easy to understand. For those outside of those domains, each one is pretty impenetrable. Worse than being hard to understand, each of these statements leaves almost as much important material unsaid as said.

If clear communication is the most important skill in business, than the most important skill for a data scientist – or arguably any scientist – is the ability to take complex topics and reduce them into material that is easy for a layman, can understand. Even more, these people must be able to understand you well enough to take effective and timely action based on the information that you are relaying to them. Continue reading “The most important skill”

What is data science?

The first question a blog like this needs to answer is really, “What is data science?” This is particularly important because there are a lot of definitions out there, and the community hasn’t coalesced on one yet. The definition I’ll be using is that data science is an overarching discipline that includes elements from several fields and focuses on integrating them together from a systematic perspective. Continue reading “What is data science?”