Review: Software Architecture & Design of Modern Large Scale Systems (1)

Annyeong!

 

I will note down some important points that I've learned from the Udemy course: Software Architecture & Design of Modern Large Scale Systems.

 

Introduction to Software Architecture

While there are many arguments about the definition of the software architectrue, here's the definition we will use throughout the course:

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

 

So the technologies or programming languages are not a part of the software architecture but a part of the implementation. We will intentionally delay the decisions about the implemention to the very end of the design. We're doing this intentionally because we want to choose the best components/services at the time when we're finishing the design. Changing the software architecture after the implementation will be very difficult.

 

Software architecture can have many different levels of abstraction:

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

We're focusing on the services when we're designing the software architecture. 

 

Software development cycle would look like below:

Design -> Implementation -> Testing -> Deployment -> Design -> ...

 

Our main topic — software architecture places between the design and implementation part, so that the developers can actually implement components based on our architecture.

Software architectrue is an output of the design, and an input of the implementation.

 

 

Introduction to System Design & Architectural Drivers

System design has high level of ambiguity since:

• The person providing the requirements (e.g. product manager) is often not an engineer and may even be not very technical
• Getting the requirements is part of the solution (that's why asking questions in system design interview is very important)

The client doesn't always know what they need. The client generally knows only what problem they need solved.

 

Let's take an example of designing a hitchhiking service — the high level requirement here is to "allow people to join drivers on a route, who are willing to take passengers for a fee". We'll need some questions to clarify:

• Real time vs advance reservation
• User experience — mobile / desktop / both
• Payment — direct payment or through system

But what happens if we don't get the requirements right? Can we simply build something and then fix it later when needed? — Large scale systems are big projects that cannot be easily changed. Many engineers will be involved in this changes, and many times will be wasted in result. There are some cases where we need to pay due to some hardware requirements and/or software licenses. Furthermore, these types of work will include contracts with financial obligations. Changing after with all these will be very risky.

 

Requirement Classification

There are three main types of requirements:

1. Feature of the system (functional requirements)
2. Quality attributes (non-functional requirements)
3. System constraints (limitations and boundaries)

Let's dive into each of the types.

 

Feature of the system (functional requirements)

This describes the system behavior — "what the system must do". It is easily tied to the objective of the system. This is usually called a black box since the service will not be finalized. Essentailly the users will input some actions and events to the system, and we do have some expected outputs from the operation of the system.

 

It is important to point out that the features or functional requirements simply dictate the functionality of our system, but they do not determine its architecture. Generally, any architecture can achieve any feature, which makes our job as a software architect so difficult.

 

Example of the features/functional requirements:

"When a rider logs into the service mobile app, the system must display a map with nearby drivers within 5 miles radius"

 

Quality attributes (non-functional requirements)

Quality attributes are the system properties that the system must have, such as scalability, availability, reliability, security, performance, and so on.

 

In contrast to the functinoal requirements, the quality attributes do dictate the software architecture of our system. In other way to look at this, the software architecture defines the quality attributes. Different architecture provides different quality attributes. 

 

System constraints (limitations and boundaries)

These are the limitations/constraints of its design/architecture/implementation.

Examples are:

• Time constraints (deadline of the implementation)
• Financial constraints (limited budget)
• Staffing constraints (small number of available engineers)

Those forces us to make certain tradeoffs and sacrifices our design. 

 

These three types of requirements we learned are also referred to architectural drivers, because they essentially drive our architectural decisions from the infinite possibilities to one solution that satisfies our client's needs.

 

That's it for today! See you later architects :)