Every company says it wants to be data-driven. Most are report-driven: three versions of the same number, a warehouse bill nobody can explain, and pipelines held together by the one person who remembers why. Modernization starts by drawing what actually exists, then fixing it in the order that pays.
What this covers
- Enterprise data strategy, maturity assessments, and modernization roadmaps
- Pipeline design and modernization — ETL and ELT, batch and streaming, ingestion architecture
- Warehouse, lake, and lakehouse work: data modeling, schema design, migration planning
- Cloud data architecture and cost optimization across AWS, Azure, and Google Cloud
- Data quality, validation, reconciliation, and observability
- Governance that survives the quarter: ownership models, stewardship, catalogs, standards
Analytics & BI — the visible half
Modern pipelines only matter if someone decides something with them. The analytics sub-practice covers KPI definition, executive and operational dashboards, self-service strategy, Tableau and Power BI implementation, reporting rationalization, and metric standardization — every number defined once, with one owner.
How the work runs
The first thing I do is draw the map. Not an idealized architecture diagram — the real one: every source system, every pipeline, every spreadsheet that quietly became a production dependency, and the reports sitting on top of them. Most of that comes from reading job schedules, query logs, and the warehouse bill, then sitting with the two or three people who get called when something breaks. The scope identifies which systems and reports to map, what access is available, and how the findings will be checked.
Then I trace numbers. Take the figure the leadership team looks at most and follow it backward — from the slide to the dashboard, to the query, to the table, to the rows that produced it. Every point where it changes definition, gets filtered, arrives late, or gets corrected by hand is a defect with a cause and an owner. This is slower than a maturity questionnaire, and it is the part nobody regrets paying for, because it turns “our data is a mess” into a numbered list you can work through.
Only then do I sequence. Modernization is easy to plan and hard to order. The tempting first project is the platform migration; the one that pays is usually a reconciliation nobody wants to own. The roadmap puts the changes with the most drag behind them first, says in rough terms what each costs and what it unblocks, and is short enough that a busy executive reads all of it.
What you get
Written artifacts, not a deck of observations. Each one is built to keep working after I am gone:
- A current-state map of sources, pipelines, and reports — including the undocumented ones.
- A defect list from tracing real numbers end to end, each item with a cause, an owner, and a fix.
- A metric definition sheet: every number defined once, with its grain, its filters, its refresh, and the person who decides when the definition changes.
- A sequenced roadmap, costed to order of magnitude, with the first ninety days broken out.
- A reporting inventory marked keep, merge, or retire — so the dashboard count goes down.
- For build work, requirements and a scope somebody can sign without a later conversation about what was implied.
When this is not the right call
If you already know what is broken, have the people to fix it, and need hands, hire hands. I am one person. I am worth paying when the problem is diagnosis, sequencing, or a definition fight nobody has been able to settle — not when the work is a known volume of pipeline builds.
If the real disagreement is between two executives about what the number should mean, no platform fixes that. It is a decision, and it belongs to whoever owns the number. I can frame the choice and write down what each option implies. A migration started in the middle of that argument only moves the argument to a newer warehouse.
And if your reporting is agreed on — slow, unglamorous, but trusted — modernization may be the wrong spend this year. A cloud bill that annoys you is not the same as a cloud bill that is hurting you. I would rather say so on the first call than discover it in week three.
Start with the data maturity assessment
A scoped investigation of a metric or data flow: trace it from source to output, document quality issues, define validation rules, and prioritize fixes. Agree on the systems covered, deliverables, timing, and fees before work begins.
Agree on the engagement
Start by describing the problem and what would make the work useful. The proposal defines the deliverables, responsibilities, access needed, acceptance criteria, fees, and timing before paid work begins. Implementation, third-party tools, production changes, and ongoing support are included only when explicitly scoped.
Work with Kenny. Sending an inquiry does not commit you to an engagement or require permission to publish your work.
Inspect a working demonstration
Trace an auditable data cleanup: download the dataset, reproduce the totals, and inspect the rejected records. These examples use synthetic data and are not client case studies or guarantees of project results.
Define the investigation before the integration
Start with what a data quality audit should deliver: a scope, traceable findings, owners, and a recheck plan. If two systems disagree, reconcile CRM and accounting records before automating a sync. The downloadable synthetic example shows why equal totals can still hide missing or mismatched records.
Explore the method
Work through the method in the lessons below. Free lessons require an account; Series lessons also require eligible learning access. Each lesson link is labelled so you can check the requirement before starting. Learning paths may contain lessons with different access requirements.
- Why two dashboards disagree (Series access required) — the four ordinary causes behind nearly every mismatch, and how to name yours in a conversation instead of an investigation.
- Trace one number end to end (Series access required) — the tracing exercise above, at a size you can do yourself this week.
- Define a metric so it survives an argument (Series access required) — the six things a definition needs before the number goes on a screen people decide from.
- Read a cloud bill and find the waste (Series access required) — the four places it usually hides, findable in an hour.
If you would rather follow a sequence, Make the numbers hold up runs from disagreeing dashboards to definitions that hold, and Understand the cloud well enough to decide covers the cost and architecture calls behind the platform. The paths include lessons with different access requirements; check each lesson before starting.
Strategy to implementation
Kenny can carry the work from assessment into requirements and delivery support when those stages are included in the agreed scope. See all six service families, or start a conversation.