Introduction

Software architecture is a complex and challenging topic that requires a deep understanding of the system's structures and elements. In this article, we will only scratch the surface of software architecture and focus on showing the system's structures and design with non-functional attributes rather than its functionality, as we obtain it in the requirements specification phase using diagrams.

When understanding Software Architecture you need to consider five things, Structures, Patterns, Tactics, levels, and Domains

Architecture Domains

Business:

Describes how the enterprise is organizationally structured and what functional capabilities are necessary to deliver the business vision. Business architecture addresses the questions WHAT and WHO:

WHAT is the organization’s business vision, strategy, and objectives that guide the creation of business services or capabilities?

WHO is executing defined business services or capabilities?

Application:

Describes the individual applications, their interactions, and their relationships to the core business processes of the organization. Application architecture addresses the question HOW:

HOW are previously defined as business services or capabilities implemented?

Data:

Describes the structure of an organization’s logical and physical data assets and data management resources. Knowledge about your customers from data analytics lets you improve and continuously evolving business processes.

Technology:

Describes the software and hardware needed to implement the business, data, and application services.

Domain Architects

Enterprise Architect
Solutions Architect
Business Architect
Application Architect
Chief Architect
Data & Information Architect
Integration Architect
Security Architect
Technology Architect
Cloud Architect

source: Visual Paradigm

Software Design Levels

1. Architectural Design

The architectural design is the highest abstract version of the system. It identifies the software as a system with many components interacting with each other. At this level, the designers get the idea of proposed solution domain.

The overall system architecture is defined here, so you can look at it as Allocation Structure design.

2. High-level Design

The high-level design is a lower abstraction level from architectural design, it breaks the ‘single entity-multiple component’ concept of architectural design into less-abstracted view of sub-systems and modules and depicts their interaction with each other.

High-level design focuses on how the system along with all of its components can be implemented in forms of modules.

So, dividing the -overall system- into sub-systems and into classes should be made here, so you can look at it as Module Structure design.

3. Detailed Design

Detailed design deals with the implementation part of what is seen as a system and its sub-systems in the previous two designs.

It is more detailed towards modules and their implementations.

So, dividing the -sub-systems- and -classes- into data and functions communications should be made here, so you can look at it as C&C Structure design.

There are two parts of this level, the first is non-functional based design, and the second is functional based design.

1. Non-functional based design

This type of design in Detailed Design level will use C&C structures, views, and architectural patterns, and it focuses on the communications between components (modules). However, it does not focus on functionality nor the internal design.

2. Functional based design

This type of design in Detailed Design level is often neglected espcially as architects (that focus mostly on non-functional attributes). However, it is good to mention this type, also it is better to design it as an architect. So, you will start getting into internal design of (modules) such as classes and functions such as writing Pseudocode or Flow chart diagrams to show the implementation code flow.

source: tutorialspoint

Architectural Structures or Views

Software architecture is a set of structures that represent the system's components and their relationships, Structures are referred to the set of elements itself and Views are the representation of the structures, so it is documented, but the two words are similar in terms of categorizing. There are three main ways to look at a system or an architecture, known as structures or views:

Module View: The module view represents the system's functional decomposition into modules and their dependencies. It shows how the system's components use each other, or how they are divided into layers, classes, data models, or decomposed components. The module view can be represented using different types of structures:

Uses Structure: Represents how the system's components use each other.
Layers Structure: Divides the system into layers, each responsible for a specific set of functionalities.
Class Structure: Represents the system's classes and their relationships.
Data Model Structure: Represents the system's entities, attributes, and relationships.
Decomposition Structure: Represents the system as a collection of decomposed components.

C&C View: The C&C (Component&Connector) or (Control&Communication) view defines the system's control and communication flows. It shows how the system's components communicate with each other, or how they handle concurrent requests. This view can be represented using different types of structures such as service structure, concurrency structure, event-driven structure, etc. The C&C view can be represented using different types of structures:

Service Structure: Represents the system as a collection of services that communicate with each other.
Concurrency Structure: Represents how the system handles concurrent requests.

Allocation View: The allocation view defines the system's physical distribution onto hardware components. It shows how the system's deployment components are distributed across different nodes, or how the system's implementation components are related to each other. This view can be represented using different types of structures such as deployment structure, implementation structure, work assignment structure, etc. The Allocation view can be represented using different types of structures:

Deployment Structure: Represents the system's deployment components and their distribution across different nodes.
Implementation Structure: Represents the system's implementation components and their relationships.
Work Assignment Structure: Represents the system's work assignment components and their distribution across different nodes.

Each of these views can be represented using different types of diagrams, such as class diagrams (class structure), EER diagrams (data model structure), and deployment diagrams (deployment structure).

Architectural Patterns

Architectural patterns are a set of tactics that provide proven solutions to recurring design problems in software architecture.

