The first dimension: Architectural Characteristics

Also know as "Nonfunctional requirements" or "system quality attribute". Those are things like performance, scalability , reliability and availability. it is the foundation of architecture in a software system. Without them, you can't make architectural discissions or analyze important trade-offs.

Let's say you need to decide what kind of database to use for your new system. should it be relational, a simple key/value , or a complex graph database? the answer will be based on what architectural characteristics are critical to you. If you need high-speed search (Performance), you might choose graph database. whereas a traditional relational database might be better if you need to preserve data relationships (Data Integrity).

Common Architectural Characteristics:

• Performance: The amount of time it takes for the system to process business request
• Availability: The amount of uptime of a system; usually measured in "nines" (so 99.9% would be 3 "nines")
• Scalability: The system's ability to maintain a consistent response time and error rate as the number of users or request increases.
• Extensibility: The ease with which system can be enhanced to support additional features and functionality
• Agility: The system's ability to respond quickly to change.
• 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.
• Feasibility: Taking into account time frames, budgets, and developer skills when making architectural choices.

The 2nd dimension: Architectural Decisions

Those are the choices you make about structural aspects of the system that have long-term or significant implications. As constraints, they'll guide your development team in planning and building the system.

You might decide that your system's user interface should not communicate directly with the database, but instead must go through the underlying services to retrieve and update data. This architectural decision places a particular constraint on the development of the user interface, and also guides the development team about how other components should access and update data in the database.

In the MVC (Model–View–Controller) Architecture. we already have decided that the "Model" which is a core architectural components of the architecture will be responsible for retrieving the data from the database. which represent a clear, straightforward example of having an architecture decision.

The 3rd dimension: Logical Components

Logical components are the building blocks of a system, much  in the same way rooms are the building blocks of your home. They usually performs some sort of function, such as processing the payment for an order, managing item in inventory, or tracking orders.

For example, the directory `app/order/payment` identifies a logical component named Payment Processing. the source code that allows users to pay for an order is stored in this directory. A logical component should always have a well-defined role and responsibility in the system. In other words, a clear definition of what it does.

The 4th dimension: Architectural styles

Architectural styles define the overall shape and structure of a software system, each with its own unique set of characteristics. For example, the microservices architectural style scales very well and provides a high level of agility. whereas layered architectural style is less complex and less costly. The event-driven architectural style provides high levels of scalability and is very fast and responsive.

Because the architectural style defines the overall shape and characteristics of the system, it's important to get it right the first time. why? It's not easy changing from a monolithic layered architecture to microservices.

Is designing a software means that I'm responsible for its architecture as well?

No, Architecture & Design are different.

Sometimes it gets confusing trying to tell what is considered architecture and what is considered architecture. Architecture is less about appearance and more about structure while design is less about structure and more about appearance.

Suppose you want to replace outdated order processing system with a new custom-built one. From a design perspective, you might build a Unified Modeling Language (UML) class diagram that shows how the classes interact with each other to implement that the new order processing system. regardless the design, it does not tells anything about the Physical structure of the source code. In other words, how these class files would be organized and deployed.

Unlike design, architecture is about the structure of the system - things like services, databases, and how services communicate with each other and the user interface. Given the new order processing service - from an architectural perspective, you might decide to create separate service for each payment type within the order payment process and have an orchestrator service to manage the payment processing part of the system.

Spectrum between architecture and design

In reality, most decision yo encounter will fall in a spectrum between architecture and design. it is very important to identify where along the spectrum between architecture and design your decision lies. It helps very much determining who should be responsible for ultimately making that decision. In order to be able to identify your decision type, you need to have clear answers to the following questions about your decision: 

• Is it Strategic or Tactical?
• How much effort will it take to construct or change?
• Does it have significant trade-offs?

1. Strategic vs. Tactical

Strategic decision are long term and influence future actions or decisions. Tactical decisions are short term and generally stand independent of other actions or decisions. The more strategic the decision , the more it sits toward the architecture side of the spectrum.

2. High vs. Low Efforts

The harder (more effort)  something is to change later, the further it falls toward the architecture side of the spectrum. Generally, Software architecture is the stuff that's hard to change.

3. Significant vs. Less-significant

You can use the level of significance of the trade-offs in a particular decision to help determine whether that decision is more about architecture or design. Some decisions you make might involve significant trade-offs, such as choosing to deploy in the cloud or on premises. Others might involve less significant trad-offs like selecting a specific library (package) among multiple options.

Conclusion

All three factors should be used to figure out whether a decision is more about architecture or more about design. This tell development team when to collaborate with an architect and when to make a decision on their own. Some decision could fall in the middle between architecture and design, in another words, some decision has some architectural aspects as well as a design aspects.

On creating an architecture, you can't skip any of previously mentioned dimensions. They are all required to create and describe an architecture. One common mistake software architects make is using only one or two of these dimensions when describing their architecture. "Our architecture is microservices" describes a single dimension - the architectural style - but leaves too many unanswered questions. for example, What architectural characteristics are critical to the success of the system? What are its logical components (functional building blocks) ? What major decisions have you made about how you'll implement the architecture?