9 posts tagged with "Data Architecture"

I have been stuck on a problem lately. Almost everyone has AI now, and almost none of that activity turns into something a business can lean on, because the value leaks out through everything the tools cannot see. What pulls at me is the next question. If scattered, ungrounded AI is the problem, what would it actually take to run AI at scale inside a regulated business? Not which model to pick. The structure around the models. The deeper I go, the more it comes down to a handful of things, and not one of them is another tool to buy.

Spend any time around how companies actually use AI right now and one thing jumps out. It is everywhere. Someone is drafting copy in one tool, someone else is summarizing a contract in another, a third person is pasting notes into a chatbot between meetings. By every obvious measure, adoption already happened. So it took me a while to work out why all that activity adds up to so little that a business can lean on. The longer I sat with it, the clearer it got that the problem is not the AI. It is everything around it.

Most of the conversation about data strategy at a community bank ends up in the wrong place. People want to talk about tools, vendors, dashboards, the latest architecture. The harder problem is sitting one floor up. The people making decisions do not need more data. They need a small set of things they can act on, and they need it consistently.

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'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.