Architecture Quantum

Software architecture

What if you could update part of a system without worrying about breaking anything else? How do complex applications like e-commerce platforms or real-time collaboration tools handle updates and scaling with ease? What hidden architecture allows modern software to evolve rapidly, staying flexible yet robust? The answer lies in the intriguing concept of the "architecture quantum". Primarily introduced and detailed in the book "Building Evolutionary Architectures", this idea unlocks the mystery behind how software components can operate, deploy, and scale independently, while still working harmoniously within a larger system. Could this be the key to mastering modern, adaptable software design?

Key Components of the Definition

The key characteristics of an architecture quantum¹²³revolve around its ability to function independently while maintaining cohesion within a larger system. A quantum is designed to be autonomously deployable, meaning it can be updated or replaced without disrupting other components. It also exhibits high functional cohesion, where all internal elements work together to achieve a specific goal. Additionally, quanta interact with other system parts through varying degrees of static and dynamic coupling. These characteristics — independent deployment, strong internal cohesion, and controlled coupling — make architecture quanta essential for building flexible, scalable, and resilient systems.

Independently deployable artifact

Let’s consider an e-commerce system composed of multiple microservices, each handling different functionalities like user management, payment processing, or product catalog management.

The microservice responsible for the product catalog can be updated (e.g., adding a new product filtering feature) without affecting the operation of other microservices, such as payments or user management. Since it functions autonomously, its deployment does not require simultaneous updates to other microservices.

A quantum of architecture that can be deployed and operate independently is an autonomous component within the system. This means it can be deployed, updated, or replaced WITHOUT disrupting the operation of other system parts.

Another good example is a serverless architecture. Individual functions are deployed and executed independently in response to specific events, such as HTTP requests, database changes, or messages in a queue. Each function performs a single task, like processing an image, handling a user authentication request, or sending a notification.

These functions are completely autonomous, meaning they can be deployed, updated, or replaced without affecting other functions or parts of the system. For instance, in a serverless application that processes user-generated content, one function might handle image uploads by resizing and compressing images, while another handles text moderation. The image processing function can be modified or deployed without needing to change the text moderation function or any other part of the application. This independence in deployment allows for greater flexibility and faster iteration in development.

An independently deployable artifact is also a plugin. In a modular software system, a plugin is a component that adds specific features or functionality to a larger application, such as a content management system (CMS) like WordPress.

Plugins are designed to be installed, activated, updated, or removed independently of the core application and other plugins. In a WordPress site, we might install a plugin for SEO optimization, another for contact forms, and a third for e-commerce functionality. Each of these plugins operates independently, meaning we can update the SEO plugin without affecting the functionality of the contact form or e-commerce plugins. This independence allows site administrators to tailor the system to their needs by selectively deploying and managing plugins without disrupting the overall site.

High functional cohesion

In a banking application, a quantum of architecture responsible for handling bank transfers can be identified. Within this quantum, there are modules responsible for verifying the user's identity, validating transaction data, and updating account balances. All these elements collaborate to ensure that the transaction is secure and compliant with regulations. High functional cohesion means that these modules are tightly connected and work together to achieve a common goal.

Functional cohesion means that all elements within a quantum of architecture work together to achieve a specific function. These elements are logically connected, enabling the quantum to effectively carry out its tasks.

Another example of high functional cohesion is a logging module within an enterprise application. A logging module is designed to handle all logging-related tasks within an application, such as recording error messages, tracking user activities, and capturing debug information. The module is responsible for managing different types of logs (e.g., error logs, access logs, transaction logs) and ensuring they are correctly formatted, stored, and possibly forwarded to external monitoring systems.

All components within the logging module are tightly integrated and work together to fulfill the sole purpose of logging. For instance, the module may include components for log message formatting, log-level filtering, and writing logs to files or sending them to remote servers. Each component is directly related to the overall goal of logging, ensuring that the module exhibits high functional cohesion. This focused and logical organization of components makes the logging module efficient and easier to maintain.

Let’s consider an authentication module within a web application. An authentication module is designed specifically to handle all aspects of user authentication, including login, logout, password management, and session handling. Every component within this module is dedicated to verifying user credentials, managing user sessions, and ensuring secure access to the application. For example, the module may include components for validating user credentials against a database, handling password resets, generating and verifying session tokens, and logging authentication events. All these components work closely together to achieve the single goal of managing user authentication. Because each part of the module is directly related to this core function, the module exhibits high functional cohesion. This cohesion ensures that the authentication process is reliable, secure, and easier to manage and update.

High static coupling

A microservice responsible for image processing may have strong dependencies on external libraries for graphic processing (e.g., OpenCV). These dependencies must be considered during the microservice's compilation and deployment. If this microservice is deployed in an environment that does not support the required version of the OpenCV library, it will not function correctly, illustrating high static coupling.

Static coupling refers to the dependencies that exist between a quantum of architecture and other system elements before the system is run. These dependencies are defined during the design and implementation stages.

An example of high static coupling is a Java-based Enterprise Application that relies on a specific version of a Java Enterprise Edition (Java EE) library, such as the Java Persistence API (JPA) or Java Servlet API. This static coupling is evident because the application's code is designed to work with particular classes, methods, and interfaces provided by the library.

• Dependency on Library Version: The application might use specific features or bug fixes present only in a particular version of the JPA library. If the library is upgraded or replaced with a different version, the application may require significant changes or may even break if there are incompatible changes.

