§ 03 — Systems Integration and Architecture
Architecture style is the general way a system is organized. Different styles solve different problems, and no single style is always best.
A layered architecture separates presentation, business logic, and data access. It is common in academic examples because it is easy to understand and maintain. A client-server architecture separates service providers from service consumers. A service-oriented or microservice-based architecture splits functionality into services that communicate through interfaces. An event-driven architecture reacts to events such as "payment received" or "order shipped."
Here is a practical comparison:
| Style | Best for | Watch out for |
|---|---|---|
| Layered | Clear separation, maintainability | Can become rigid or slow if too many layers |
| Client-server | Centralized services | Server bottlenecks or a single point of failure |
| SOA / Services | Reuse across many systems | Governance and versioning complexity |
| Microservices | Fast team autonomy, independent deployment | Operational complexity, monitoring difficulty |
| Event-driven | Real-time reactions, loose coupling | Harder debugging and eventual consistency issues |
In a BSIT exam, you are often not asked to define styles only. You are asked to select an appropriate style for a scenario. That selection should always depend on requirements.
A system should not only "work." It should also work in a way that fits organizational expectations. These expectations are called quality attributes or non-functional requirements.
Common attributes in systems integration include:
These attributes often compete with one another. A very secure system may add more steps and slow access. A highly distributed microservice design may improve scalability but make monitoring harder. A simple direct connection may be fast to build but difficult to maintain later.
This is why architecture involves trade-offs. Good designers do not claim to maximize everything. They decide which qualities matter most for the given case.
For example, an online payment integration may prioritize security and reliability first. A data dashboard may prioritize timeliness and usability. A university enrollment system during peak registration may prioritize availability and scalability.
Pro2 reviewers locked
Part of this subject's paid reviewers. Not included in this printout.
Done with this module? Track it — your progress shows on the subject list.
Studying with blockmates? Send them this lesson.
Up next
Lesson 4: Middleware and Integration Patterns→←Previous: Lesson 2: Enterprise Architecture and Architectural Views