Skip to main content

Survey of architecture styles - real world examples & trade-offs

1. Layered Architecture (Style) = Layered Pattern (Pattern)

Definition:

  • Shaw & Garlan: Defines a hierarchical structure where each layer provides services to the layer above it.
  • Bass et al.: Describes a structured approach where responsibilities are divided into layers to improve separation of concerns.

Real-World Examples:

  • Operating Systems – Windows, Linux (Kernel, Hardware Abstraction, User Interface)
  • Enterprise Software – 3-tier architecture (Presentation, Business Logic, Data)

Trade-offs:

  • Easy to maintain and extend
  • Supports modularization and separation of concerns
  • Can introduce performance bottlenecks due to inter-layer communication

2. Pipe-and-Filter (Style) = Pipe-and-Filter Pattern (Pattern)

Definition:

  • Shaw & Garlan: A system is divided into processing units (filters) that pass data through pipes.
  • Bass et al.: Describes a processing pipeline where data flows through sequential transformations.

Real-World Examples:

  • Unix Shell Pipelines – (cat file.txt | grep "error" | sort)
  • Compilers – Lexical Analysis → Syntax Analysis → Optimization → Code Generation
  • ETL (Extract, Transform, Load) Systems – Data processing in Apache NiFi

Trade-offs:

  • Supports parallel processing and reusability
  • Makes transformations modular and easy to test
  • High overhead due to data transfer between filters

3. Client-Server (Style) = Client-Server Pattern (Pattern)

Definition:

  • Shaw & Garlan: Defines a system where clients request services from a central server.
  • Bass et al.: A pattern where processing is distributed between a service provider (server) and consumers (clients).

Real-World Examples:

  • Web Applications – Browsers accessing web servers (e.g., Google, Facebook)
  • Databases – MySQL, PostgreSQL, Oracle (client apps interact with DB servers)
  • Email Systems – SMTP/POP3/IMAP protocols

Trade-offs:

  • Centralized control and security
  • Easier to scale compared to monolithic architectures
  • Single point of failure unless redundancy is added

4. Event-Based (Implicit Invocation) (Style) = Event-Bus Pattern (Pattern)

Definition:

  • Shaw & Garlan: Components communicate indirectly by broadcasting events.
  • Bass et al.: Uses an event bus to decouple event producers from event consumers.

Real-World Examples:

  • IoT Systems – Smart home devices using MQTT, Kafka, or RabbitMQ
  • GUI Applications – Button clicks triggering events in React, Angular
  • Stock Market Trading Systems – Event-driven architecture for handling transactions

Trade-offs:

  • High scalability and decoupling of components
  • Supports real-time event processing
  • Difficult to debug due to lack of direct control flow

5. Repository (Blackboard) (Style) = Blackboard Pattern (Pattern)

Definition:

  • Shaw & Garlan: A centralized data store (repository) that multiple components interact with.
  • Bass et al.: The Blackboard pattern defines a shared knowledge base where independent processes read/write.

Real-World Examples:

  • Integrated Development Environments (IDEs) – Eclipse, Visual Studio Code (central repository for plugins)
  • AI & Machine Learning Systems – Blackboard systems for inference engines
  • Database-Driven Applications – CRM, ERP systems (centralized database for business logic)

Trade-offs:

  • Facilitates data consistency and sharing
  • Ideal for AI/ML reasoning systems
  • Can become a performance bottleneck if poorly managed

6. Interpreter (Virtual Machine) (Style) = Microkernel Pattern (Pattern)

Definition:

  • Shaw & Garlan: A system that interprets and executes commands dynamically.
  • Bass et al.: Describes a core (microkernel) with additional extensible components.

Real-World Examples:

  • Virtual Machines – Java Virtual Machine (JVM), .NET CLR
  • Web Browsers – JavaScript engine (V8 in Chrome, SpiderMonkey in Firefox)
  • Modular Software – Eclipse plug-ins, Adobe Photoshop extensions

Trade-offs:

  • High flexibility and extendability
  • Reduces core complexity by offloading features to external modules
  • Performance overhead due to interpretation/execution layer

Comments

Popular posts from this blog

Example 1: ArchiMate relationship in PlantUML code to demonstrate 15 relationship types

 Following section presents 15 types of relationships in ArchiMate and PlantUML to generate the diagram. Since this code is generated by GEN-AI it may require precision on aspects other than PlantUML syntax: Diagram Plant UML Code:  @startuml '!includeurl https://raw.githubusercontent.com/plantuml-stdlib/Archimate-PlantUML/master/Archimate.puml ' Another way of including Archimate Library (above is commented for following) !include <archimate/Archimate> !theme archimate-standard from https://raw.githubusercontent.com/plantuml-stdlib/Archimate-PlantUML/master/themes title ArchiMate Relationships Overview <style> element{     HorizontalAlignment: left;     MinimumWidth : 180;     Padding: 25; } </style> left to right direction rectangle Other {     Business_Role(Role_SeniorManager, "Senior Manager")     Business_Role(Role_Manager, "Manager") } rectangle Dynamic {     Business_Event(Event_CustomerReques...

Mastering Trade-Off Analysis in System Architecture: A Strategic Guide for Architects

 In system architecture and design, balancing conflicting system qualities is both an art and a science. Trade-off analysis is a strategic evaluation process that enables architects to make informed decisions that align with business goals and technical constraints. By prioritizing essential system attributes while acknowledging inevitable compromises, architects can craft resilient and efficient solutions. This enhanced guide provides actionable insights and recommendations for architects aiming to master trade-off analysis for impactful architectural decisions. 1. Understanding Trade-Off Analysis Trade-off analysis involves identifying and evaluating the conflicting requirements and design decisions within a system. Architects must balance critical aspects like performance, scalability, cost, security, and maintainability. Since no system can be optimized for every quality simultaneously, prioritization based on project goals is essential. Actionable Insights: Define key quality ...

Virtual environments in python

 Creating virtual environments is essential for isolating dependencies and ensuring consistency across different projects. Here are the main methods and tools available, along with their pros, cons, and recommendations : 1. venv (Built-in Python Virtual Environment) Overview: venv is a lightweight virtual environment module included in Python (since Python 3.3). It allows you to create isolated environments without additional dependencies. How to Use: python -m venv myenv source myenv/bin/activate # On macOS/Linux myenv\Scripts\activate # On Windows Pros: ✅ Built-in – No need to install anything extra. ✅ Lightweight – Minimal overhead compared to other tools. ✅ Works across all platforms . ✅ Good for simple projects . Cons: ❌ No dependency management – You still need pip and requirements.txt . ❌ Not as feature-rich as other tools . ❌ No package isolation per project directory (requires manual activation). Recommendation: Use venv if you need a simple, lightweight solut...