• Tightly Integrated APIs: The application’s code directly interacts with classes and methods from the library. For example, if the application uses a specific implementation of JPA entity managers, it is tightly coupled to that implementation.

• Configuration Dependencies: The application might rely on specific configuration settings or annotations provided by the Java EE library, making it dependent on the library’s expected configuration structure.

In this scenario, high static coupling means that the application's deployment, maintenance, and potential upgrades are closely tied to the Java EE library. Changes to the library version or configuration can have significant implications for the application’s behavior and functionality.

Another example of high static coupling is a legacy application that relies on a specific version of a database management system (DBMS). Consider a legacy application designed to interact with a particular version of a relational database management system, such as Microsoft SQL Server 2012. The application may use specific features, stored procedures, or SQL queries that are tailored to this version of the DBMS.

• Dependency on DBMS Version: The application’s code and queries are optimized for the specific features and behavior of Microsoft SQL Server 2012. For example, it might use certain SQL functions or database features that are only available in this version.

• Direct Interaction with DBMS: The application’s database layer is tightly coupled with the DBMS, using proprietary SQL syntax, custom stored procedures, and specific database schema designs. This tight coupling means that the application relies heavily on the internal workings of the DBMS.

• Configuration and Setup: The application might be configured to work with specific database settings or connection parameters unique to SQL Server 2012. Changes to the DBMS, such as upgrading to a newer version or switching to a different DBMS, might require substantial rework of the application’s data access code and configuration.

In this scenario, high static coupling occurs because the application’s functionality and performance are closely tied to the specific version of the DBMS. Upgrading to a newer version of the DBMS or migrating to a different DBMS would require significant changes to the application’s codebase and possibly its architecture, making such transitions complex and costly.

Synchronous dynamic coupling

In a real-time collaborative editing application, such as Google Docs, multiple users can simultaneously edit a document. The application must ensure that all changes are synchronized across all users in real-time.

• Change Propagation: When a user makes an edit (e.g., typing a new line of text), the application synchronously sends the change to the server. The server then processes this change and updates the document for all other users currently viewing or editing the document.

• Live Updates: Other users’ clients must receive and display the update in real-time. This requires synchronous communication between the server and each client to ensure that all users see the changes immediately.

• Conflict Resolution: If two users make conflicting changes to the same part of the document simultaneously, the system must synchronize these changes and resolve conflicts in real-time. This requires immediate interaction between the clients and server to determine the final state of the document.

• Session Management: The application must synchronously manage user sessions, including handling actions like user joining or leaving the document. When a new user joins, the system synchronously updates their view with the latest state of the document.

Synchronous dynamic coupling ensures that all users have a consistent and up-to-date view of the document. Each component (client, server, and possibly a backend synchronization service) communicates in real-time, with each user’s changes being immediately reflected to all others. This real-time dependency is crucial for collaborative editing but can lead to issues if any component experiences delays or connectivity problems.

Dynamic coupling describes the interactions between architectural quanta in real-time when the system is running. Synchronous coupling means that components must communicate with each other immediately, waiting for responses before continuing their operations.

Another example of synchronous dynamic coupling is a real-time chat application. In a real-time chat application, components such as the chat client, server, and message broker are tightly coupled through synchronous communication. When a user sends a message, the following steps illustrate synchronous dynamic coupling:

• Message Sending: When a user sends a message from their chat client, the client sends a request to the server to deliver the message. This communication is synchronous because the client often waits for an acknowledgment or confirmation from the server that the message has been received and is being processed.

• Real-Time Updates: The chat server, which handles incoming messages, processes the message and then synchronously sends it to the intended recipient's client. The recipient's client waits for this message to arrive in real-time before updating the chat window and notifying the user.

• Error Handling: If there is an issue during the message delivery (e.g., network failure), the chat client must handle this error in real-time. The client might wait for a response from the server indicating that the message could not be delivered, and then take appropriate action, such as retrying the message sent or notifying the user of the failure.

In this scenario, synchronous dynamic coupling means that the components (chat client, server, and message broker) must interact in real-time, with each component waiting for immediate responses before proceeding. This ensures that messages are delivered and received promptly, maintaining the real-time nature of the chat application. However, it also means that if any component experiences delays or failures, it can impact the overall responsiveness and reliability of the chat system.

Significance

The concept of a quantum of architecture is crucial for analyzing and designing modern, complex systems, especially those with distributed architectures like microservices. It allows software engineers to break down a system into smaller, manageable units, facilitating easier deployment, testing, and scaling of individual components. Analyzing a system at the quantum level enables a more precise understanding of its characteristics, such as flexibility, fault tolerance, and scalability, without the need to consider the entire system as a whole.

Summary

The term "architecture quantum" refers to a modular unit within software architecture that can operate and be deployed independently within a system. Key characteristics of an architecture quantum include its independence in deployment, high functional cohesion (where components work together to perform specific tasks), and varying degrees of static and dynamic coupling. Understanding and applying the concept of architecture quanta helps engineers by enabling them to break down complex systems into manageable units, facilitating easier deployment, testing, and scaling, and allowing for a more precise analysis of system characteristics such as flexibility and fault tolerance.

1. Building Evolutionary Architectures: Automated Software Governance, Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage

2. Fundamentals of Software Architecture. An Engineering Approach, Mark Richards, Neal Ford

3. Software Architecture: The Hard Parts. Modern Trade-Off Analyses for Distributed Architectures, Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani