In what way is an "architecture quantum" distinct from UML subsystems?

Question

I am reading "Fundamentals of Software Architecture" by Mark Richards & Neal Ford. They introduce the notion of an architectural quantum (p 92):

An independently deployable artifact with high functional cohesion and synchronous connascence.

Let's break that apart.

By independently deployable they mean it includes "all the necessary components to function independently from other parts of the architecture". They don't define "to function", but it is stated that "if an application uses a database, it is part of the quantum because the system won't function without it."

By high functional cohesion they mean "how well the contained code is unified in purpose."

By synchronous connascence they draw on a little-known measure of coupling—connascence—introduced in "What Every Programmer Should Know About Object-Oriented Design". Confusingly, for the purpose of their definition, they repurpose the term "connascence" to denote coupling on a higher-level architectural component level, e.g., a software package. Synchronous connascence (coupling) then implies "synchronous calls within an application context or distributed services" which prevent choosing meaningful differing "architectural characteristics" (the author's preferred name for non-functional requirements) for different components. For example, they state: "If the caller is much more scalable than the callee, timeous and other reliability concerns will occur."

I'm a sucker for good definitions with clear delineations (I'm an architect after all). But, at a glance, I see several problems with the proposed terminology:

• "To function" is ill-defined and depends on an ambiguous scope of functionality, which goes beyond the deployed artifact, to consider. The authors imply here that in microservice architectures a single microservice can "function" independently. But, even in an appropriate microservice decomposition, parts of an end-user's workflow will still stop "functioning", even if only temporarily in case eventual consistency is applied, if some of the dependent services are unavailable.
• Is there value in using a different name for the same concept at a different level of abstraction? I.e., connascence vs. coupling? Personally, I always understood "coupling" as a concept which can be applied to any level of abstraction in a codebase, i.e., within functions, between functions, between classes, or implicit knowledge a developer needs to know for two different parts of the codebase (semantic coupling). If connascence is a specific measure of coupling, why overload that term?
• This definition seems to mix architectural goals with a way to classify existing architectural components.

While reading this, I kept thinking: isn't this just a subsystem? As in, "subsystem decomposition", and "deployment diagrams" in UML (emphasis mine).

In UML models, subsystems are a type of stereotyped component that represent independent, behavioral units in a system. Subsystems are used in class, component, and use-case diagrams to represent large-scale components in the system that you are modeling.

Certainly, I appreciate the attempt at a more precise definition, since UML keeps it intentionally vague:

Definitions of subsystems may vary among different domains and software methods. It is expected that domain and method profiles will specialize this element.

But, I have a hard time understanding how the notion of "architecture quantum" can improve architectural discussions (especially given the esoteric definitions it relies on) over pre-existing terminology such as "subsystem", "coupling", "non-functional requirements", "deployment", "microservice", and "eventual consistency".

In what ways is "architecture quantum" more specific or meaningful than "subsystem" or "microservice"?

Answer 1

The term "architectural quantum", as defined by Richards and Ford, is essentially microservice, without the baggage.

An architectural quantum is more specific than a subsystem. Take, as a specific example, the concept of a majestic monolith. Because it's a monolith, the subsystems within it are not independently deployable. However, because the subsystems tend to communicate over well-defined APIs and have isolated data, a majestic monolith is viewed as something that could be decomposed into a service-oriented architecture by extracting a subsystem. Since these subsystems are not independently deployable, they don't fit the definition of architectural quantum - they have high functional cohesion and synchronous connascence but are not independently deployable.

Architectural quantum sidesteps some issues with microservices, especially around the definition of "micro". The micro prefix implies some level of size, which I find gets in the way of the intent behind the approach. Instead of focusing on size, the focus should be on the relationships. I believe a good example would come from Domain-Driven Design. An architectural quantum would relate directly to a bounded context. Often, microservice is used in this context.

I'm not sure I've ever heard the term "architectural quantum" before. I'm not convinced it is the best term. Still, it is likely better than microservice because it removes discussion of smallness while adding additional architectural and design constraints beyond subsystem.

Answer 2

But, even in an appropriate microservice decomposition, parts of an end-user's workflow will still stop "functioning", even if only temporarily in case eventual consistency is applied, if some of the dependent services are unavailable.

Well obviously in any system consisting of services that interact at all, then some kind of useful functionality must be precluded when the connection is severed and for as long as it remains severed.

The point of microservices though is that they are supposed to have reasonably independent functionality that will sustain at least as long as a reasonable maintenance period.

I suppose there could be a variety of definitions of "independent functionality", but I would suggest that whatever the jobs of your users are who use the service, they should be able to get on with at least some useful minimum of their work if not the majority or entirety.

An example of this could be a retail payment service in the financial sector. If the connection from the payment point to central systems is severed, the payment service will continue to accept and record payments, but will suspend authorisation and fraud checks, with the increased risk accepted. The core functionality of recording payments for transactions occurring stays online and available, most of which are legitimate, but there is a graceful degradation of auxiliary functions. This is rather than the whole retail economy being ground to a halt every time a phone line gets cut.

The practical effect is that all transactions are entered and stored for processing, and there is only a small sweep-up afterwards if some transactions are in fact fraudulent, which might even still allow you to catch the goods in transit - well worth the effort compared to pulling your shutters down completely during the partial outage, or even writing down everything on paper to be entered when the system resumes full availability.

However, it's rather pointless to decompose services that cannot realistically do anything without each other. You then bear all the software overheads of dealing with interacting services that cannot be assumed to be available, but with no return on the effort.

what ways is "architecture quantum" more specific or meaningful than "subsystem" or "microservice"?

The perceived advantage is probably that the authors alone get to define this new term, free of any other baggage or infelicities.

We've been having arguments here recently about the meaning of "microservices" itself, and the upshot is that it isn't a very clear term in its own right and some of us have significantly different views about it.