Understanding IT Solution Architecture

Introduction

Architecture in software engineering refers to the fundamental structures of a software system, encompassing the components or modules of the application, the relationships between these components, and the properties of both the components and the relationships. It is a high-level blueprint that provides a comprehensive understanding of how a software system is organized and how it will function.

Key aspects of software architecture

Components: Components are individual parts of the software system, such as modules, classes, or functions, that perform specific tasks or groups of tasks.
Connectors: Connectors are the mechanisms that allow components to communicate with each other, such as APIs, data streams, message queues, or remote procedure calls.
Configuration: Configuration describes the arrangement and interaction of components and connectors in the system.
Constraints: Constraints are the technical and business rules that affect the architecture, such as performance requirements, security standards, or compliance regulations.
Rationale: Rationale is the reasoning behind the architectural decisions, including trade-offs and choices made to meet the system's objectives.

Software Architecture Principles

SOLID Principles

The SOLID principles are a set of five design principles intended to make software designs more understandable, flexible, and maintainable. These principles encourage software developers to create more scalable, robust, and easier-to-manage applications.

Here's a brief overview of each principle:

Single Responsibility Principle (SRP)
1. A class should be responsible for only one operation.
Open/Closed Principle (OCP)
1. Classes/modules/functions should be open for extension but closed for modification.
2. By implementing this, existing code will not be changed, and because of this errors reduced.
Liskov Substitution Principle (LSP)
1. Subclasses should be able to process the functionalities independently and produce results.
Interface Segregation Principle (ISP)
1. A very large interface design is not allowed. It should be splitting large interfaces into specific smaller tasks.
Dependency Inversion Principle (DIP)
1. Parent classes should not depend on child classes directly.
2. Proper interfaces should be created, which is known as abstraction, and dependency should be handled based on these interfaces.

Important Characteristics of Software Architecture

Performance: Performance can be measured depending on various factors like response time, throughput, and execution time for specific requests.
Availability: System’s uptime means the system is operational and accessible.
Maintainability: It improves the code readability and the use of standard patterns and practices.
Testability: The system should allow the team to test all the components of the application independently and in minimum time.
Modularity: The system should be divided into multiple modules so that each module is responsible for performing one specific task.

Steps to Design Software Architecture

Clear requirements understanding
System designing visualization
Identify key scenarios
Identify key issues
Create Candidate Solutions

Implementation of system designing visualization by UML

Unified Modelling Language (UML) is a general-purpose modeling language. The main aim of UML is to define a standard way to visualize the way a system has been designed. It is quite like blueprints used in other fields of engineering. UML is not a programming language; it is rather a visual language.

Some UML diagrams to design the system

The Component Diagram
- It describes the detailed components.
- All the interfaces should be properly designed in the diagram
- The relation between the interfaces/modules and nested interfaces should be clearly shown.
The Class Diagram
- In the class diagram, all the classes and their methods, properties, and fields will be shown.
- The diagram shows the relationship between the objects.
The Sequence Diagram
- The sequence diagram describes the order/sequence that followed when creating the object of the class and calling the respective methods.
- When calling the methods, it describes the response and exact data type.
The State Diagram
- State diagram describes about the activities that object follows and it's current state.
- The internal activities during execution are also mentioned.
The Activity Diagram
- It describes all the activities that are performed in a single process.
- During the activity, it mentioned the nested and concurrent activities also.
The Layer Diagram
- The layer diagram describes the layers that our application can be divided into.
- The references between the layers are also properly designed.
The Use Case Diagram
- Use case diagram details about the exact use cases and who are the actors for the same.
- It shows the actor's relation to the respective use cases.

Use of architecture patterns in system designing

Various architectural patterns can be used to better design the system. Some of them are listed below

Layered Architecture Pattern

Layered Architecture pattern is divided into 3 patterns

Client/Server pattern
- This pattern describes the client and server for the system.
- All the communication protocols and network standards will be described between client and server.
- It describes the number of clients for one particular server and the type of requests served.
Layered pattern
- This pattern describes how the system should be divided into many layers for better management.
- It describes the communication between the layers.
- All the dependencies should show in a way that each layer should be properly isolated, and it will be easy to scale out in the future.
N-Tier Pattern
- This pattern describes the physical separation between layers.
- It describes the layers that will be deployed across different servers and the communication protocol between them.
- It also describes the detailed security and maintainability between the servers.

Structural architecture pattern

It is divided into 2 patterns.

Component-based pattern
- This pattern describes all the components that the system should be divided into and can be reused.
- It describes the related components that can be grouped as a module so that deployment can be done easily.
Object-Oriented pattern
- It describes all the principles that should be followed as object-oriented principles.
- It details inheritance, polymorphism, encapsulation, and abstraction for objects.

Presentation Architecture Patterns

It is divided into 2 patterns.

MVC Pattern
- It details the model-view-controller pattern so that the presentation layer will be properly designed.
- It shows how the views generate outputs that can be visible to the end user, the model handles data/validations, and controllers handle the communication between views and the model.
MVVM pattern
- It represents the view-model concepts that can be created by using multiple models.
- Views can be bound to one view model instead of multiple models.

Service Architecture Patterns

It is divided into 3 patterns

Service-oriented pattern
- It describes, instead of concrete classes, how to design the services so that irrespective of the language, objects can communicate with each other.
- The communication protocols like SOAP/XML/Binary etc.. should be properly mentioned.
Microservice pattern
- It describes more detailed modular services.
- Services should have their own protocol, contract, and service.
- Each service can independently communicate with each other.
Message Bus Pattern
- In this pattern, communication between the services should be achieved through a message bus so that messages can be used for communication.
- The message bus can be shared or dedicated and handles the message failover for each service.

Hybrid Architecture Patterns

It is divided into 3 patterns

Components in layers
- It is a combination of layers and component patterns. Inside each layer, the system is again divided into components.
- The communication between layers and components should be described.
MVC in the presentation layer
- It is the model-view-controller pattern that presentation layers are divided into.
Objects in components
- It describes the components that should contain objects for extensibility.

How to choose the right pattern?

Determine the current and future load. Accordingly, scaling can be decided.
Choose a pattern that promotes modularity and is loosely coupled.
Patterns can be considered based on the domain and context in which the application will operate.
Understand the business goals, end-user needs, scalability demand, performance expectations, and security concerns.

Conclusion

Software architecture provides a way to find out the problems involved with the old implementation. Software architecture is the best way to remove the technical debt involved in processing unstructured data for a complex project. Solution Architecture must have a standard, reliable approach to business engagements, and it must work collaboratively with other architecture roles, business analysis, and service management to ensure continually along the solution delivery journey.