Any real work with data starts with actually looking at it. Before reaching for a heavyweight analytics platform, the fastest way to get your hands on a dataset is a notebook running on your own machine. That personal workbench is where I do most of my exploring, and Jupyter is what powers it.

The core banking system keeps coming up as one of the biggest constraints on what's possible in bank technology. I have started to understand why.

I used to think banks were just slow. When I was pitching mobile payments to bankers years ago, I couldn't understand why they didn't see what seemed obvious to me. Working inside a bank, I've had to revisit some of those assumptions.

Understanding how banks make money turned out to be more interesting than I expected.

I've spent years building tech startups and, at various points, pitching them to banks. Now I'm on the other side of that table, working as CTO of a community bank. The view is different from here, and I want to share what I'm learning along the way.

In the previous posts, I covered transactional databases for real-time operations and data warehouses for historical analytics. Both work with structured data. But what happens when you need to store log files, images, sensor readings, or raw event streams? That's where data lakes come in, and understanding them has changed how I think about data architecture.

In the previous post, I looked at transactional databases that power real-time operations. But I've learned the hard way that running complex analytical queries against production databases is a bad idea. It slows down the application and puts operational data at risk. Data warehouses solve this by providing a separate system optimized for analysis rather than transactions.

I've been thinking about data architecture lately, specifically how different systems serve different purposes. Every application I've built has relied on a transactional database somewhere in the stack. When a user updates their profile, places an order, or transfers money, a transactional database ensures the operation completes reliably. These systems, also called Online Transaction Processing (OLTP) databases, form the backbone of modern software.

I've worked on projects where there was no clear process, and the chaos is memorable. Features get built before anyone agrees on requirements. Testing happens as an afterthought. Deployments become fire drills. The Software Development Life Cycle exists to prevent exactly this kind of mess.

The SDLC is a structured approach to building software that breaks the work into distinct phases. Each phase has a purpose, produces specific deliverables, and sets up the next phase for success. Understanding how these phases connect has helped me see where my work fits in the bigger picture.

As a software developer and dad to two curious boys, I live in one world of code and another of LEGOs. Watching my kids snap together simple blocks to build increasingly complex creations, I can't help but see the similarity to how we build software from just a few basic "blocks" of code.