Architectural Design Basics

Architectural Design Basics

Once the analysis phase ends — requirements signed off, data model agreed, business processes documented — the project enters a new territory: architectural design. Where analysis answers "What must the system do?", architectural design answers "How, at the highest level, will it be structured?" This is the moment a systems analyst partners with software architects to translate every requirement and every entity in the ERD into a concrete, deployable structure. Getting this structure wrong is expensive; changing a fundamental architectural decision late in a project can cost weeks and trigger cascading rework.

This lesson introduces the vocabulary and thinking tools you need to participate in, challenge, and document high-level architectural decisions — layers, tiers, and the classic three-tier pattern that underpins the majority of business information systems built today.

Layers vs Tiers — A Critical Distinction

Two terms that are often confused are layer and tier. Understanding the difference prevents expensive misunderstandings during design reviews.

• Layer is a logical concept — a grouping of code by responsibility. Layers exist purely as a design convention; they can all run on a single machine. The classic three-layer model groups code into: Presentation (UI logic), Business Logic (rules and workflows), and Data Access (reads/writes to storage).
• Tier is a physical concept — a separately deployable runtime, typically running on its own machine or container. Tiers communicate over a network. A two-tier system has a client and a database server. A three-tier system adds a dedicated application server between them.

A three-layer architecture can be deployed as a two-tier system (all layers on one application server plus a separate database). Or it can be deployed as a three-tier system, with the presentation layer on a web server, the business logic on an application server, and the data access layer connecting to a database server. The layers describe what the code does; the tiers describe where it runs.

The Three-Tier Architecture in Detail

Consider a clinic appointment booking system. At the broadest level it needs to: display forms and calendars to patients and staff (Presentation Tier), enforce rules such as "no double-booking" and "appointment must be at least 30 minutes" (Application Tier), and store and retrieve patients, doctors, time slots, and appointments (Data Tier). These three responsibilities map cleanly to three tiers:

Notice several important properties of this diagram:

• Strict neighbour rule: The Presentation Tier never talks directly to the Data Tier. All data access must pass through the Application Tier, which enforces business rules. In the clinic system, this prevents a browser from querying the database directly and bypassing the "no double-booking" rule.
• Independent scalability: If appointment bookings spike at 8am every morning, the organisation can add more Application Tier servers without touching the database or the frontend. Each tier scales independently.
• Technology substitution: The Data Tier can migrate from MySQL to PostgreSQL without changing the Presentation Tier. The Application Tier's Data Access Layer absorbs the change. This is why the Data Access Layer is sometimes called an abstraction boundary.

Common Architectural Styles

Three-tier is the dominant pattern for business systems, but it is not the only one. As an analyst you will encounter several styles; recognising them allows you to ask the right questions and document the right constraints.

• Monolithic: All layers packaged as a single deployable unit. Common in small systems and early-stage products. Simple to develop and deploy initially; becomes hard to scale or change independently as the system grows. An online store with all functionality in one PHP application is monolithic.
• Microservices: Each business capability (Orders, Inventory, Payments, Notifications) becomes an independent service with its own database, deployable separately. Enables teams to release independently and scale specific bottlenecks — but introduces network latency, distributed transaction complexity, and higher operational overhead. Logistics companies with high-volume real-time tracking often evolve towards microservices.
• Event-driven: Services communicate by publishing and consuming events via a message broker (such as Kafka or RabbitMQ). The Order Service publishes an OrderPlaced event; the Inventory Service and Notification Service each react independently. Decouples producers from consumers but complicates debugging and consistency guarantees.
• Serverless: Business logic runs in stateless functions (AWS Lambda, Azure Functions) invoked on demand. No servers to manage, automatic scaling, pay-per-invocation — but cold-start latency and vendor lock-in are real concerns for latency-sensitive transactions.

How the Analyst Uses Architectural Knowledge

You do not choose the architecture — but you influence it. Here is how your analysis work connects to each tier:

• Presentation Tier design is shaped by your use cases, wireframes, and user stories. If your use case specifies that a logistics dispatcher must update 50 shipment statuses simultaneously, the presentation tier needs a bulk-edit grid, not 50 separate forms — and that shapes whether a lightweight server-rendered page is sufficient or whether a single-page application (SPA) is needed.
• Application Tier design is shaped by your business rules, workflows, and integration requirements. Every business rule you documented in the SRS ("a patient cannot book an appointment within 2 hours of the current time") becomes a service method, a validation, or a policy object. Complex rules mean a richer Application Tier.
• Data Tier design flows directly from your ERD. Each entity in the ERD maps to a database table (or a collection in a NoSQL store). The relationships you identified (a patient has many appointments; an appointment belongs to exactly one doctor) dictate foreign keys, join tables, and indexes. The Data Tier is the ERD made operational.

Documenting the Architecture

Architectural decisions need to be documented — usually in the Design Specification Document (covered in Lesson 7). A minimal architectural description includes:

1. Architecture style: "Three-tier, client-server." State this explicitly. Do not assume everyone shares the same mental model.
2. Tier responsibilities: A one-paragraph description of what each tier handles and what it does not handle.
3. Communication protocols: "Presentation to Application via HTTPS REST API (JSON). Application to Data via SQLAlchemy ORM over a TCP connection to PostgreSQL on port 5432."
4. Technology stack per tier: "React 18 (Presentation), Node.js / Express (Application), PostgreSQL 16 (Data)."
5. Key architectural decisions and their rationale: "We chose a monolithic deployment for the initial release because the team has four developers, the user base is under 1,000, and a microservices split would add operational complexity the team cannot yet support."

This documentation level is sufficient for the analyst to trace requirements to design components in the traceability matrix, which in turn enables the test team to plan their test architecture accordingly. Every functional requirement should map to at least one component in the Application Tier, and every data requirement should map to at least one entity in the Data Tier. You will practice this mapping explicitly in Lesson 9 (Traceability from Requirements to Design).