What’s Software Architecture?

This is my personal summary from Software Architecture & Design of Modern Large Scale Systems course. The author is Michael Pogrebinsky.

Software architecture describes the system’s structure, focusing on how components interact. It doesn’t include specific languages or frameworks. The choice of language and framework is determined during implementation.

Each component can also be a complex system that has another software architecture diagram to describe. It also means that this definition may be recursive when needed.

Components come together to do what the requirements require and to not do what is listed on the constraint.

Software architecture can be divided into different levels from low to high:

• Classes/structs
• Modules/packages/libraries
• Services (processes/groups of processes)

Software development cycle can be simply divided into 4 steps:

• Design
• Implementation
• Testing
• Deployment

Software architecture is the output of the design phase and the input of the implementation phase.

We cannot prove software architecture is whether or not correct or optimal, but we can guarantee to follow methodical design process, architectural patterns, best practices.

---

The challenge we may face while working on software architecture is high level of ambiguity

There are 2 potential ambiguities…

1. Who provides the requirements is often not an engineer and may not be very technical.
2. Getting the specifications is part of the solution.
   • Clients normally don’t know what they need
   • Clients generally know what the problems they want to solve.

For example, someone asks to build a taxi service then to clarifying the questions, you may ask…

1. It’s real time or advance reservation?
2. It’s for mobile, desktop or both?
3. It’s going to pay through the system or cash to the driver directly?
4. …etc.

Therefore, it’s important for us to ask the questions ahead of time before starting doing it, so we will know that we are really going to build.

There are 2 potential ambiguities…

1. Who provides the requirements is often not an engineer and may not be very technical.
2. Getting the specifications is part of the solution.
   • Clients normally don’t know what they need
   • Clients generally know what the problems they want to solve.

For example, someone asks to build a taxi service then to clarifying the questions, you may ask…

1. It’s real time or advance reservation?
2. It’s for mobile, desktop or both?
3. It’s going to pay through the system or cash to the driver directly?
4. …etc.

Therefore, it’s important for us to ask the questions ahead of time before starting doing it, so we will know that we are really going to build.

However, by asking client, it is a good enough way because clients may not remember all details. Therefore, a better approcah is gathering requirement by:

• Use cases – Situation/scenario in which our system is used
• User flows – A step by step/graphical representation (ex: UML diagram) of each use case

---

Type of Requirements:

• Features of the system
  • Functional requiremetns – what system must do? what’s objective?
    • This requirements can be easily divided into User Actions/Events, Result/Outcome. For example, When a rider logs into the service mobile app, the system must display a map with nearby drivers within 5 miles radius.
      • User Actions: a rider logs into the service mobile app
      • Result: display a map with nearby drivers within 5 miles radius
• Quality attributes
  • Non-Functional requirements – what system must have
    • Scalability
    • Availability – ex: must be avilalbe to user a request at least 99.9% of time.
    • Reliability
    • Performance – ex: must response in 100ms.
    • Security
    • …etc
  • Software architecture defines the system quality attributes; in other words, quality attributes have direct correlation with the architecture design
  • It describes the qualities of functional requirements and the ovoerall properties of the system
  • It must be measurable and testable
  • There is no any existing architecture that can fit all quality attributes – MUST trade off
    • ex: you want to a login feature to be able to login asap, but also want it to be secured enough. To make it secured, it may need some complex implementations that will slow down the speed.
  • Feasibility is also an important consideration since the client may ask something that
    • Technically impossible – ex: 100% availability
    • Prohibitively expensicve to implement
• System constraints
  • Limitation and boundaries
    • Time constraints – deadline
    • Financial constraints – budget
    • Staffing constraints – human resource
  • A system constraint is essentially a decision that was already either fully or partially make for us, restricting our degree of freedom.
  • Three type of constraints
    • Technical constraints – being locked to a particular cloud vendor, have to use a particular programming language/database, support certain platforms, browsers, or OS.
    • Business constraints – limited budget, restrict deadline, work/integrate with third-party providers.
    • Regulatory/Legal constraints – HIPAA (in USA), GDPR (in EU)
  • We should not take any given constraint lightly
    • Real constraints – regulation may not have room to negotiate
    • Self-imposed constraints – limited budget + limited deadline, locked to particular vendor.
  • Loosely coupled architecture
    • We need to make sure that our system is not tightly coupled to a certain technology or third party APIs
    • Usage of different technology/serivce in future should need minimal changes
    • Different parts of the system can be decoupled to be easily replaced or updated independently

These requirements essentially drive the architecture decisions, so it can be also refer as archtiecture drivers.

Systems are frequently redesigned NOT because of functional requirements, but because of the system is not:

• Fast enough
• Hard to maintain
• able to scale
• secure enough
• …etc