Levels of Architecture
In one week, DabbaGo's architect is asked three things: how to split a tangled pricing class, how to connect the ordering app to a company's HR system for office lunch plans, and whether all business lines should share one customer database. All three are "architecture", but they happen at different heights, for different people, over different lengths of time.
The rule
Zoom out one level, widen the audience, lengthen the horizon.
Think of a map app. Zoomed in you see one street; zoomed out you see the city, then the state. Architecture works the same way. Four common levels:
| Level | Scope | Typical question | Main audience | Horizon |
|---|---|---|---|---|
| Code / component | Inside one module | How should pricing and discounts be split into classes? | Developers on one team | Days to weeks |
| Application | One deployable app | How is the ordering app divided into modules and layers? | The app's team | Months |
| Solution | Several systems for one business need | How do ordering, invoicing and an HR system combine into office lunch plans? | Several teams, product owners | A project or quarter |
| Enterprise | All systems of the organisation | Should every business line share one customer account system? | Leadership, all teams | Years |
As you zoom out, two things change together. More people are affected, so communication matters more than detail. And the decision lasts longer, so its reasons matter more than its mechanics.
Different job titles often follow these levels: a tech lead at the code and application level, a solution architect for projects that cross systems, and an enterprise architect for the whole portfolio. In a small company like early DabbaGo, one person does all four.
The shortcut
Count the boundaries a decision crosses.
- Stays inside one module → code / component.
- Crosses modules but stays inside one app → application.
- Crosses several systems (built or bought) for one goal → solution.
- Crosses business lines or the whole company → enterprise.
Splitting the pricing class
Only the order module changes; nothing outside notices. Zero boundaries crossed: code / component level.
A common mistake is solving a problem at the wrong level. Arguing about class names in an enterprise meeting wastes leadership time. Settling a company-wide data policy inside one team's code review hides a decision that everyone else needed to see.
Drills
Answer fast — trust the rule.
Deciding that DabbaGo's rider app will have separate modules for job offers, navigation and earnings is which level?
DabbaGo connects its ordering app, a bought accounting tool and a bank's payout system to pay kitchens weekly. Which level is this?
As you move from application level to enterprise level, what happens to the decision's time horizon?
A developer changes, inside a pull request, which customer data DabbaGo keeps across all business lines. What went wrong?
Remember
- Four levels: code / component, application, solution, enterprise.
- Shortcut: count the boundaries a decision crosses; more boundaries means a higher level.
- Trap: settling a decision at the wrong level, so the wrong people see it.