Rick Cramer

About Me

I came to data engineering by learning how real systems actually work.

My career has progressed from enterprise-system user and domain specialist to data analyst, SQL developer, product owner, data and analytics engineer, and senior technical consultant. That path gave me experience on both sides of the problem: understanding how organizations operate and building the technical systems that support them.

From business systems to engineering

I spent years working directly with Ellucian Banner before moving formally into analytics and development. That experience taught me that a database schema alone rarely tells the whole story. Business rules, operational workflows, historical decisions, and downstream dependencies all matter.

I later moved through increasingly technical roles involving SQL, reporting, data extraction, relational modeling, integration, performance tuning, ETL/ELT, migration, validation, and production troubleshooting.

At Liberty University, I eventually became product owner of Centralist, a PL/SQL- and Python-based marketing data application. At Unanet, I worked across complex ERP migrations and integrations and served as the primary architect and engineer for Nessie, an automated analytics and data-quality platform.

What I bring to engineering

Deep SQL experience
PostgreSQL, SQL Server/T-SQL, and Oracle PL/SQL across transformation, migration, analytics, troubleshooting, and performance work.
Systems thinking
Experience tracing data through source applications, transformations, integrations, business rules, and downstream reporting rather than treating individual queries in isolation.
Technical and business translation
Years of client-facing work translating business processes, requirements, and legacy-system behavior into durable technical solutions.

How I Work

Engineering principles shaped by production work

Understand the business first

Reliable data engineering starts with understanding what the data represents, how the source system behaves, and what downstream users actually need.

Build for messy reality

Real systems contain incomplete documentation, inconsistent data, edge cases, historical decisions, and competing requirements. I design with those conditions in mind.

Make systems explainable

Good engineering should be understandable by the people who operate, maintain, troubleshoot, and depend on it. Clear logic and documentation are part of the solution.

See the engineering work

Northstar is where I am applying these principles to a production-style AWS data platform from the ground up.

Explore Northstar