These patterns are reusable, abstract solutions that can be applied to different systems to improve their quality attributes such as performance, availability, modifiability, security, and more.

So, instead of just starting from scratch and try to solve problems with tactics, just use a patterns that solve the quality attributes you need, we will talk about tactics more later.

1. Module Structure Patterns

The module structure defines the system's functional decomposition into modules and their dependencies. Some Patterns Are:

Layered Pattern: Uses the uses and layers structures. It is strong in modifiability and reusability but weak in performance and scalability.
Data Model Pattern: Uses the data model structure. It is strong in data integrity and consistency but weak in performance.
Component-Based Pattern: Uses the decomposition structure. It is strong in modifiability and reusability but weak in performance and scalability.

2. C&C Structure Patterns

The C&C (Control and Communication) view defines the system's control and communication flows. Some Patterns Are::

Publish-Subscribe Pattern: Uses the event-driven structure. It is strong in scalability but weak in performance and security.
Peer-to-Peer Pattern: Uses the decentralized structure. It is strong in scalability but weak in security and reliability.
Service-Oriented Architecture (SOA) Pattern: Uses the service structure. It is strong in modifiability, reusability, and scalability but weak in performance and security.
Client-Server Pattern: Uses the two-tier structure. It is strong in scalability and security but weak in performance and modifiability.
Shared-Data (Repository Model) Pattern: Uses the shared data structure. It is strong in simplicity and modifiability but weak in scalability and performance.
Model-View-Controller (MVC) Pattern: Uses the separation of concerns structure. It is strong in modifiability, reusability, and testability but weak in performance and simplicity.
Pipe-and-Filter Pattern: Uses the data transformation structure. It is strong in modifiability and flexibility but weak in performance and scalability.
Broker Pattern: Uses the distributed communication structure. It is strong in scalability and modifiability but weak in performance and simplicity.

3. Allocation Structure Patterns

The allocation view defines the system's physical distribution onto hardware components. Some Patterns Are:

Map-Reduce Pattern: Uses the work assignment and other allocation structures. It is strong in scalability and performance but weak in simplicity and modifiability.
Multi-Tier Pattern: Uses the deployment and other allocation structures. It is strong in scalability and security but weak in simplicity and performance.
Micro-Services Pattern: Uses the deployment and other allocation structures. It is widely used nowadays, it is strong in scalability and performance but weak in security.

Tactics

Remember that every pattern has got strengths and weaknesses in some quality attributes?

Let's take Multi-Tier Pattern as an example, when using it we do not need to be so much concerned about security so much, because the pattern itself has it as a strength. However, we want to use tactics to overcome performance issues.

Architects can also use tactics to achieve specific quality attributes. Tactics are design decisions that address specific quality attributes, such as performance, availability, reusability, modifiability, security, and so on.

Some common tactics that can be used to achieve different quality attributes include:

Performance:

Caching: Stores frequently accessed data in memory to reduce response time.
Load balancing: Distributes workloads evenly across multiple nodes to improve response time.
Parallelism: Divides workloads across multiple processors or nodes to improve response time.

Availability:

Redundancy: Provides backup resources to ensure system availability in the event of a failure.
Replication: Duplicatesdata or components across multiple nodes to ensure system availability in the event of a failure.
Fault tolerance: Uses mechanisms to detect and recover from system failures to ensure system availability.

Availability Tactics

Reusability:

Modularity: Divides the system into smaller, independent modules that can be reused across different parts of the system.
Encapsulation: Hides the implementation details of a module and provides a well-defined interface for other modules to use.

Modifiability:

Loose coupling: Reduces the dependencies between components to make it easier to make changes to the system.
Separation of concerns: Divides the system into distinct components, each responsible for a specific set of functionalities.

Security:

Encryption: Protects sensitive data by encoding it to prevent unauthorized access.
Access control: Restricts access to sensitive data or components to authorized users only.
Auditing: Monitors system activities to detect and prevent security breaches.

Security Tactics

Conclusion

Architects often use ASR (Attribute-Scenario-Response) utility trees to prioritize tactics for each quality attribute. ASR utility trees help architects identify the most critical quality attributes and the tactics that can achieve them.

Also, they use Scenarios.

An example of an availability general scenario is when a user initiates a request for a service or data from the system, and the system must respond within an acceptable time frame and provide the requested service or data, with response time and uptime measured and monitored to ensure the required availability level is met.

They can extract stimulus, source of stimulus, artifact, environment, response, and response measure from the general scenario and know the appropriate tactic used here or want to be used here.

Lastly, a general rule of thumb in patterns' attributes, whenever the system is seperated with layers, it will increase modifiability but decrease performance and security. Also,

Real-World Skills and Diving Deeper

Jobs:

Software Architect: Responsible for designing the system's architecture and ensuring that it meets the required quality attributes.

What's Next?

Next activity is the Implementation, where we start making the design and architecture something that works.

Software Development (Design) in The Process

Table of contents