The Menu

I will have the artisanal spreadsheet as a shared appetizer.

Sir, that is the only thing in the kitchen. Ralph makes it by hand.

Dave: "I need the list of active facilities with their regional codes."

Jen: "Pull it from the asset management system."

Dave: "I did. It has 412 facilities. The budget system says 397. The HR system says 408."

Jen: "Which one is right?"

Dave: "None of them. Ralph in Building 4 has the real number. He keeps a spreadsheet."

Every organization has a Ralph. [not his real name. but you already knew that.]

He is the person who quietly built a spreadsheet years ago because the official systems couldn't answer a basic question. Now he maintains it. He's the only one who understands the formulas. Three VPs depend on his Tuesday morning update. Two dashboards pull from his file. And one entire compliance submission is just his spreadsheet reformatted into a PDF.

Who is the Matador? He or she is the Spreadsheet Jockey. And "The Matador" is the most important person in your data operation that nobody will ever put on an org chart. The Matador often gets applause which sounds like seals at the waterpark.

Who is the Crowd? The managers who need numbers by Tuesday.

Who is the Bull? Your live operational data, about to flip the matador and his "vlookup" upside down.

I chose this metaphor because it works for what we all observe daily. The Four Words explain why he exists.

[Catching up? The Four Words: Data Governance, Data Standards, Data Management, Data Exchange. Same order. Every time. Parts 1 to 3 covered why you can't skip the first two.]

Ralph exists because Word 1 (Data Governance) was never done. Nobody documented the authoritative source for "active facility." Nobody assigned ownership of that definition. Three systems were bought, each with its own interpretation, and nobody reconciled them. So Ralph did it himself.

That's not initiative. That's organizational failure wearing a lanyard.

The human middleware problem

Here's what happens in practice. An executive asks a question. "How many active contracts do we have?" The answer should come from a system. Instead, it triggers a phone tree. Someone emails Ralph. Ralph opens his spreadsheet. Ralph cross-references two databases, adjusts for the records he knows are duplicates, removes the ones that should have been archived last quarter, and sends back a number.

That number is accurate. I want to be clear about that. Ralph's spreadsheet is usually the most accurate source in the building. For a brief moment in time, that's the problem.

When your most accurate data source is a person with a .xlsx file on a shared drive, you have built human middleware. You have turned a GS-12 into an API. And you are one retirement, one transfer, or one bad Tuesday away from losing your entire data pipeline.

[side note: I have personally watched an agency treat a massive excel sheet as "live" inventory which then drives leadership dashboards and downstream tools provided to support contractors. Human middleware is a true story. The backup plan was "someday we should try really hard to modernize data integrity."]

[Dad Joke] Why did the spreadsheet break up with the dashboard? It was tired of doing all the work and getting none of the credit.

Why this keeps happening

Ralph didn't create this problem. The org did. The pattern is always the same:

Leadership buys a platform. The platform is a Data Lake with a proprietary ontology which does not match reality, and now it includes AI features without governance. What could possibly go wrong?! Now the large tools platform leads your government data strategy instead of following. Is your vendor-provided ontology portable? We all know the answer is... doubtful.

If you cannot take your ontology and model with you, you do not own it, you are RENTING it. No agency should outsource or rent its own data governance.

Nobody wants to do the governance work to reconcile the model with the business definitions. So the platform launches with "good enough" data. Two quarters later, someone notices the numbers don't match. Ralph builds a spreadsheet to "bridge the gap." Five years later, that bridge IS the infrastructure.

This is what happens when you skip Word 1 and Word 2. Your tools (Word 3) get deployed without governed definitions or standards. Your integrations (Word 4) move data between systems that don't agree on what the data means. And somewhere in the middle, a human being holds it all together with VLOOKUP and conditional formatting.

The Spreadsheet Jockey audit

Want to know how big this problem is in your org? Ask four questions:

1. For your top 10 business entities (customer, contract, facility, employee, asset), can you name the single authoritative system of record for each?
2. When the numbers from two systems don't match, who do people call?
3. How many spreadsheets in your org exist because a system couldn't answer a basic question? Manager consensus: "well it's all we have really."
4. Are your dashboards lying to leadership? Be honest.

If the answer to #2 is a person's name and not a system, you have a Spreadsheet Jockey. You probably have several. And your data governance program should start by documenting what they know, not by buying another platform.

[Save those four questions. Use them in your next data strategy meeting. The room will get very quiet.]

What 1st Class governance does for Ralph

Here's the good news. When governance is done right, Ralph gets his life back.

Word 1: document the authoritative source for every key business entity. Publish it. Make it official. No ambiguity.

Word 2: define the standards. "Active facility" means this. Not that. Not "it depends." Every system that stores facility data conforms to this definition or gets flagged.

Word 3: configure the tools to enforce those definitions. The platform doesn't accept records that violate the standard. The dashboard pulls from the governed source.

Word 4: integrations move governed data between systems that share the same definitions.

Good news: this is the moment that $$$ AI platform returns real, measurable value. Not before. When governance leads, tools follow.

And Ralph? Ralph goes back to his actual job. The one he was hired to do before the org turned him into a data janitor.

The path forward

Your Spreadsheet Jockeys are not the problem. They are the symptom. They exist because governance didn't happen first. Every spreadsheet workaround is a postcard from a system that failed to answer a basic question.

Four words. Same order. Same answer.

If you want to retire the spreadsheet, govern the source.

Part 4 of The Governance Series by daitagov. First published on LinkedIn.

The Menu

Family style, please. Every team brings a dish.

And who is responsible for the table?

...Everybody. So nobody.

You heard "data mesh" at a conference. Your architect heard it on a podcast. Your vendor heard it and started updating their slide deck.

Now everyone is excited about decentralized data ownership. Domain teams own their data products. Self-serve infrastructure. Federated governance. It sounds like freedom. It sounds like the opposite of that centralized data lake that never delivered.

Here's the problem: your enterprise already runs a data mesh. You've been running one for years. You just call it "every department has their own database and nobody shares anything."

Data mesh without governance is just your current mess with a prettier architecture diagram.

The Four Words still apply.

[If you're joining the series here: the Four Words are Data Governance, Data Standards, Data Management, Data Exchange. Same order. Every time. Parts 1 and 2 covered why you can't skip straight to tools.]

Data mesh lives in Word 3 (Data Management) and Word 4 (Data Exchange). It is an architectural pattern for how data gets organized and shared across domains. It is not a governance model. It does not replace Words 1 and 2. It depends on them.

Let me say that louder for the vendors in the back: data mesh does not eliminate the need for enterprise data governance. It increases it.

Why mesh fails without governance

When you decentralize data ownership to domain teams, you're making a bet. The bet is that each team will define their data products with consistent quality, interoperable standards, and clear access policies. Without centralized governance standards, here's what actually happens:

Marketing defines "customer" one way. Finance defines it another. Operations has three definitions depending on which system you check. And the data mesh becomes a data marketplace where nobody speaks the same language.

I've watched this play out at three different agencies. The pattern is always the same. Phase 1: excitement about domain autonomy. Phase 2: teams build data products in isolation. Phase 3: someone tries to combine data from two domains and discovers the schemas don't align, the timestamps use different zones, and "Enterprise" means four different things (true story).

That's not a mesh. That's a mess with a Kubernetes cluster. [side note: I've seen this exact failure pattern more times than I've seen a clean data lake migration. And I've never seen a clean data lake migration.]

What governance looks like in a mesh

The good news: data mesh done right is actually excellent. It's one of the better patterns for large, complex organizations. But "done right" means the federated governance layer is the first thing you build, not the last.

Three non-negotiable governance requirements for mesh:

1. A shared business glossary that every domain agrees to before they build their first data product. Not after. Before. If domain teams can't agree on what "customer" means, they're not ready for mesh. They're not even ready for a shared spreadsheet.
2. Interoperability standards at the contract level. Every data product has a schema contract. Those contracts follow enterprise-wide standards for naming, typing, versioning, and access. The mesh platform enforces these contracts automatically. If a data product doesn't meet the standard, it doesn't publish.
3. A central governance council (small, empowered, cross-domain) that reviews data product registrations, resolves definition conflicts, and audits quality. This council doesn't own the data. The domains own the data. The council owns the rules.

The real question

When someone tells me their org is "moving to data mesh," I ask three questions:

1. Do you have an enterprise data glossary that more than one team actually uses?
2. Can you tell me, right now, who owns the definition of your top 10 business entities?
3. When two domains define the same thing differently, what's the resolution process?

If the answer to any of those is "we'll figure it out as we go," you're not implementing data mesh. You're decentralizing a problem.

[Save these three questions. Ask them at your next architecture review. The answers will tell you exactly how ready your org is.]

The path forward

Data mesh is not the enemy. Premature decentralization is. The pattern works when governance provides the rails and domain teams provide the trains. Without rails, you just have expensive vehicles driving in circles.

Four words. Same order. Same answer.

If your mesh doesn't start with governance, it ends with a vendor re-platform pitch in 18 months.

Part 3 of The Governance Series by daitagov. First published on LinkedIn.

The Menu

Do you have a reservation?

Yes. My guest and I will be dining in the Data Lakehouse.

Wonderful. Will you be owning or renting the table tonight?

Dave: We're building a Data Lake.

Jen: Cool. What problem does it solve?

Dave: All of them.

Jen: Which ones specifically?

Dave: The data ones.

Jen: Do we have a data strategy?

Dave: The Data Lake IS the strategy.

Jen: That's like saying the swimming pool is the water treatment plan.

Dave: We're also hiring a Data Lake architect.

Jen: Do we have a data governance lead?

Dave: That's a different budget line.

Jen: It's the SAME problem, Dave.

Dave: Look, leadership wants a Data Lake by Q3.

Jen: Leadership also wanted a Data Warehouse by Q3 in 2018.

Dave: That was different.

Jen: Was it though?

Dave: ...

Jen: Where is that Data Warehouse now?

Dave: We don't talk about that.

Jen: You are building a swamp with a dashboard.

Welcome back. If you read Part 1, you already know the four words and the order they go in. If you didn't, go read it. We'll wait.

This one builds on it. In this series, Dave and Jen will have some interesting conversations which (could be) based on actual conversations in your Federal agency. Are you Dave or Jen in this story? More characters coming soon.

Part 1 was about what happens when agencies buy tools before building governance. Part 2 is about something more uncomfortable: why everyone involved (vendors, IT managers, contractors) has a vested interest in making sure the buying never stops. Regardless of whether the tools work.

Let's start with a question nobody wants to answer honestly.

Why is "build a Data Lake" always urgent?

Not important. Urgent. There's a difference. Important is "we need to understand our data before we can modernize." Urgent is "we need a Data Lake by Q3." Important means asking hard questions. Urgent means skipping them. And urgency, real or manufactured, is the engine that keeps this cycle running. "We are in a crisis, there's no time for this stuff!"

Here's what I've observed over decades in federal IT: the urgent need for vendors to sell "Data" solutions and the urgent need for agencies to implement them. Those are not two separate problems. They are the same problem. They are both symptoms of a confirmed, enterprise-wide absence of data governance. And here's the part that makes people uncomfortable: in the current model, everybody wins. The vendor wins a deal. The IT manager wins a bigger budget line. The contractor wins a support contract. The only thing that loses? The mission. And it loses quietly, over years, one seven-figure project overrun at a time.

(What's a Data Lake without governance? A very expensive swamp? A Data Puddle for $40M? You decide.)

WARNING: What follows is going to sound harsh. It's meant to.

The Tools Promotion Office

We love them, right? The people I mean.

In most large federal agencies, the IT department functions less as an objective technical authority and more as a tools promotion office. There are individual exceptions everywhere. Talented, mission-focused IT professionals who fight this pattern every single day. But the institutional pattern is clear: the loudest voice in the room isn't asking "what does the mission need?" It's asking "which platform should we buy?" And that person already has an answer. They've been to the demos. They've been to the conferences. They've got vendor swag on their desk and a relationship with the Federal Sales Engineer that pre-dates the RFI.

The evaluation was over before it started. Facts.

[TRUE STORY] Decades ago, one evening after 8pm working as a young network admin, I was waiting for all the staff to go home then update the LAN (uh... with 50 floppy disks). A senior federal IT colleague appeared on my floor. He was unloading boxes, lots of them, to every desk. "Don't mind me Greg! Everyone is getting a brand new color printer on this floor!" Me: "For what?" Him: "We have to spend IT budget before end of September." I was maybe 21 yrs old in a server closet (also my office) and had already asked my one allowed question. I knew nobody on my floor "needed" a color printer but someone else "needed" to buy 20 of them to maintain the annual budget request to OMB. I find the phrase "hey, it was the 80's" works often, but as each decade since has come and gone, some might say not much has changed, unless you work for GAO.

Is this procurement gone wild or culture? You decide, but in most agencies it's a system that rewards procurement over outcomes, platform adoption over mission impact, and budget growth over operational maturity. The IT manager who procures a seven-figure platform gets promoted. The IT manager who spends two years building a data governance framework that prevents the need for that platform? Nobody writes that success story. There's no ribbon-cutting for "we didn't buy something."

And the vendors? They're doing what vendors do. They sell. They're good at it. The demo is always incredible. The deck always aligns with your strategic plan. The references are always glowing. I am not anti-vendor. I am pro-honest-outcomes. Although not a catchy buzzword, let's face it, the vendor's job ends at the purchase order. Your job doesn't. And the gap between "purchased" and "operational"? That's where seven figures go to die.

"We need a Data Lake" = Federal Enterprise Surrender

So when someone in your agency says "Our problem is that we need a Data Lake!" (eyes wide, voice rising, hands gesturing at an imaginary architecture diagram like they just discovered religion)...

...ask yourself: is this a strategy or is this a purchase order dressed up as one?

A familiar pattern. Do you recognize it?

The cries for a Data Lake almost always indicate what I call enterprise surrender. The moment an agency admits it cannot make sense of its own data. The frustration is legitimate. The data is scattered across 40 systems. Nobody trusts it. Getting a straight answer to a simple question requires calling three people and opening four spreadsheets. The Human Middleware from Part 1? Still running. Still duct-taping answers together every morning before leadership walks in. "Happy Monday. I can't wait to see our Dashboard."

But the instinct to reach for technology (something big, something shiny, something with a logo and a sales engineer) is the instinct that's been costing us millions for decades.

Buying a Data Lake to solve a data governance problem is like buying a gym membership to fix a broken leg. You're not wrong for wanting to be healthy. You're just starting in the wrong place. And the gym doesn't care. They got your money.

The lifecycle of a Data Lake (without governance)

Here's where the pattern gets expensive. I've seen this play out enough times to set my Apple iOS watch by it.

Are AI platforms the Data Warehouses of 2016? Let's hope not.

[side note: I've seen this movie before. In the late 2000s it was Business Intelligence platforms. In the mid-2010s it was Data Warehouses. By 2016 it was Data Lakes and now it's AI. The vendors change. The acronyms change. The PowerPoint decks get prettier. The outcome doesn't change.]

I am witnessing a project now which has stuffed 200+ documents (TWO-HUNDRED) into an agency AI chatbot which will be flung at light speed into the workforce. Context? None. Structure? Meh. Use cases? Zero. Next train stop: Hallucination Island. Success? Not a flippin chance unless you define the purchase itself as success. What could possibly go wrong using AI? Can't wait to read the "Lessons Learned" report in 2027.

You cannot "Data Lake" what you cannot govern. Same as you cannot "AI" what you cannot govern. Same answer. Same four words.

The Data Lake IS legitimate (when it's earned)

Now, to be fair. A Data Lake absolutely has a place. This is not an anti-Data Lake article. For silo-based analytics use cases, a Data Lake can and should exist as part of a permanent, live, operational Data Mesh. One does not replace the other, despite what many are led to believe by vendor whitepapers that conveniently blur the line between the two.

A Data Lake and a Data Strategy are two very different topics. One is a thing you build. The other is how you make sure the thing doesn't become the most expensive puddle in the federal government.

Your systems and databases aren't waiting to be centralized. They're a decentralized Data Mesh. They always have been. They always will be. Every large agency is a collection of Lines of Business, each with their own systems, their own data, their own use cases, and their own operational reality. Pretending you can pour all of that into one lake and have it magically make sense is like expecting a library to organize itself just because you put all the books in the same building.

(More on Data Mesh in Part 3. It deserves its own deep dive.)

The question that exposes everything

Here's the question that exposes the gap every single time: who owns the data going into your Data Lake?

Not who maintains the system. Not who manages the servers. Not who has admin credentials. Who owns the data: the business rules, the authoritative version, the lineage from source to destination? If nobody can answer that question? You don't have a Data Lake project. You have a very expensive ingestion pipeline with no quality controls. Congratulations. You just automated the chaos. Enter the spreadsheet jockey, right on cue.

Ask four questions before you write a single purchase order:

1. Does your agency have a documented, enterprise-wide data governance framework? Not policy sitting in a binder collecting dust, but an active, living framework with named data owners, defined authoritative sources, and verification and validation processes?
2. Are your data standards defined at the enterprise level? Not just inside each silo?
3. Do you know which systems hold the authoritative version of your most critical data? And does everyone agree? [side note: they don't]
4. Can your enterprise describe itself in three seconds during a crisis, or does someone need to open a spreadsheet?

If you can answer yes to all four, a Data Lake might be exactly the right next step. If you can't? The Data Lake isn't your problem. It's your escape from the problem. And it's going to cost seven figures to learn that lesson again.

The real conversation: buying over governing

Here's what nobody wants to say out loud. The problem isn't that agencies buy bad tools. The tools are fine. The problem is that the entire incentive structure (from vendor compensation to IT budget cycles to how federal managers get promoted) rewards buying over governing. Until data governance becomes a 1st Class discipline with the same organizational weight as program management, the pattern will repeat. Different tool name. Same outcome. Same landfill.

The good news? This is fixable. And it doesn't require a seven-figure purchase order.

Document your authoritative sources. Define your enterprise data standards. Assign data ownership that lives with the mission, not with IT. Build the foundation. Then, and only then, let the tools do what they were designed to do.

When you do this right, something remarkable happens. The tools you already own start working better. The APIs start delivering trustworthy data. The dashboards stop lying. And the next tool you buy? It walks into an environment where it can actually succeed. That's not a vendor pitch. That's math, not magic.

The vendor who understands this and helps the agency mature its data environment before pushing product? That vendor earns a partnership that lasts. The IT manager who champions governance over procurement? That person changes the trajectory of the entire enterprise. And the agency that gets the four words right? They stop feeding the landfill and start building something that actually works.

Four words. Same order. Same answer.

Data Governance. Data Standards. Data Management. Data Exchange.

The lake can wait. The governance can't.

Part 2 of The Governance Series by daitagov. First published on LinkedIn.

The Menu

Are you ready to order?

Yes. The platform. Seven figures, full enterprise license.

And what are we putting on it?

...Is there a menu?

Dave: Big news. Leadership approved the new data platform. Seven figures. Full enterprise license.

Jen: Nice. What data are we putting in it?

Dave: That's Phase 2.

Jen: What are the data standards?

Dave: Phase 3.

Jen: Who owns the data?

Dave: That's more of a governance question.

Jen: Right. So when does governance start?

Dave: It's not in scope.

Jen: So we bought a seven figure tool with no data, no standards, and no governance.

Dave: Yes but the demo was incredible.

Jen: ...

Dave: They had a dashboard with live charts.

Jen: Of what data?

Dave: Demo data.

Jen: Outstanding.

If that conversation made you wince? Good. It should. If it made you laugh because you've lived it? Welcome. Pull up a chair.

I'm giving myself a birthday gift: my first LinkedIn post and editorial series. Ever.

I will opt out of posting about "10 Ways to Be a Leader Before Breakfast" and "why I'm successful and you should feel bad about it". Not my wheelhouse, but here's why I'm finally writing.

Myself and most of my colleagues, people who have spent decades inside federal programs, have been making the same observations for years. In hallways, on whiteboards, in post mortem "Lessons Learned" which nobody reads. The same patterns. The same mistakes. The same outcomes. And we keep watching talented people and capable organizations fall into the same traps with the best of intentions. So this is Part 1 of an ongoing series to crystalize and discuss these patterns. To help us all recognize them more often and ask some honest questions to any Federal Agency out there who has seen them up close.

WARNING: It's going to be direct. Along my career, the best mentors I have known have all been brutally honest at all times. None of them ever won a personality contest but they were (1) authentic, zero time for platitudes, (2) DEAD ON about the subject at hand and (3) had an unquestionable track record of success in their wheelhouse. If this series comes across like the relative at Thanksgiving who pokes a hole in your Grandma's Etsy business plan?

Guilty as charged.

But like that person, the goal is to save the business (OR) kill it as quickly as possible for Nana's sake. Stick around. We're rooting for you Federal agencies out there.

Why I'm writing

First, let's be clear about something. We all love technology to some degree or another. My career started building and testing the very first "personal computers" (google "Columbia Data Products"). Then a Formula 1 speed of tech waves ensued for networks (Novell), the early email (Crosstalk and WordPerfect Office), client server (Lotus Notes), then "the interwebs", cloud, analytics, and so on. Every wave was exciting and every wave changed everything. Now it's 2026 and AI?

AI might be the most important paradigm earthquake since the printing press or, I don't know, perhaps the discovery of FIRE by humans. In 2026, building these early AI systems and agents on government infrastructure right now is EXCITING. Far beyond any previous tech wave. So the themes in this series are not coming from myself or others who are afraid of the future role of AI in Government systems. In fact, it's quite the opposite.

This is coming from people who have watched the future get sabotaged, repeatedly, by skipping one critical step. AI could be the next tech casualty to fall short of expectations.

Here goes.

Four words, in this exact order

There are four words that matter in enterprise data, and they go in this exact order:

Data Governance → Data Standards → Data Management → Data Exchange.

Your favorite software tool? The one you've been dreaming about installing for your org? The one where the vendor demo was so good you've been operating as their pro bono sales rep with your cubicle neighbors? That tool belongs in the last two categories. Never the first two. Ever. Read that over and over again as needed.

Still there? I need to check in, as this is where we lose half the room. Why? Because most federal agencies start with tools. They need them always and lots of them. An RFI goes out. A shiny platform gets procured. Best of intentions, real budget, even aligns with strategy. Eighteen months later it's sitting in the software landfill next to the last platform, the one before that, and the one before that. And here's the part nobody talks about: the vendor didn't want that outcome either. No commercial product company wants the reputation of "that platform failed us" before their platform and tools even had a chance to impact the agency's mission.

Federal software vendors build capable products. They deserve a fair shot. But getting a purchase order and a few installs is like getting a tee time. It doesn't mean you can play golf.

When the tool is aligned with the agency mission instead of just the building advocate, it's a much better long term value proposition for everyone: the agency, the vendor, the taxpayer. Vendors don't want to end up in the landfill any more than we want to put them there. But it requires both sides to understand what the platform and toolset is walking into.

The pantry is the problem

I used AI to ask our database who the authoritative source was. It replied "you should ask the other database."

Why do so many capable enterprise software platforms and tools fail? Because we handed world class products ungoverned, unstructured, non authoritative data and asked them to perform miracles. That's like handing Gordon Ramsay a kitchen full of expired ingredients and then blaming him when dinner is terrible. The chef isn't the problem. The pantry is.

"Garbage in, garbage out" is the Mick Jagger of IT catch phrases and is making a comeback. We must admit it still rings true with modern APIs and absolutely rings true with AI today. Across the Federal IT landscape, the technology changes every few years but guess what? The failure mode hasn't changed once.

[side note: In case you're wondering, the boy-band-one-hit wonder catch phrase in Federal IT was "Big Data" and saying it as often as possible to sound smart. Most of us in this industry are relieved it's gone from the tech lexicon. Word of advice: stop saying that phrase please, it makes the kids "cringe".]

Large agencies managing hundreds of systems and thousands of databases almost always have hundreds of data silos. And everyone treats the silos like the disease. They're not. They're a symptom. The real diagnosis? Zero enterprise data governance. Nobody has documented the authoritative sources for their own data. Who owns it? Who maintains it? Who publishes the authoritative version? What's the data lineage? Policy enforcement? Where's the configuration management? Silence.

Here's a question worth sitting with: does your agency leadership regard data governance as a critical mission enabler, a 1st Class discipline embraced by all? Or as a geeky administrative exercise that is (inexplicably) unrelated to critical operations?

Be honest. Because that answer explains almost everything.

QUESTION: When did any critical agency discipline which we now take for granted move from the kids table to the adults table?

There was a time when many Federal agency enterprises viewed master scheduling, configuration management, Verification & Validation or even program management the same way. It was seen as overhead, bureaucracy, paper pushing that "real operators" didn't need. Until projects started collapsing, requirements failed beyond repair, budgets evaporated, and entire programs were publicly cancelled. It took a generation of expensive, painful lessons before program management earned its seat at the table. Data governance is fighting that exact same battle today. And the agencies that figure this out first will modernize years ahead of everyone else. Think simply throwing everything "AI" at literally everything you have will fix known and unknown data challenges?

Artisanal data processing

And every organization has a hero. The spreadsheet jockey who whips up a complicated Excel file at 2am just in time to brief leadership during the latest crisis. Everyone applauds. Seriously. This is happening in your building right now and can be witnessed daily by all of us. It's like watching a matador take a bow after the eighth pass. The crowd goes wild. The bull is still in the ring. And sooner or later, the math catches up. (This topic gets its own deep dive later in the series.)

That is not automation. That is the exact opposite of automation. Your critical agency processes and operations are not going to GET to automation if your mission ops suffer from a systematic reliance on "Human Middleware". So ask your doctor if an emergency, painful tattoo removal of human middleware is right for you.

Does that impact your favorite support contractors? Yeah. It probably does. Stay focused.

(Not to worry, we are about to see an army of agency spreadsheet jockeys transform into "AI jockeys" by the thousands.)

Meanwhile, the metric that actually matters? What some call Data Excellence, what I refer to as Data Maturity, never moves. Not once. And the cycle repeats for every Line of Business. You could set your watch to it, except the watch is also ungoverned.

Walk towards the light

Here's what we keep coming back to. AI is too important, too transformational, to let it FAIL SPECTACULARLY the way too many previous generations of technology platforms have in government.

So the goodness of AI or automation modernization cannot be transformational if you skip governance.

Let that sit for a second.

What an agency CAN do, and this is the genuinely exciting part, is give modern platforms and capable tools exactly what they need to succeed: authoritative, structured, well governed, mature data. When that happens? The software platforms and tools don't just work, they thrive. Down in the Star Trek engine room, APIs deliver clean, trustworthy data which maintains verification and validation from end to end.

...Suddenly dashboards stop lying to leadership.

And AI? We're already seeing quick, reactive AI solutions spit out unreliable garbage for our most important data. Wait, what happened? I thought our new chatbot was magic? Heard somewhere in an AI demonstration: "Ha! You see? I told you AI was no good, it doesn't even understand our data governance!"

...Well, the question is... do you?

Here's the difference that matters. There's a world of gap between a RAG-based chatbot that ingests unstructured PDFs and spits out a different answer every time you ask the same question, and an AI model built on governed, structured, authoritative data that provides the correct response, consistently, every single time. Same question Monday. Same question Friday. Same answer. The right answer. That's not a theoretical difference. That's the difference between a novelty demo and a production system people trust with mission critical decisions. One is a party trick. The other is governed infrastructure.

The good news? This is fixable. And it's not as complicated or expensive as the industry has made it sound. If you're STILL here? Wow, thank you. Here's my favorite phrase with my colleagues...

You cannot "AI" or outsource what you cannot govern. Stand in the mirror and repeat that to yourself.

Every stakeholder from federal agencies, vendors, contractors and engineers has a chance to get aligned here. The vendor who understands the mission and governance and helps the agency mature its data excellence isn't just selling software. They're building a partnership that lasts. The agency that manages its own data governance and feeds tools clean data isn't just buying technology. They're building a foundation that every future investment benefits from. Everyone wins. And the landfill gets a little emptier.

One use case I am working on is building this concept into a 200,000+ record sandbox. Siloed legacy federal systems consolidated into a single governed registry, which is like giving Red Bull to AI powered components. Once you see an AI responding with structured responses you cannot un-see it. Early results are great, no hallucinations. It works because the data governance and data standards came first. Bonus: we then began testing to see if local AI models can help highlight and measure where the data quality gaps exist across silos. Try comparing a bull fighting event to watching a Blue Angels show.

In 2026, the future is incredible. The tools are incredible. AI is going to change everything. But four words have to come first. In order.

Data Governance. Data Standards. Data Management. Data Exchange.

Get the first two right and the last two take care of themselves. Skip them and no tool, not even AI, will save you. You can't microwave your way to a Michelin star. And you cannot explain to your leadership why simply adding a 7 figure AI tool to your Data Lake failed miserably.

We've all watched this movie too many times. This series is about writing a different ending together. Now that the car is on the road, buckle up and let's go.

Part 1 of The Governance Series by daitagov. First published on LinkedIn.