Software Architecture Foundations - Part 6

Question 1: What is an architectural quantum, and why is it important to architecture?

Answer: In general, the term "quantum" refers to a discrete unit or indivisible entity. In the context of architecture, an architectural quantum could potentially refer to a fundamental building block or modular component of an architecture, similar to how atoms are the fundamental units of matter in the quantum theory.

Designing an architecture with modular components or building blocks provides benefits such as reusability, maintainability, scalability, and flexibility. By decomposing the system into smaller, self-contained units, architects can manage complexity, improve code organization, facilitate parallel development, and support independent deployment and evolution of components.

Question 2: Assume a system consisting of a single user interface with four independently deployed services, each containing its own separate database. Would this system have a single quantum or four quanta? Why?

Answer: In the given scenario, where a system consists of a single user interface with four independently deployed services, each containing its own separate database, the system can be considered to have four quanta.

Each independently deployed service with its own separate database can be seen as a discrete and indivisible unit, representing a distinct architectural building block or component. Each service operates independently and has its own defined boundaries, responsibilities, and data storage. These services can be developed, tested, deployed, and scaled independently of each other.

Considering the modularity and independence of these services, they can be treated as separate quanta in the architecture. Each service can be individually managed, modified, or replaced without impacting the others. The user interface, which interacts with these services, can be seen as a separate component that orchestrates the interaction between the services.

It is important to note that the concept of quanta may vary depending on the architectural perspective or context in which it is used. The definition of a quantum can be subjective and depend on how the architecture is conceptualized or decomposed into building blocks. In this case, considering each independently deployed service with its own separate database as a quantum provides a modular and independent view of the architecture.

Question 3: Assume a system with an administration portion managing static reference data (such as the product catalog, and warehouse information) and a customer-facing portion managing the placement of orders. How many quanta should this system be and why? If you envision multiple quanta, could the admin quantum and customer-facing quantum share a database? If so, in which quantum would the database need to reside?

Answer: In the given scenario, the system can be divided into two quanta: an administration portion and a customer-facing portion. Here's the rationale behind this division:

Administration Portion: The administration portion manages static reference data such as the product catalog and warehouse information. It typically involves activities related to data maintenance, configuration, and administrative tasks. This portion represents a distinct functional unit with its own set of responsibilities and user interfaces.

Customer-Facing Portion: The customer-facing portion is responsible for managing the placement of orders and handling interactions with customers. It focuses on providing a user interface and functionality for customers to browse products, place orders, track shipments, etc. This portion represents the customer-facing aspect of the system, which is distinct from the administration portion.

While the two portions have different roles and responsibilities, they can share the same database if it makes sense from a data management perspective. The decision to share a database depends on factors such as data dependencies, data access patterns, and the need for data consistency across the system.

If it is feasible and beneficial to share the database, it would typically reside in the administration portion. This is because the administration portion is responsible for managing the static reference data, which is likely to be utilized by both the administration functionality and the customer-facing functionality. Placing the shared database in the administration portion allows for centralized data management, ensuring that updates to the reference data are reflected consistently across the system.

However, it is important to note that the decision to share or separate the database ultimately depends on the specific requirements, constraints, and trade-offs of the system. Architects should carefully consider factors such as data access patterns, data security requirements, performance considerations, and the potential impact of changes on both portions of the system before making a decision on the database placement.