Robin Tanner.

I have spent sixteen years inside enterprise data architectures — building them, repairing them, and occasionally being asked to render a verdict on them. The practice you are reading about is the consequence of those years.

Inteledyne has been my consulting vehicle since 2012. The client work has spanned higher education (University of Wisconsin), enterprise software (Salesforce), aerospace and satellite communications (Viasat), retail (Taco Bell), healthcare (Blue Shield of California, Healthcare Partners of Nevada), financial services (Bank of America, SEI Investments via Hashmap/NTT Data), networking and tech hardware (Poly/Plantronics, Juniper Networks via Hashmap/NTT Data), and several smaller engagements. The work has been variously described as solution architecture, data architecture, AI architecture, and DevOps strategy. I think of it as one practice with several emphases.

The throughline is this: I write code in the same engagements where I write architecture. I have led teams of engineers and I have been the engineer when that's what the moment required. This matters because architecture documents that have not survived contact with implementation tend to mislead the organizations that follow them.

The strategic ambition

Across those sixteen years a single observation kept reasserting itself: source-system change is the dominant cost driver in modern data layers, and most architectures don't address it directly. They handle it reactively — schema drift causes outages; outages get patched; the patches accumulate into a structure no one fully understands. I have rebuilt several such structures.

The pattern I came to favor is a self-evolving foundation: ingestion that absorbs schema change without code change, automatic relationalization of nested payloads, and elastic compute that scales to actual usage. At University of Wisconsin I built a production version of this for a consolidated EMR data lake. At Salesforce I built a smaller-scoped version for the marketing analytics platform that was eventually adopted enterprise-wide.

Lake AI — operated through Axium Data Solutions — is the productized version of that pattern. It exists because the engagements that produced it kept producing it. At some point the question became whether the work was a series of engagements or the iterative refinement of a single product. I concluded it was the latter.

How I work

Engagements are direct. The first conversation is free. If we are a fit for the work in front of you, we'll discuss scope and structure plainly. If we are not, I will tell you who to call instead — there are several practitioners I know personally whose work I would vouch for in domains where I cannot.

I do not pad engagements. I do not bring junior consultants who learn on your dime. I work directly with your engineering leads. The deliverables are documented, defensible, and structured to outlast my involvement.

When the right first engagement isn't a contract — it's evidence — I have built a productized two-week diagnostic called the Data Layer Health Assessment. It is the way most clients begin working with me.

Outside the work

I live in Austin, Texas. I am continuously studying — at present, in agentic systems and in the practical limits of language-model reasoning over enterprise data. The internal research that informs Lake AI's roadmap is the visible portion of that study.