§ — — 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.
ProReviewer — locked
Drills, code labs, and full solutions.
ProReviewer — locked
Drills, code labs, and full solutions.
Done with this module? Track it — your progress shows on the subject list.
Up next
Lesson 4: Middleware and Integration Patterns→←Previous: Lesson 2: Enterprise Architecture and Architectural Views