Bachelors Program in Computer Applications
System Analysis and Design
•
Bachelor
System Architecture and Solution Design
Introduction
System analysis identifies what an organization needs; solution design determines how those needs will be realized through software, data, infrastructure, interfaces, people, and operational practices. Architecture provides the organizing structure for that design. It defines major components, their responsibilities, their relationships, the technologies that support them, and the qualities the system must exhibit.
Architecture is not merely a collection of servers or a technical diagram. It is a set of significant design decisions that constrain implementation and influence security, performance, maintainability, cost, reliability, scalability, and user experience. A well-designed architecture connects business objectives with implementable technical solutions.
This chapter examines the transformation from requirements to logical and physical designs. It evaluates common architectural styles—including client-server, layered, service-oriented, microservices, cloud, and API-based designs—and discusses integration, build-versus-buy decisions, and legacy modernization.
Learning Objectives
After studying this chapter, students should be able to:
Distinguish logical architecture from physical architecture.
Translate functional and non-functional requirements into architectural decisions.
Explain and compare client-server, layered, service-oriented, microservices, cloud, and API-centric architectures.
Design integration solutions using suitable interfaces and messaging approaches.
Evaluate build-versus-buy alternatives using structured criteria.
Assess architecture using quality attributes, risks, governance, and ethical considerations.
1. From Requirements to Architecture
Requirements provide the starting point for architecture. Functional requirements state what the system must do, such as registering students, processing payments, or generating reports. Non-functional requirements describe constraints and quality expectations, such as response time, availability, privacy, accessibility, auditability, and maintainability.
A useful transformation process is:
Classify requirements. Separate business goals, functional requirements, quality attributes, constraints, assumptions, and regulatory obligations.
Identify architectural drivers. Architectural drivers are requirements with substantial influence on structure. For example, strict privacy rules may require data segregation, while high transaction volume may require horizontal scaling.
Partition responsibilities. Group related functions into subsystems, services, modules, or layers.
Define interactions. Specify calls, events, data exchanges, protocols, and ownership boundaries.
Select an architectural style. Choose a style that supports the most important quality attributes and organizational capabilities.
Evaluate alternatives. Compare options against cost, risk, delivery time, security, performance, and strategic fit.
Document and validate. Use diagrams, scenarios, prototypes, and reviews to test the design.
Architectural Drivers
Architectural drivers commonly include:
Business drivers: strategic goals, time to market, operational efficiency, and competitive differentiation.
Functional drivers: essential business processes and information flows.
Quality drivers: security, availability, performance, scalability, usability, portability, and modifiability.
Compliance drivers: data protection, financial controls, accessibility, retention, and audit requirements.
A requirement such as “the system must be fast” is insufficiently precise. A better requirement might specify that 95% of catalogue searches should complete within two seconds under a stated workload. Precision makes architectural evaluation possible.
2. Logical and Physical Design
Logical Architecture
Logical architecture describes what the system contains and how responsibilities are organized, without committing to specific machines or deployment locations. Typical logical elements include:
user-interface components;
application services;
business rules;
data access components;
domain entities;
external interfaces; and
cross-cutting concerns such as authentication, logging, and validation.
Logical design helps analysts reason about cohesion, coupling, responsibility, and information flow. It should remain understandable to business stakeholders while being sufficiently precise for developers.
Physical Architecture
Physical architecture maps logical elements to concrete technology and infrastructure. It may specify:
web servers, application servers, databases, and storage;
networks, firewalls, load balancers, and identity providers;
containers, virtual machines, or serverless functions;
cloud regions and availability zones;
operating systems, programming platforms, and database products; and
backup, monitoring, deployment, and disaster-recovery arrangements.
Logical and physical designs should be traceable. Every major physical component should support a logical responsibility, and every critical logical responsibility should have an operational home.
Views and Documentation
A single diagram cannot communicate all architectural concerns. A useful documentation set may include:
Context view: system boundaries, users, and external systems.
Logical or container view: major applications, services, modules, and data stores.
Component view: internal responsibilities and interfaces.
Deployment view: nodes, networks, runtime environments, and connections.
Data view: entities, ownership, storage, retention, and movement.
Security view: trust boundaries, identities, privileges, controls, and audit points.
The 4+1 architectural view model is one recognized approach: logical, process, development, and physical views are related through scenarios. Other notations, including UML and the C4 model, may also be used. The important principle is not the notation itself but whether stakeholders can understand and validate the design.
Logical to physical architecture mapping
Figure: Logical to physical architecture mapping
Figure: Logical responsibilities mapped to physical deployment components.
3. Major Architectural Styles
Client-Server Architecture
In a client-server architecture, clients request services from one or more servers. A browser communicating with a web server and database is a common example. Clients may be thin, with most processing on the server, or thick, with substantial business logic locally.
Advantages include centralized data management, easier control of shared services, and broad support for networked applications. Risks include server bottlenecks, network dependence, and the possibility that a thick client becomes difficult to update.
Layered Architecture
Layered architecture organizes responsibilities into levels, commonly presentation, application or business logic, domain, and data access. A layer generally uses services of the layer below and provides services to the layer above.
Layering promotes separation of concerns, testability, and replaceability. However, excessive layering can create unnecessary indirection and performance overhead. Strict layering may also force an operation through several layers even when a simpler path would be appropriate.
Service-Oriented Architecture
Service-oriented architecture (SOA) organizes capabilities as relatively autonomous services with explicit contracts. Services are often coarse-grained and may be integrated through enterprise service buses, messaging infrastructure, or standardized interfaces.
SOA is useful where multiple applications need to reuse business capabilities and where integration governance is important. Its challenges include contract management, coordination, network failures, service versioning, and potentially complex middleware.
Microservices Architecture
Microservices decompose an application into small, independently deployable services, usually aligned with business capabilities. Each service should have a clear responsibility and should minimize dependence on the internal implementation of other services.
Potential benefits include independent deployment, team autonomy, selective scaling, and technological flexibility. Costs include distributed-system complexity, observability requirements, network failure, data consistency challenges, security across service boundaries, and operational overhead. Microservices are not automatically superior to a well-structured modular monolith.
A modular monolith keeps one deployable application while enforcing strong internal module boundaries. It can provide many benefits of modularity with less operational complexity and is often a sensible starting point for a new system.
Cloud Architecture
Cloud architecture uses on-demand computing, storage, networking, managed platforms, or software services. Common service models are:
Infrastructure as a Service (IaaS): virtual machines, networks, and storage;
Platform as a Service (PaaS): managed runtimes, databases, and deployment platforms; and
Software as a Service (SaaS): complete applications delivered by a provider.
Cloud adoption may improve elasticity, availability options, and speed of provisioning. It does not eliminate architecture responsibility. Organizations must still address identity, data location, resilience, cost control, provider dependency, configuration management, and exit strategies.
API-Centric Architecture
An application programming interface (API) is a defined way for software components to request capabilities or data. APIs may use REST over HTTP, GraphQL, gRPC, messaging protocols, or other mechanisms. A good API contract specifies operations, data formats, authentication, authorization, errors, rate limits, idempotency, and versioning.
Public APIs require especially careful governance because clients may be outside the organization. Compatibility rules, deprecation policies, documentation, monitoring, and abuse prevention are essential.
4. Integration and Communication Design
Integration connects applications, data stores, devices, and external partners. The first design decision is whether communication should be synchronous or asynchronous.
Synchronous communication requires the caller to wait for a response. It is appropriate when the response is needed immediately, such as validating a payment instrument. It creates temporal coupling: the receiving system must be available when called.
Asynchronous communication uses queues, event streams, or messaging. The sender can continue without an immediate response. This supports buffering and resilience but introduces eventual consistency, duplicate messages, ordering concerns, and more complex failure handling.
Important integration patterns include:
Request–response: one component requests an operation and receives a result.
Publish–subscribe: a producer publishes an event and multiple consumers receive it.
Message queue: messages wait until a consumer processes them.
Batch transfer: records are exchanged at scheduled intervals.
Shared database: systems read or write a common store; this is simple initially but creates strong coupling and ownership ambiguity.
Anti-corruption layer: an adapter protects a new model from the concepts and defects of a legacy system.
Integration design must address retries, timeouts, duplicate requests, partial failure, schema evolution, reconciliation, and monitoring. An operation that may be repeated safely is idempotent. For example, setting an account status to “active” is naturally more idempotent than charging a credit card.
5. Quality Attributes and Architecture Evaluation
Architecture should be evaluated with realistic scenarios rather than vague claims. A quality-attribute scenario normally identifies a stimulus, source, environment, response, and measurable response target.
For example: “When 5,000 users submit searches during registration, the system shall return 95% of results within two seconds and shall not lose committed registrations.” This scenario can guide load testing, database design, caching, and transaction decisions.
Key quality attributes include:
Performance: response time, throughput, and resource utilization.
Scalability: ability to handle increased load by adding resources or improving capacity.
Availability: ability to provide service when required.
Reliability: ability to perform consistently over time.
Security: protection of confidentiality, integrity, and availability.
Maintainability: ease of correcting, adapting, and extending the system.
Interoperability: ability to exchange and use information with other systems.
Usability and accessibility: effectiveness for diverse users, including users with disabilities.
Observability: ability to infer internal state from logs, metrics, traces, and events.
Quality attributes can conflict. Strong encryption may add processing cost; extreme availability may increase infrastructure expense; independent service deployment may reduce coordination but increase operational complexity. Architecture is therefore a process of informed trade-offs, not the maximization of every quality simultaneously.
6. Build, Buy, Subscribe, or Reuse
The build-versus-buy decision compares developing a capability internally with acquiring a commercial product, subscribing to SaaS, or reusing an existing organizational component. The decision should consider more than purchase price.
Criterion
Build
Buy or subscribe
Strategic differentiation
Strong control
Limited if capability is common
Initial delivery
Often slower
Often faster
Customization
High
Product-dependent
Internal skills
Required
Less implementation effort, but configuration skills remain necessary
Long-term cost
Maintenance is internal
Fees, upgrades, and vendor costs
Vendor dependence
Lower
Potentially significant
Compliance control
Direct control
Requires supplier assurance
A simple total-cost comparison over a selected period can be expressed as:
TCO = C₀ + ∑(Ot + Mt + It) − R
Here, TCO is total cost of ownership; C₀ is initial acquisition or development cost; Oₜ is operating cost in period t; Mₜ is maintenance cost in period t; Iₜ is integration and migration cost in period t; and R is residual value or avoided cost. The formula is useful for comparing alternatives over the same time horizon and should use consistent currency, scope, and assumptions. It does not capture every strategic or qualitative factor.
A disciplined decision includes a weighted scorecard, proof of concept, security and privacy due diligence, contract review, service-level analysis, data portability assessment, accessibility testing, and an exit plan. Buying a product does not transfer accountability for lawful processing, correct configuration, or business continuity.
7. Legacy Modernization
Legacy systems often contain valuable business rules and historically accumulated data. Replacement may be risky because documentation is incomplete, dependencies are hidden, and the system may support essential operations.
Common modernization strategies are:
Retain: continue operating the system when it remains suitable.
Retire: remove unused or redundant functionality.
Replace: implement a new system and migrate users and data.
Rehost: move the system to a new infrastructure environment with minimal code change.
Replatform: move to a new platform with limited modification.
Refactor: improve internal structure without changing externally visible behavior.
Rearchitect: change the system structure to achieve new qualities.
Rewrite: build a replacement, usually when the existing design is unsustainable.
Strangler approach: place new capabilities around the legacy system and gradually route functionality to the new solution.
Modernization should begin with dependency discovery, data assessment, risk analysis, and a clear transition architecture. Coexistence may require synchronization, reconciliation, and an authoritative-source policy. A “big bang” replacement can be simpler conceptually but concentrates risk; incremental migration reduces each change but prolongs coexistence complexity.
8. Security, Governance, and Ethical Responsibilities
Security must be designed rather than added at the end. Architecture should apply least privilege, separation of duties, secure defaults, defense in depth, encryption where appropriate, strong identity management, input validation, secure secrets handling, logging, patching, and tested recovery procedures.
Privacy architecture should minimize data collection, limit access, define retention and deletion, record processing purposes, and protect sensitive attributes. Data flows should identify trust boundaries and third parties. Decisions involving personal data should comply with applicable law and organizational policy.
Governance establishes who may approve architecture, change interfaces, select suppliers, accept risks, and operate production systems. Architecture review boards can provide consistency, but governance should not become a bureaucratic barrier to delivery. Lightweight decision records should explain important choices, alternatives, consequences, and assumptions.
Artificial intelligence may assist with code generation, architecture documentation, test creation, or anomaly detection. However, generated designs and code require human review for security, licensing, privacy, bias, reliability, and correctness. Confidential requirements and source code should not be submitted to tools without appropriate authorization.
9. Illustrative Case: Modernizing a College Registration System
Background
A fictional college uses a ten-year-old registration application. Students register through a browser, while the application accesses a central database and exchanges nightly files with the finance and identity systems.
Problem
During registration periods, response times become unacceptable. The finance interface cannot provide current payment status, duplicate student records exist, and changes require specialist knowledge of obsolete technology. The college wants mobile access, near-real-time payment confirmation, stronger auditability, and lower operational risk.
Analysis
The architectural drivers are peak scalability, data integrity, privacy, availability during registration, integration with finance and identity services, and gradual migration. A complete replacement would be expensive and risky because the old system contains poorly documented rules concerning prerequisites and enrollment limits.
Approach and Solution
The college chooses an incremental modernization strategy:
retain the legacy prerequisite engine initially;
place an anti-corruption layer between the legacy system and new applications;
create a modular registration API for student, course, and enrollment operations;
use synchronous identity validation and payment authorization where immediate responses are needed;
publish enrollment events asynchronously for notifications and reporting;
introduce a read-optimized registration portal without allowing uncontrolled direct database access;
centralize audit logging and monitoring;
migrate course catalogue and student-profile capabilities first; and
establish reconciliation reports between old and new data stores.
The first deployment uses a modular monolith rather than microservices. This limits operational complexity while preserving internal module boundaries. The system is deployed on managed cloud infrastructure with encrypted storage, role-based access, automated backups, and tested restoration procedures.
Outcome
The college reduces peak load on the legacy database and gains faster payment-status updates. Migration remains measurable because each capability has an owner, data-quality checks, and rollback criteria. Some duplication remains during transition, but reconciliation controls expose discrepancies.
Learning Points
The case demonstrates that architecture should respond to business and quality drivers, not fashion. Incremental modernization can protect valuable legacy rules. A modular monolith may be preferable to microservices when the organization lacks the operational maturity required for a distributed system. Integration contracts, data ownership, observability, and transition planning are as important as application code.
10. Best Practices for Solution Designers
Start with business outcomes and measurable quality scenarios.
Separate logical responsibilities from infrastructure decisions, while maintaining traceability between them.
Prefer clear boundaries, high cohesion, and manageable coupling.
Treat data ownership and lifecycle as architectural decisions.
Select technology after understanding constraints and capabilities.
Design failure handling, security, observability, and recovery from the beginning.
Use prototypes and architecture decision records to test uncertain assumptions.
Avoid unnecessary distribution; use microservices only when their benefits justify their costs.
Evaluate suppliers, APIs, and cloud services for portability, compliance, and exit risk.
Plan migration, coexistence, rollback, and decommissioning—not only the target state.
Involve users, operations staff, security specialists, developers, and business owners in reviews.
Revisit architecture as requirements, risks, and technology change.
Chapter Summary
System architecture transforms requirements into an organized solution structure. Logical architecture defines responsibilities and relationships, while physical architecture maps those responsibilities to technologies and infrastructure. Architectural styles—including client-server, layered, SOA, microservices, cloud, and API-centric designs—offer different benefits and costs. No style is universally best; selection depends on quality attributes, constraints, skills, and business priorities.
Integration design must distinguish synchronous and asynchronous communication and must address contracts, failures, retries, data ownership, and consistency. Build-versus-buy analysis should consider total cost, strategic value, control, compliance, vendor dependence, and exit options. Legacy modernization is best guided by dependency analysis and an explicit transition architecture. Security, privacy, governance, accessibility, and responsible use of AI are integral design responsibilities. Effective solution designers evaluate alternatives, document trade-offs, validate assumptions, and create systems that can evolve.
Key Terms
Architectural driver: A requirement or constraint that strongly influences system structure.
Logical architecture: A technology-independent organization of responsibilities and interactions.
Physical architecture: The deployment of logical elements onto concrete infrastructure and technologies.
Client-server: An arrangement in which clients request services from servers.
Layered architecture: A structure that separates responsibilities into levels with defined dependencies.
Service-oriented architecture: An architecture composed of autonomous, contract-based services.
Microservices: Small, independently deployable services aligned with business capabilities.
Modular monolith: One deployable application with strongly separated internal modules.
Cloud computing: On-demand access to shared computing resources and managed services.
API: A defined interface through which software components communicate.
Synchronous communication: Communication in which the caller waits for a response.
Asynchronous communication: Communication in which processing can continue without an immediate response.
Idempotency: The property that repeating an operation produces the same intended result.
Quality attribute: A measurable characteristic such as security, performance, or maintainability.
Total cost of ownership: The combined acquisition, operating, maintenance, integration, and related costs over a defined period.
Anti-corruption layer: An adapter that protects one model from another system’s concepts and interfaces.
Legacy modernization: The improvement, migration, replacement, or restructuring of an existing system.
Strangler approach: Incremental replacement of legacy capabilities by routing functionality to new components.
Architecture decision record: A concise record of an important decision, alternatives, and consequences.
Observability: The ability to understand system state through outputs such as logs, metrics, and traces.
Review Questions
Short Answer Questions
What is the difference between logical and physical architecture?
Identify two advantages and two risks of microservices architecture.
When is asynchronous communication appropriate?
What factors should be included in a build-versus-buy decision?
Define an anti-corruption layer.
Long Answer Questions
Explain how functional and non-functional requirements become architectural drivers.
Compare layered architecture, SOA, and microservices in terms of coupling, deployment, and operational complexity.
Explain the role of APIs, contracts, versioning, and observability in integration design.
Discuss the major strategies for legacy modernization and the risks of a big-bang replacement.
Describe how security, privacy, governance, and accessibility should influence solution architecture.
Analytical / Application Questions
A university expects registration traffic to increase tenfold for two hours each semester. Propose an architecture and justify your choices concerning scaling, data consistency, resilience, and cost.
An organization is considering a SaaS payroll product for a highly regulated environment. Develop a decision framework covering security, privacy, integration, total cost, vendor dependence, and exit planning.
A legacy inventory system has valuable business rules but an inaccessible database and unreliable batch interfaces. Design an incremental modernization roadmap, including transition architecture, integration patterns, data reconciliation, and rollback controls.
Multiple Choice Questions with Answers
Question 1
Which statement best distinguishes logical architecture from physical architecture?
A. Logical architecture specifies servers, while physical architecture specifies business rules.
B. Logical architecture organizes responsibilities, while physical architecture maps them to technologies and infrastructure.
C. Logical architecture is used only after deployment, while physical architecture is used before requirements analysis.
D. Logical architecture describes costs only, while physical architecture describes users only.
Correct Answer: B. Logical architecture organizes responsibilities, while physical architecture maps them to technologies and infrastructure.
Question 2
Which quality attribute scenario is the most measurable?
A. The system should be user-friendly.
B. The system should be modern.
C. The system should be fast.
D. At peak registration, 95% of searches should return within two seconds.
Correct Answer: D. At peak registration, 95% of searches should return within two seconds.
Question 3
What is a major operational challenge of microservices?
A. They cannot use APIs.
B. They eliminate the need for monitoring.
C. They introduce distributed-system and service-management complexity.
D. They require all business logic to be placed in one database.
Correct Answer: C. They introduce distributed-system and service-management complexity.
Question 4
Which communication style allows a sender to continue without waiting for an immediate response?
A. Asynchronous communication
B. Synchronous communication
C. Direct database coupling
D. Blocking request-response only
Correct Answer: A. Asynchronous communication
Question 5
What is the main purpose of an anti-corruption layer?
A. To remove all legacy data immediately
B. To prevent users from logging in
C. To protect a new model from the concepts and interfaces of another system
D. To replace all asynchronous messaging with batch processing
Correct Answer: C. To protect a new model from the concepts and interfaces of another system
Question 6
Which option is usually a benefit of a modular monolith compared with microservices?
A. It has no internal boundaries.
B. It provides modularity with less distributed operational complexity.
C. It requires every module to use a different programming language.
D. It cannot be deployed automatically.
Correct Answer: B. It provides modularity with less distributed operational complexity.
Question 7
In a total-cost-of-ownership comparison, which item is explicitly included as a cost component in this chapter’s formula?
A. Integration and migration cost
B. Employee satisfaction score only
C. Brand popularity
D. Number of programming languages used
Correct Answer: A. Integration and migration cost
Question 8
Which legacy modernization strategy gradually routes capabilities from an old system to new components?
A. Retain
B. Rehost
C. Strangler approach
D. Batch preservation
Correct Answer: C. Strangler approach
Question 9
Why is API versioning important?
A. It ensures that clients are not unexpectedly broken by interface changes.
B. It removes the need for authentication.
C. It guarantees zero network failures.
D. It prevents all data duplication.
Correct Answer: A. It ensures that clients are not unexpectedly broken by interface changes.
Question 10
Which statement about cloud computing is most accurate?
A. Cloud adoption eliminates the need for security design.
B. Cloud services remove all vendor-dependence risks.
C. Cloud architecture can provide on-demand resources but still requires governance, security, and cost control.
D. Cloud systems cannot support managed databases.
Correct Answer: C. Cloud architecture can provide on-demand resources but still requires governance, security, and cost control.