Understanding the Boundaries and Connections Between Business, Application, Data, and Technology Architecture

Four Layers of Enterprise Digital Architecture

Enterprise digitalization can be viewed as a four‑layer architecture, where each higher layer guides the one below it, and each lower layer provides the foundation for the one above.

1. Business Architecture

Defines "what business to do and how to make money". It answers core questions about business processes, revenue models, departmental roles, and profit mechanisms without touching any IT details.

Outputs: business model, processes, organization, capabilities, profit model, core rules.

Boundary: focuses solely on business logic; e.g., it may state "members earn points automatically" but does not specify the system or database used.

2. Application Architecture

Bridges business and technology by specifying which software systems are needed, their responsibilities, and how they interoperate.

Typical systems: cash register, membership, parking management, merchant management, OA.

Interaction rule example: after a purchase, the cash register triggers the membership system to add points.

Outputs: system inventory, functional boundaries, interaction contracts, deployment patterns.

Boundary: defines system responsibilities and integration, not the underlying technology stack.

3. Data Architecture

Acts as the "circulatory system" of the digital enterprise, determining where data lives, how it is standardized, transferred, and consumed.

Data categories: user, transaction, parking, merchant, foot‑traffic.

Rules: storage locations, master data standards (e.g., unique phone number for members), flow (order data sync to finance, membership, reporting), and usage (daily revenue and traffic reports).

Outputs: data models, standards, flow diagrams, storage solutions, governance rules, application scenarios.

Boundary: sets data policies without prescribing hardware or specific platforms.

4. Technology Architecture

Defines the concrete hardware, software, and components that realize the applications and data layers, ensuring stability, security, and performance.

Choices include servers (on‑premise or cloud), databases (MySQL/Oracle), caches (Redis), message queues (RabbitMQ), development stacks (Java SpringBoot, Vue), deployment, and security measures.

Outputs: technology stack selection, deployment diagrams, middleware choices, network topology, security and scaling plans.

Boundary: concerns only implementation details and infrastructure, not business logic.

How the Four Layers Interact

Top‑down influence: Business architecture determines required applications; applications dictate data requirements; data and applications together shape technology choices. A mis‑aligned business model renders downstream work wasteful.

Bottom‑up support: Technology provides the foundation for data and applications; without a solid technical base, applications fail and business cannot operate.

Data as the glue: Data originates from business, is captured by applications, governed by data architecture, and stored/processed by technology, enabling analytics and intelligent decisions.

Concrete Example: Campus Ordering System

Business Architecture: Goal – provide campus employees with online ordering; core flow – select restaurant → choose dishes → place order → pay → merchant prepares → employee picks up; revenue – merchant commission or service fee.

Application Architecture: Three front‑ends – user mini‑program, merchant backend, admin backend; capabilities – WeChat Pay integration, SMS notifications; interaction – order triggers merchant notification.

Data Architecture: Tables – users, restaurants, dishes, orders, payments; flow – order → payment status sync → merchant sync; reports – daily order, sales, revenue analysis.

Technology Architecture: Frontend – Vue + mini‑program; Backend – Java SpringBoot; Database – MySQL; Deployment – Tencent Cloud lightweight server with Nginx; Cache – Redis for hot‑dish data.

Common Pitfalls

Confusing "architecture" with only technology architecture; business architecture is the driver.

Over‑engineering: small projects need only simple layers; unnecessary complexity wastes resources.

Rigid boundaries: in practice layers often overlap (e.g., application and data design together).

In summary, business architecture defines "what we do", application architecture defines "which systems support it", data architecture defines "how data is managed and used", and technology architecture defines "the technical foundation"; each layer decides direction for the next, while lower layers provide essential support, with data threading through all layers.