Software Architecture

​Software Architecture

Software Architecture defines fundamental organization of a system and more simply defines a structured solution. It defines how components of a software system are assembled, their relationship and communication between them. It serves as a blueprint for software application and development basis for developer team.

Software architecture defines a list of things which results in making many things easier in the software development process.

• A software architecture defines structure of a system.

• A software architecture defines behavior of a system.

• A software architecture defines component relationship.

• A software architecture defines communication structure.

• A software architecture balances stakeholder’s needs.

• A software architecture influences team structure.

• A software architecture focuses on significant elements.

• A software architecture captures early design decisions.

​

Characteristics of Software Architecture

Architects separate architecture characteristics into broad categories depending upon operation, rarely appearing requirements, structure etc. Below some important characteristics which are commonly considered are explained.

Operational Architecture Characteristics

• Availability

• Performance

• Reliability

• Low fault tolerance

• Scalability

Structural Architecture Characteristics

• Configurability

• Extensibility

• Supportability

• Portability

• Maintainability

Cross-Cutting Architecture Characteristics

• Accessibility

• Security

• Usability

• Privacy

• Feasibility

​

SOLID principles of Software architecture

Each character of the word SOLID defines one principle of software architecture. This SOLID principle is followed to avoid product strategy mistakes. A software architecture must adhere to SOLID principle to avoid any architectural or developmental failure.

1. Single Responsibility: Each services should have a single objective.

2. Open-Closed Principle: Software modules should be independent and expandable.

3. Liskov Substitution Principle: Independent services should be able to communicate and substitute each other.

4. Interface Segregation Principle: Software should be divided into such microservices there should not be any redundancies.

5. Dependency Inversion Principle: Higher-levels modules should not be depending on low-lower-level modules and changes in higher level will not affect to lower level.