Software Architecture

What is Architecture?

Architecture (as an artefact)

The architecture of a system describes its overall static structure and dynamic behaviour. It models the system’s elements (which for IT systems are software, hardware, and its human users), the externally manifested properties of those elements, and the static and dynamic relationships among them.

Architecture (as a discipline) Architecture is an engineering discipline that studies methods of designing IT systems that provide a solution to a business problem. The solution must satisfy functional and non-functional requirements in a way that best balances competing stakeholders’ concerns and must take constraints into account.

What is Software Architecture?

The Software architecture of a system is a high-level description of the system's structure, its different components, and how those components communicate with each other to fulfill the System's requirements and constraints.

Some of the imperatives for producing architecture

• Solution blueprint that can be reviewed and validated
• Communication tool for stakeholders and teams (business, IT delivery and BAU – IT Operations), future reference for maintenance and change, developing neighbouring systems and integration
• Delivery Environments: Input into the delivery environments’ design and specification, tools and platforms of choice for solution delivery
• Delivery Planning: Starting point for developing the project plan (Traditional delivery), solution and feature backlog (Agile delivery), resource requirements and team structure
• Estimates: Starting point for cost estimation (labour, licences, platform costs, etc)
• Enable parallel development: by understanding how inter-component dependencies can and should be managed
• Foundation for commercial agreements (i.e. “This is what you get for the price we have agreed on”)
• Foundation for DOU and segregation of responsibilities between various parties – e.g. Client and Solution Provider, Solution Provider and Partner(s)/Subcontractor(s) (e.g. RACI matrices)

Architect

An Architect defines the structures of solutions and architectures to address client business problems. The Architect understands client needs and business constraints, works in levels of abstraction, applies industry knowledge, and leverages appropriate business elements and information technology to address those needs. The solutions are manifested as business, enterprise, or IT architectures and can include systems, applications, and process components. They may also involve the application and integration of a broad variety of products, technologies and services, and various architectural styles and domains.

What an Architect does

An Architect defines the structures of solutions… [based on] client needs and 
business constraints… [leveraging] appropriate business elements and 
information technology to address those needs. …Solutions [can address] 
business, enterprise, or IT architecture… domains

Architect works

• At the front
  • Listining to clients
  • Understanding business requirements
  • Negotiating feasible requirements and scope
  • Forming detailed definitions of solution structures
• At the back
  • During Construction
  • Serving as a customer advocate
  • Guiding the team

Difference between Design and Architecture

• Ensuring the system meets its specific requirements is called design.
  • Design describes something specific
• Ensuring it is designed in the right way is referred to as its architecture.
  • Architecture describes good ways of doing something

Non-Functional Requirement

Scalability

• An application should be able to serve millions of requests

Reliability & Availability

• An application should be available 24 hrs in 7 days

Maintability

• An appliction should be able to support several years

Efficiency

• An application should be able to perform well from performance point of view.

Request per second and acceptable latency

Concurrent Users	Reqeuest/Second	Latency(Expected)
2k	0.5k
20K	12k
100K	80K	<= 2 sec

Design Principles for System Architectures

How to start on designing an System Architecture

1. Write or bring the Functional Requirements
2. Write down the Non-Functional Requirements
3. Write the Design priciple which is going to be applied on architecture

• KISS
• YAGNI
• DRY
• SoC
• SOLID
• SOA
• Microservices

4. Designing the diagram of architecture following the defined principles

DRY - Don't Repeat Yourself

• You must try to maintain the behaviour of functionility of system in one place

KISS - Keep it Simple, Stupid

• Make your code simple
• avoid unnecesary complexity
• Follow Naming
• Separate the functionality

YAGNI - You Ain't Gonna Need IT

• Extream programing
• Do not create feature which is not necessary
• It focuses on complexity

Separation of Concerns (SoC)

• Elements in the software should be unique
• Separate responsibilities
• Limits to allocate responsibilities
• Low-coupling, High-cohesion

SOLID

• Single Responsibility Principle
  • Each of class,module, souuld be resonosibel for one functionality
  • The changes should be at one place
• Open-Close Principle
  • Change the code again and again, allow a new functionality on top of exsiting code
  • extend without impacting existing architecture
  • open for extention and close for modification
• Liskov Substitution Principle
  • System can be able to substitute easily, plugin can be added easily
• Interface Segregation Principle
  • Abstraction of function,
• Dependency Inversion Principle
  • Dependency injection whenever required
  • Event Driven Architecture to support this.

Service-Oriented Architecture

• Service components
• Communicates over the network
• Converged service infrastructure
• Enterprise applications

Architectural design patterns - Enterprise Service Bus(ESB)

• Integration between application
• Transformations of data models
• Middleware messaging components
• Service orchestration
• Increasead complexity and introduced bottlenecks
• Single point of failure, basically ESB can be a bottlenecks

Communication in SOA

• Enterprise Service Bus - ESB Systems
• Handles connectivity and messaging, performs routing
• Inter-service communication
• SOAP-based web services
• SOAP, WSDL, and XSD

Difference between SOA and Microservices

• Inter-service communication due to distributed services (both using)
• SOA, using Enterprise Serice Bus
• Microservices, using message borkers
• SOA using Global Data Model
• Microservices has polyglot Databases
• Size of services different
• SOA increased complexity and introduced bottleneck
• ESB middleware are expensive