The four layers underneath every growth problem
Enterprise architecture has a reputation for being something large companies do to produce documents. Underneath the reputation is a genuinely useful idea, and it is small enough to explain in a page.
Every business sits on four stacked layers.
The layers
Business architecture. What you do and how you create value. Your positioning, your personas, your promise, and the motions that turn attention into revenue: attract, convert, close, deliver, expand.
Application architecture. The software that runs it. Your CRM, your phone system, your forms, your content, and every source system where work actually happens.
Data architecture. The records and the rules that govern them. Contacts, consent, deals, subscriptions, transactions, and the map of which system owns which fact.
Technology architecture. The infrastructure underneath. Domains, DNS, carriers, APIs, servers.
The one principle
Each layer must serve the one above it. Technology serves data, data serves applications, applications serve the business.
Almost every expensive problem is a break in that chain, and the break is almost never on the layer where the symptom shows up.
Why the layer matters
Because the fix goes on the layer where the cause is, and people apply it where they noticed the problem.
Sales says the leads are bad. That is felt at the business layer, so the response is a business-layer response: change the targeting, rewrite the copy, retrain the team.
But if the CRM cannot see product usage, or if consent is modeled so that half your contacts are unreachable, or if job titles arrive as free text and no segment is accurate, then the lead quality problem is a data architecture problem. Every business-layer fix you apply to it will feel like it half-worked and then decay, because the constraint never moved.
The reverse happens too. Companies buy sophisticated tooling for a problem that is really positioning. New software cannot fix an unclear promise. It just makes the unclear promise arrive faster.
Naming the layer changes the conversation
"Our reporting is bad" is not actionable and generates opinions.
"Our data architecture has no path from the billing system to the CRM, so revenue is invisible to marketing reports" is a specification. It says what to build, who builds it, and how you will know it worked.
That translation is most of the value of the model. Not the diagram. The precision it forces.
Greenfield is where this is worth most
A common assumption is that architecture is for untangling legacy messes, and that a young company should move fast and sort it out later.
The opposite is closer to true. Designing the wiring deliberately is cheaper than rebuilding it under load, and the decisions that are nearly free at the start, what a lead is, which system owns revenue, how consent is modeled, become the expensive ones once there is history to migrate.
You do not need all four layers documented on day one. You need to know which layer you are working on, and to notice when you are treating a symptom two layers above its cause.