What Needs To Endure

On my team we talk about where we “pour concrete.” It’s a useful metaphor for a real decision that comes up constantly in systems work “what do we lock in, and what do we leave flexible?” Concrete can be broken, but it’s expensive and slow, and the cost of getting it wrong is rarely just technical. It ripples into the organization, into the relationships, into the work that depends on the structure you’ve built.

Every architecture decision is a bet on the future. What’s less often stated is the timeframe of that bet. What do we need for the next year? What does this ultimately need to look like? Those are different questions with different answers, and in my experience the distinction is frequently implicit — understood loosely, assumed rather than aligned on, and occasionally the source of expensive surprises later.

I’ve been in and around technology and software development for over thirty years. For most of that time the dominant conversation has been about speed and flexibility. Agile. Lean. Rapid prototyping. MVP. The underlying assumption in most of these approaches, stated or not, is that course-correction is cheap — that you can move fast, learn, and adjust without carrying too much cost from the decisions you made in the first sprint.

That assumption was always more optimistic than accurate. But it’s breaking down faster now.

The systems we build have become load-bearing in ways that earlier generations of software simply weren’t. We’ve moved from record-keeping to process orchestration to something harder to name — systems that are ambient, interconnected, and increasingly embedded in how organizations function at a level that wasn’t true when a database was just a database. When those systems need to change, the cost isn’t just technical. It’s organizational, relational, operational. The concrete is everywhere, and a lot of it was poured without a clear conversation about how long it was meant to last or what structures would be built on top of it.

AI accelerates this. If the last article’s argument was that speed amplifies the cost of building the wrong thing, the argument here is that speed also compresses the window in which structural decisions get made thoughtfully. When you can build faster, the architecture phase doesn’t automatically get more rigorous — it often gets shorter. The questions that were already being underasked get less time, not more.

What needs to endure is not a technical question. It’s a question about purpose, about organizational intent, about what this system is ultimately in service of. Architecture at its best is the translation of those answers into structure. But that translation requires the answers to exist first — stated, aligned on, and understood across the people who will live with what gets built.

The best architects I’ve worked with carry a version of this question into every engagement. Not just what are we building, but what does this need to still be true in five years. It sounds obvious. It’s practiced far less often than it should be.

In a faster world, that question doesn’t get easier to ask. It gets more important.