What Gets Built Next
Part 6 of 7: After the Data
In 1963, a psychologist named George Miller published a paper that changed how we think about human memory.
His argument was simple.
The human mind has a limited capacity for holding information in working memory. About seven things at once, give or take. Beyond that threshold, we don’t just slow down. We start making errors. We start forgetting. We start dropping things that matter.
His conclusion wasn’t that humans are limited. It was that humans compensate.
We developed language to externalize memory. We developed writing to persist it. We developed institutions (libraries, legal systems, professional guilds) to maintain knowledge that no individual could hold alone.
Every time the complexity of what we needed to remember exceeded the capacity of individual human memory, we built something external to absorb the excess.
The history of human civilization is partly a history of building better external memory systems.
Organizations are no different.
The externalizing pattern
Every infrastructure category I described in Part 4 is an instance of the same thing.
Externalizing something that used to live informally (in human memory, in conversation, in tribal knowledge) into a structured system that can maintain it reliably at scale.
CRM externalized customer relationship knowledge. The memory of who the customer was, what they bought, what they needed = moved from salespeople’s heads into a system.
The data stack externalized operational facts. What happened, when, and to what = moved from scattered spreadsheets and siloed databases into a centralized, queryable infrastructure.
Version control externalized code history. What changed, when, who changed it, why = moved from developer memory and email threads into a system that could track it perfectly and indefinitely.
Infrastructure as code externalized system configuration. How the infrastructure was set up and why = moved from system admin memory and manual processes into declarative files that could be versioned, shared, and reproduced.
The pattern is consistent.
Something that lived in human memory gets externalized into infrastructure when the complexity of maintaining it informally exceeds human capacity.
And every time that externalization happens, it doesn’t just reduce cost. It unlocks capability. Things become possible that weren’t possible before because the knowledge that enables them is now maintained reliably rather than degraded through drift and turnover and the limits of human memory.
What hasn’t been externalized yet
Here’s where the pattern leads.
If we map what has been externalized across the modern enterprise stack — customer relationships, operational data, code changes, infrastructure configuration — a gap becomes visible.
Something that every organization depends on. Something that currently lives primarily in human memory and informal systems. Something that is getting more complex faster than informal systems can manage.
The shared logic of how the business actually operates.
Not the data. The meaning behind the data.
The definitions. The assumptions. The rules.
How revenue gets calculated and what counts toward it. Who the ideal customer is and what criteria qualify them. How the market gets segmented and what puts a company in one bucket versus another. What assumptions drive the forecast. How capacity gets modeled. What the competitive positioning actually is and how it’s supposed to translate into the field.
This logic exists at every organization. It governs every important decision. It shapes every metric, every model, every strategy.
And it lives (almost universally) in the same places human knowledge lived before every previous infrastructure transition.
In conversations. In documents that drift. In the heads of people who were there when the decisions got made. In institutional memory that walks out the door every time someone leaves.
It is, in the language of the pattern, waiting to be externalized.
What externalization looks like here
The previous infra transitions give us a template for what this externalization needs to do.
When CRM externalized customer knowledge, it didn’t just store names and phone numbers. It created a structured representation of the relationship (stages, history, context) that could be shared across an organization and maintained over time.
When the data stack externalized operational facts, it didn’t just move spreadsheets to the cloud. It created a structured, queryable, reliable layer that any system or person could access and trust.
When version control externalized code history, it didn’t just save old files. It created a system for tracking change (who made it, when, why, what depended on it) that made the evolution of complex systems manageable.
The externalization of business logic would need to do the same things.
Not just store definitions somewhere. Create a structured representation of them that can be shared, maintained, and trusted across an organization.
Not just document assumptions. Track how they change: who changed them, when, why, what depends on them.
Not just write down the rules. Keep them synchronized with the systems and tools that depend on them, so that when the logic changes, everything built on top of it updates.
The form factor isn’t obvious yet. These transitions never look obvious from the inside.
CRM didn’t look inevitable when it was Salesforce running on servers in 1999. The data stack didn’t look inevitable when it was a few engineers connecting Postgres to a nascent analytics tool. Version control didn’t look inevitable when it was a workaround three engineers built to avoid emailing files.
They look inevitable now because the infrastructure exists and we’ve forgotten what it was like without it.
Whatever externalizes business logic will look the same way in retrospect.
The companies building toward it
Something worth noting.
The market is already moving.
Not in a single direction. Not with a clear winner. But with the kind of distributed, multivector movement that characterizes the early stages of a category forming.
Data governance platforms expanding their scope from metadata management toward business context. Semantic layer companies building upward from metric definitions toward broader business logic. Planning software companies whose assumptions layer is starting to look like infrastructure rather than just a model input. AI deployment companies discovering that the hard part isn’t the model, it’s the context.
And an emerging set of companies building explicitly toward the gap, toward the layer that sits between the data stack and the applications that act on it, maintaining the business logic that neither currently manages.
None of them has fully defined the category yet.
That’s what early looks like.
What the pattern predicts
History doesn’t repeat exactly. But the pattern is consistent enough to make some observations.
The infrastructure that externalizes business logic will not be built by the companies that currently own adjacent layers, at least not at first. CRM wasn’t built by the rolodex companies. The data stack wasn’t built by the legacy BI vendors. Version control wasn’t built by the project management software companies.
New infrastructure categories tend to get built by people who feel the pain most acutely and can see the gap most clearly (often because they’ve lived inside it).
The externalization will start narrow. It always does. CRM started with contact management. The data stack started with moving data from one place to another. Version control started with tracking file changes for a team of three.
The starting point is never the ending point. The category expands as the infrastructure proves its value and the full scope of what it can absorb becomes clear.
And the companies that establish themselves in the early window (before the category is obvious, before the incumbents move, before the market converges on a definition) tend to define it.
That window is open right now.
One more thing
I’ve been building toward a question across this entire series.
Not an answer. A question.
Because I think the most interesting thing about this moment isn’t the infrastructure that’s going to get built. It’s what becomes possible when it does.
Every previous infra transition didn’t just reduce cost. It changed the ceiling.
What’s the ceiling that organizational context infrastructure raises?
That’s what the last part of this series is about.
Part 7 drops next week.
Until the next one,
— Adnan
P.S. Have a question or topic in mind? Drop it in the comments.
P.P.S. If this resonated, subscribe + follow on LinkedIn for more.