Learning software architect (1)

In this post, we will learn about software architect.

This is a note for me while I’m reading the book “Head First Software Architecture” by Raju Gandhi, Mark Richards & Neal Ford.

TL;DR

1. Software architect basics ( current )
2. Know your capabilities
3. The two law of software architecture
4. Logical components

Okay, let’s go further the details

Software architect basics

1. Software architecture definition

Let’s say you are building a house. You need to have a plan, a blueprint, to build the house. The blueprint is the architecture of the house. It defines how the house will be built, what materials will be used, and how the different parts of the house will be connected. The structure thing like a roof, wall, and floor are the components of the house. The architecture defines how these components will be connected and how they will work together to form the house. Those thing are hard to change once the house is built.

The same thing with software. Software architecture is the blueprint of the software system. It defines how the software system will be built, what technologies will be used, and how the different parts of the software system will be connected. The components of the software system are the different parts of the software system, such as the database, the user interface, and the business logic. The architecture defines how these components will be connected and how they will work together to form the software system. The architecture is hard to change once the software system is built.

2. The dimensions of software architecture

There are four dimensions of software architecture:

1. Architecture characteristics capabilities key to the success of the system.

You cannot make architecture decisions without understanding the characteristics of the system you are building. The characteristics of the system are the requirements that the system must meet. For example, if you are building a system that needs to be highly available, you need to design an architecture that can meet that requirement. If you are building a system that needs to be scalable, you need to design an architecture that can meet that requirement.

Extensibility: the ability to add new features to the system without changing the existing features, the ease with which the system can be extended.

Agility: the ability to change the system quickly and easily, the ease with which the system can be changed.

Feasibility: the ability to build the system within the constraints of time, budget, and resources (developer skills), the ease with which the system can be built.

Interoperability: The system’s ability to interface and interact with other systems to complete a business request.

Fault tolerance: The system’s ability to keep its other parts functioning when fatal errors occur.

2. Architecture decisions decisions are structural guide for dev teams.

The choice that make about structural aspect of the system that have long-term or significant implications.

3. Logical components

The logical components of the system are the different parts of the system that perform different functions. For example, the database is a logical component of the system that stores data. The user interface is a logical component of the system that allows users to interact with the system. The business logic is a logical component of the system that implements the business rules of the system.

Logical components in a system are usually represented through a directory structure, package, or module.

The different between domain and system functionality: The domain is the problem we are trying to solve, the system functionality is how we solve the problem. In another word, the domain is the “what” and the system functionality is the “how”.

4. Architecture styles

Architecture styles defined the overall structure of the system and the shape.

It’s important to get it right from the first time because it’s hard to change once the system is built. It not easy to changing the monolithic architecture to microservices architecture.

Architecture and design are different things. Architecture is the high-level structure of the system, design is the detailed structure of the system.

Example: The company want to replace the outdated order processing system with a new custom-built one that better suits its specific needs. Customer can place order and view or cancel order once they have placed it. They can pay with credit card, a gift card, or both payment methods.

A design perspective

Build a Unified Modeling Language (UML) diagram to represent the system. Order can have one or two payment types can be associated with zero or more orders. CreditCard and GiftCard classes are inherited from PaymentMethod class.

An architecture perspective

Unlike design, architecture is about the structure of system things like the databases, services and how services communicate with each other and the user interface.

The spectrum between architecture and design your decision lies helps determine who should be responsible for ultimately making that decision.

There are some decisions that the development team should make (such as designing the classes to implement a certain feature), some decisions that the architect should make (such as deciding whether to use a microservices architecture or a monolithic architecture). And other should be made together (such as breaking apart services or putting them back together).

Strategic and tactical decisions

Strategic decisions are the high-level decisions that have long-term implications for the system. They are the decisions that the architect should make.

Tactical decisions are the low-level decisions that have short-term implications for the system. They are the decisions that the development team should make.

If this is a decision you will be living with for a long time, it’s a strategic decision. If it’s a decision you can change easily, it’s a tactical decision.

High and low level of effort

High level of effort decisions are the decisions that require a lot of time and effort to make. They are the decisions that the architect should make. (For example, deciding whether to use a microservices architecture or a monolithic architecture. Or changing the architect from monolithic to microservices.)

Low level of effort decisions are the decisions that require little time and effort to make. They are the decisions that the development team should make. (For example, deciding how to implement a certain feature, or change the color of a button.)

Significant and less-significant trade-offs

Significant trade-offs are the trade-offs that have a big impact on the system. They are the trade-offs that the architect should make. (For example, deciding whether to use a microservices architecture or a monolithic architecture.)

Less-significant trade-offs are the trade-offs that have a small impact on the system. They are the trade-offs that the development team should make. (For example, deciding whether to use a dropdown or a radio button, breaking class file apart(maintainability) or keeping it together (readability), more classes)

Summary

• Software architecture is less about appearance and more about structure.

• You need to use four dimensions to understand and describe software architecture: architecture characteristics, architecture decisions, logical components, and architecture styles.

• Architectural characteristics form the foundational aspects of software architecture. You must know which architectural characteristics are important to your system before you can make architecture decisions. So you can analyze the trade-offs between different architectural styles and make the right decisions.

• Architecture decisions serve as guideposts to help development team understand the constraints and conditions of the architecture.

• Logical components are the building blocks of the system. They are the different parts of the system that perform different functions.

• Architecture styles define the overall structure of the system and the shape of the system. They are the high-level decisions that have long-term implications for the system.

• It’s important to know the difference between architecture and design. Architecture is the high-level structure of the system, design is the detailed structure of the system. Because that helps determine who should be responsible for ultimately making that decision.