Architecture becomes much more useful when we can trace a technical decision back to the business outcome it supports.
Discussions about architecture often begin with implementation.
Microservices.
Databases.
Message brokers.
Cloud platforms.
These are important decisions. But they describe only part of the system.
Before choosing a message broker, we need to understand what must happen when a business event occurs.
Before splitting an application into services, we need to understand the responsibilities we are separating.
Before selecting a database, we need to understand the information it will hold and who owns it.
A useful way to organize these questions is through four architectural domains:
- business architecture,
- data architecture,
- application architecture,
- technology architecture.
They are often presented as layers. I find that useful as a starting point, provided we remember that decisions move in both directions.
Business needs influence technology.
Technical constraints also influence what the business can deliver.
This post explores how these domains connect, using a simplified subscription service as a running example.
🧭 Start with the Questions
Each architectural domain brings a different perspective.
| Domain | Central question | Typical concerns |
|---|---|---|
| Business | What must the organization be able to do, and why? | Capabilities, value streams, processes, responsibilities |
| Data | What information does the organization need? | Meaning, ownership, relationships, quality, lifecycle |
| Application | Which software responsibilities support the work? | Applications, services, boundaries, contracts, integrations |
| Technology | What technical foundation supports those applications? | Compute, networking, storage, runtimes, platforms, operations |
The boundaries are useful, but they are not walls.
A subscription renewal involves a business process, changes to data, application behavior, and technical infrastructure.
Understanding the whole operation requires all four perspectives.
💼 Business Architecture: Define the Capability
Imagine a company launching a subscription service.
Customers should be able to:
- choose a plan,
- activate a subscription,
- renew it,
- change it,
- cancel it.
The company also needs to collect payments, resolve billing issues, and understand revenue.
These are business concerns before they become software concerns.
Subscription management is a business capability.
A customer portal is one possible application supporting that capability.
A database is one part of its implementation.
Keeping that distinction clear matters.
If we define the capability as “having a subscription microservice,” we have already mixed the business need with a technical solution.
A more useful starting point is:
The organization must manage a customer’s subscription throughout its lifecycle.
Now we can ask meaningful questions.
When does a subscription become active?
What happens after a failed renewal?
Who handles an exception?
What does the customer expect?
These answers establish the behavior the software must support.
Capabilities and Processes Describe Different Things
A capability describes what the organization can do.
A process describes how a particular piece of work happens.
For example:
| Concept | Example |
|---|---|
| Capability | Subscription management |
| Process | Renew a subscription after a successful payment |
| Business rule | Access remains available until the paid subscription period ends |
| Outcome | Customers receive the access they have paid for |
This gives the engineering work a clearer foundation.
🗂️ Data Architecture: Make Meaning Explicit
The subscription service needs information about customers, plans, subscriptions, payments, and access rights.
Listing those entities is a beginning.
The more difficult questions concern meaning and authority.
What does an “active subscription” mean?
Can a subscription remain active while a renewal payment is being retried?
Does a successful payment automatically mean access has been granted?
Which system is authoritative for each fact?
Consider these statements:
The payment succeeded.
The subscription was renewed.
The customer can access the product.
They describe related facts.
They do not necessarily become true at the same moment.
A payment provider may confirm a payment while the subscription application is temporarily unavailable. The subscription may then be renewed before an access-management application processes the change.
Treating all three facts as one status field hides that behavior.
Ownership Matters More Than Duplication Alone
Several applications may need a subscription’s status.
That does not mean they should all independently decide its value.
A useful design identifies:
- the authoritative owner,
- the consumers,
- how changes are distributed,
- how stale information is handled,
- how inconsistencies are corrected.
A reporting system can hold a copy of subscription data while the subscription application remains authoritative for operational changes.
The important question is:
Who can change this fact, and how do other systems learn about the change?
Data architecture also addresses quality, retention, access, and deletion.
Those decisions affect application behavior and infrastructure choices later.
🧩 Application Architecture: Define Responsibilities
Once the capabilities and information are understood, we can examine the software that supports them.
Our example might involve:
- a customer portal,
- a subscription application,
- an external payment provider,
- an access-management application,
- an accounting system.
Application architecture describes their responsibilities and relationships.
The payment provider processes payments.
The subscription application manages subscription rules and state.
The access-management application determines whether a customer can use the product.
Accounting records the financial consequences.
These responsibilities may be implemented in separate applications, modules within one application, or a mixture of custom software and external products.
A responsibility boundary does not automatically require a network boundary.
A modular monolith can preserve clear responsibilities. Several independently deployed services can still be tightly coupled.
The useful question is whether the boundaries make behavior and ownership easier to understand.
Contracts Describe the Collaboration
Suppose the subscription application receives a payment notification.
It must decide whether the payment applies to a renewal, whether it has already been processed, and what subscription change should follow.
That raises practical questions:
- Can the notification arrive twice?
- Can notifications arrive out of order?
- What happens if processing fails?
- How can an operator identify a payment that has not produced the expected renewal?
An API or event schema describes the shape of the exchange.
The application design must also describe its meaning and failure behavior.
A contract becomes more useful when both sides understand what receiving a message requires them to do.
⚙️ Technology Architecture: Provide the Foundation
Technology architecture covers the technical environment supporting the applications and their data.
Infrastructure is a major part of it.
So are runtimes, middleware, platform services, and technology standards.
For our subscription service, the foundation might include:
- application compute,
- a relational database,
- messaging,
- networking and identity,
- secrets management,
- logs, metrics, and tracing,
- backup and recovery mechanisms.
These choices should follow concrete requirements.
How much traffic is expected?
How quickly must a failed operation recover?
What data loss is acceptable?
What can the team operate reliably?
A managed platform may reduce operational work. It also introduces service constraints, costs, and dependencies.
A self-managed component provides more control while assigning more operational responsibility to the team.
Architecture makes those tradeoffs visible.
🔗 Follow One Requirement Across All Four Domains
Now introduce a business requirement:
After a successful renewal payment, a customer’s access must be restored within one minute.
That sentence looks simple.
Implementing it requires several connected decisions.
| Domain | Decisions to resolve |
|---|---|
| Business | Define when the one-minute period begins, the expected service level, and responsibility for exceptions. |
| Data | Define authoritative payment, subscription, and access states, including identifiers and timestamps. |
| Application | Coordinate renewal and access restoration, handling retries, duplicates, and partial failure. |
| Technology | Provide sufficient processing capacity, reliable delivery where required, and monitoring of the elapsed time. |
Notice what the requirement does not tell us.
It does not automatically require microservices.
It does not select a message broker.
It does not determine a cloud provider.
Those decisions need additional context.
The requirement does give us something valuable: a basis for evaluating whether the implementation supports the promised outcome.
🔍 Observe the Outcome, Not Just the Components
Suppose every application reports that it is healthy.
The database is available.
The message broker is running.
HTTP requests return successful responses.
Yet some customers wait twenty minutes for access after payment.
Component health alone has missed the business failure.
We need to connect the observations:
- when the payment was confirmed,
- when the subscription was renewed,
- when access was restored,
- which operations remain incomplete.
This allows us to measure the customer-facing outcome.
It also helps locate the point where the process stopped.
Observability becomes more useful when technical signals explain business behavior.
🔄 The Relationship Works in Both Directions
It is tempting to treat architecture as a one-way sequence:
business requirements first, infrastructure last.
Real projects are more iterative.
An external payment provider may deliver notifications with delays.
A legacy application may support only scheduled imports.
The available team may be unable to operate a proposed platform reliably.
These findings can change the solution, the delivery plan, or the business promise.
The architectural work is to expose the constraint and decide what to do about it.
Perhaps the integration needs to change.
Perhaps the customer experience needs an intermediate “payment received” state.
Perhaps the service target needs revision.
The important part is making the decision explicitly, with the relevant people involved.
🚫 Four Domains Do Not Require Four Silos
These perspectives do not require four disconnected teams producing separate documents.
A small product team may discuss all four in the same design session.
A larger organization may distribute responsibility across several roles.
Either way, the decisions must connect.
A capability map has limited value if nobody can relate it to the applications supporting it.
An infrastructure diagram has limited explanatory power if nobody can explain which business operations depend on it.
Documentation helps when it makes those relationships easier to inspect and maintain.
🛠️ A Practical Starting Point
For a new feature, I would begin with a small set of questions:
- Business: What outcome are we enabling, and what rules govern it?
- Data: Which facts are involved, and who owns them?
- Application: Which responsibilities collaborate, and how do they handle failure?
- Technology: What platform capabilities and operational controls support the required behavior?
- Verification: How will we know the complete outcome works?
The answers can be brief.
A focused table, a small diagram, and a few recorded decisions may be enough.
The goal is to make the reasoning clear enough that someone can challenge it, implement it, and revisit it later.
🏁 Final Thoughts
Architecture reaches from organizational intent to the technical environment that makes it possible.
Business architecture defines capabilities and outcomes.
Data architecture establishes meaning and ownership.
Application architecture organizes software responsibilities and collaboration.
Technology architecture provides the foundation for execution and operation.
Their real value appears in the connections.
A business promise should be traceable to application behavior.
That behavior should rely on clearly defined data.
The technology should support the required performance, reliability, and recovery.
And the complete outcome should be observable.
For me, that is what makes architecture useful: being able to explain how a technical decision helps the organization deliver something that matters.
🚀 Follow me on norbix.dev for more insights on Go, TypeScript, Python, AI, system design, and software engineering.