Lesson189 - Architectural Quantum Tradeoffs

Summary

In this episode of 'Software Architecture Monday,' Mark Richards explores the concept of architectural quantum, a term that describes independently deployable artifacts with high functional cohesion and synchronous dynamic coupling. He revisits the idea of dynamic quantum entanglement and its implications for system dependencies. Using the 'sisp squad' as a case study, Richards illustrates the trade-offs involved in creating or separating architectural quanta, emphasizing the importance of balancing user experience with the benefits of modular, independently deployable system components.

Takeaways

• 👋 Introduction: Mark Richards starts the lesson on 'Software Architecture Monday' discussing the architectural quantum concept and trade-offs involved.
• 🧑‍🎨 Theme: The lesson focuses on the architectural quantum, a concept that Mark has previously touched upon in lesson 138, and its implications in system design.
• 🔍 Definition: An architectural quantum is an independently deployable artifact with high functional cohesion and synchronous dynamic coupling.
• 📚 Source: The concept is identified in 'Building Evolutionary Architectures' by Neil Ford, Rebecca Parsons, and Patrick Qua and further refined in 'Software Architecture: The Hard Parts'.
• 🛠️ Example: The SISP Squad, a trouble ticket system for electronics support plans, is used to illustrate the architectural quantum and its trade-offs.
• 🔄 Dynamic Quantum Entanglement: Systems can become unknowingly entangled, creating dependencies between them through both synchronous and asynchronous communication.
• 🔑 Key Insight: Architectural characteristics live at the quantum level, and understanding these can help in the partitioning of complex systems.
• ⚙️ Trade-offs: There are trade-offs between creating separate, independently deployable units of architecture and maintaining a cohesive user experience.
• 🔄 Dependency: Synchronous dynamic coupling can bind architectural quanta together, even if they are designed to be separate, due to shared resources like databases.
• 🛑 Solutions: One solution to entanglement is to create separate user interfaces and databases for different functionalities to ensure independence.
• 🤔 Consideration: The decision to separate or entangle architectural quanta depends on the importance of user experience versus the benefits of independent deployment and system characteristics.
• 📈 Conclusion: Mark emphasizes the importance of understanding the architectural quantum concept and its trade-offs in software architecture, as everything involves a trade-off.

Q & A

What is the main topic of the 189th lesson by Mark Richards in 'Software Architecture Monday'?

The main topic of the lesson is the architectural quantum concept and the trade-offs involved in using or forming architectural quanta.

What does Mark Richards wear when he discusses trade-offs as a core piece of the lesson?

Mark Richards wears his architecture shirt that says 'It Depends' when discussing trade-offs.

What is the concept of an 'architectural quantum' as defined in the script?

An architectural quantum is an independently deployable artifact with high functional cohesion and synchronous dynamic coupling, including all necessary components for the functionality to work.

What book is mentioned in the script that identified the concept of an architectural quantum?

The book mentioned is 'Building Evolutionary Architectures' by Neal Ford, Rebecca Parsons, and Patrick Kua.

Can you describe the 'SISP Squad' system mentioned in the script?

The SISP Squad is a trouble ticket system for customers who buy electronics and purchase a support plan. It allows customers to register, submit problem tickets, and have customer-facing experts fix their issues at their location.

How does the 'SISP Squad' system illustrate the concept of architectural quanta?

The SISP Squad system shows how different parts of the architecture, such as customer login/profile, ticket creation, and operations reporting, can be independently deployable and share the same database, forming separate architectural quanta.

What is the issue with the original 'SISP Squad' system architecture in terms of architectural quanta?

The issue is that while the system appears to have separate parts, the shared database creates a synchronous dynamic coupling that binds them together into a single architectural quantum, which can lead to entanglement and dependency issues.

What is one way to address the problem of architectural entanglement in the 'SISP Squad' system?

One way to address the problem is to create a new user interface for ticket creation, making it a separate architectural quantum independent of the customer profile and login functionalities.

What trade-offs are involved in creating separate architectural quanta for ticket creation and customer profile management?

The trade-offs include potentially disrupting the user experience with separate user interfaces and the complexity of synchronizing session state between the separate deployment units, versus the benefits of having independent, deployable units of architecture.

What alternative solution is presented to avoid disrupting the user experience while addressing architectural entanglement?

An alternative solution is to create a separate ticket creation database, allowing ticket creation to be a separate quantum, while maintaining a good customer experience with a single front end and ensuring data consistency and integrity.

What is the key takeaway from the lesson regarding architectural quanta and trade-offs?

The key takeaway is to understand the importance of the architectural quantum concept for partitioning systems and recognizing dependencies, while also being pragmatic and considering the trade-offs involved in system design decisions.

Outlines

00:00

📚 Introduction to Architectural Quantum Concepts

In this video script, the presenter, Mark Richards, introduces the concept of architectural quantum, a term that refers to an independently deployable artifact with high functional cohesion and synchronous dynamic coupling. He discusses the trade-offs involved in using architectural quanta and references a previous lesson (lesson 138) where he first introduced this concept alongside the idea of dynamic quantum entanglement. The script mentions a book titled 'Building Evolutionary Architectures' by authors Neil Ford, Rebecca Parsons, and Patrick Qua, who first identified the concept of architectural quantum. The presenter uses a case study of a support ticket system to illustrate the concept and the trade-offs involved in forming architectural quanta.

05:01

🔍 Analyzing Architectural Quanta and Trade-offs

The second paragraph delves into a detailed analysis of the architectural quantum in the context of a distributed system. The presenter identifies different parts of the system that could potentially be separate architectural quanta, such as the operations reporting and customer-facing areas. He discusses the concept of synchronous dynamic coupling and how it can entangle what might otherwise be separate quanta. The presenter then explores the idea of creating separate user interfaces for ticket creation and customer profile management to avoid entanglement, but also acknowledges the trade-offs of potentially disrupting the user experience and the complexities of synchronizing session states between separate deployment units.

10:01

🛠 Addressing Architectural Quantum Challenges

In the final paragraph, the presenter addresses the challenges of maintaining a good customer experience while ensuring the system's backend is scalable, responsive, and fault-tolerant. He suggests creating a separate database for ticket creation to make it a distinct architectural quantum, which would necessitate a synchronization process between the ticket creation and the ticketing backend functionality. The presenter emphasizes the importance of understanding the trade-offs associated with architectural quantum, such as data consistency and integrity, and the impact of dependencies on system characteristics. The lesson concludes with a reminder of the importance of being pragmatic in software architecture and considering all trade-offs.

Keywords

💡Architectural Quantum

The term 'Architectural Quantum' refers to an independently deployable artifact with high functional cohesion and synchronous dynamic coupling within a system. It is a concept that helps in understanding the partitioning of systems and the dependencies between different components. In the video, it is used to discuss the trade-offs involved in forming these quanta, such as the example of a trouble ticket system where different parts like customer login, ticket creation, and operations reporting are considered in terms of their deployability and coupling.

💡Trade-offs

Trade-offs are decisions made between two or more alternatives, each with its own advantages and disadvantages. In the context of the video, trade-offs are discussed in relation to the architectural quantum concept, where creating separate deployable units may improve system modularity but could affect user experience or data consistency. The script uses the phrase 'it depends' to emphasize that the decision to create separate architectural quanta should be based on weighing these trade-offs.

💡Dynamic Quantum Entanglement

Dynamic Quantum Entanglement is a concept that describes how systems can become unknowingly interdependent, creating a relationship between them. It is mentioned in the script as a previous topic that the presenter discussed in lesson 138 and is related to the use of asynchronous and synchronous communication in forming architectural quanta. The example of ticket creation and routing in the script illustrates how entanglement can occur due to shared databases and synchronous calls.

💡SISP Squad

SISP Squad is an architectural kata used in the video as a concrete example to illustrate the concept of architectural quantum. It represents a trouble ticket system for customers who purchase electronics and a support plan. The script describes how different functionalities like customer login, ticket creation, and operations reporting could be part of separate or entangled architectural quanta within this system.

💡Distributed Architecture

Distributed Architecture refers to a system whose components are located on different networks but still work together as a unified whole. In the video, the SISP Squad system is described as having a distributed architecture, with separate services for customer interaction, ticket routing, and operations reporting, which are all interconnected through their shared database and asynchronous communication.

💡User Interface

A User Interface (UI) is the point of interaction between a user and a system, allowing users to input data and commands and receive output. In the context of the video, the UI is mentioned in relation to the customer-facing aspects of the SISP Squad system, such as logging in and updating customer profiles, which are considered in terms of their architectural quantum.

💡Synchronous Dynamic Coupling

Synchronous Dynamic Coupling is a term used to describe the way components within an architectural quantum interact with each other in real-time. The video script explains that this coupling binds different parts of a system together, as seen in the ticket creation process, which relies on synchronous calls to the ticket router.

💡Asynchronous Communication

Asynchronous Communication refers to a communication method where the sender and receiver do not need to be active at the same time. In the video, asynchronous communication is used to separate architectural quanta, such as the ticket router receiving tickets independently of the ticket creation process.

💡Database Dependency

Database Dependency occurs when different parts of a system rely on the same database, which can create a single point of failure or coupling between those parts. The script discusses how ticket creation, customer login, and profile updates share the same database, forming a single architectural quantum due to this dependency.

💡Fault Tolerance

Fault Tolerance is the ability of a system to continue operating, even when some of its components fail. In the video, fault tolerance is considered as a requirement for the customer-facing parts of the SISP Squad system, which need to be highly available and responsive, contrasting with the backend parts that may not require the same level of fault tolerance.

💡Data Consistency

Data Consistency refers to the accuracy and reliability of data across a system. The video script discusses the trade-off between creating separate architectural quanta, which can improve system modularity, and maintaining data consistency, which can be challenging when different parts of the system operate independently.

Highlights

Introduction to the concept of architectural quantum and its importance in software architecture.

The speaker's unique approach to wearing an architecture shirt to symbolize the concept of trade-offs in architecture.

A quick review of architectural quantum from a previous lesson, highlighting the concept's evolution.

Definition of an architectural quantum as an independently deployable artifact with high functional cohesion and synchronous dynamic coupling.

The identification of architectural characteristics living at the quantum level, as discussed in 'Building Evolutionary Architectures'.

Illustration of the architectural quantum concept using the SISP squad example, a trouble ticket system.

Analysis of the trade-offs involved in using or forming architectural quanta through the SISP squad example.

Explanation of dynamic quantum entanglement and its impact on system dependencies.

The dilemma of whether to separate ticket creation into its own architectural quantum to reduce dependencies.

The impact of synchronous dynamic coupling on the formation of a single architectural quantum despite distributed architecture.

Proposing a solution to create a separate user interface for ticket creation to form an independent architectural quantum.

Discussion on the trade-offs between user experience and system architecture separation.

Alternative solution of creating a separate ticket creation database to achieve architectural quantum separation.

The importance of balancing system scalability, availability, and fault tolerance with customer-facing functionalities.

The trade-off between data consistency and integrity against the benefits of separate front-end and back-end systems.

Emphasizing the significance of understanding and considering trade-offs in software architecture decisions.

Conclusion highlighting the importance of the architectural quantum concept and its impact on system partitioning and dependency management.

Transcripts

hello everyone and welcome to software

architecture Monday my name is Mark

Richards and in this lesson number 189

I'm going to talk a little bit about the

architectural quantum concept but also

some of the trade-offs involved uh you

may be noticing my shirt I decided

anytime I need to talk about tradeoffs

as a core piece of it I'm actually going

to wear my architecture shirt which says

of course it depends

you can get a listing of all the lessons

I do in software architecture Monday at

my website at developer to architect.com

lessons speaking of lessons if we go on

the Wayback machine all the way back to

lesson

138 I talked about the architectural

quantum concept and also something

called Dynamic quantum entanglement how

we tend to entangle systems unknowingly

uh creating dependenc between them well

in this lesson I'm going to offer up a

very quick review of that architectural

Quantum but show you some of the

trade-offs

involved with using or forming

architectural

quanta so in the building evolutionary

architectures book by Neil Ford Rebecca

Parsons and Patrick qua uh they

identified this concept of an

architectural Quantum which we later

refined in our books software

architecture the hard

Parts uh basically it's an independently

Deployable artifact with high functional

cohesion and

synchronous Dynamic coupling but this

doesn't mean a service an independently

Deployable artifact means an

independently Deployable portion of the

system including all of the things

needed for that functionality to work

that includes the user interfaces

Services gateways the database uh

Brokers all of that

stuff that has high functional cohesion

and all of it is coupled

synchronously uh inside that

architectural

Quantum now the Revolutionary aspect of

this uh that uh Neil Rebecca and Patrick

had identified and discovered is that

architectural characterist ICS those

things we've been looking at at the past

couple of lessons live at an

architectural Quantum level and I want

to show you an example of this and also

the tradeoffs of

this so in order to illustrate a solid

concrete example uh we're going to use

uh something called the sisp squad this

was the architectural qu architectural

Kata uh that we had identified in our

book software architecture the hard

Parts uh this is a trouble ticket system

where if customers Buy electronics uh

they can also purchase a support plan if

they have an issue uh the customer can

register with this site uh submit a

problem ticket and our customer facing

experts those of the ssop squad will

come to your home or office and fix your

problem let me show you the arch ecture

for this and then we'll analyze the

architectural Quantum and the tradeoffs

with that so let's say we have a

customer

myself I interact with a web-based user

interface to be able to log in to be

able to also uh update my customer

profile and my support plans and my

address and all that kind of stuff and

both of these separately deployed

Services share the same data base

but I can also create tickets through

this website so I create a ticket and

now we have the sisap squad so what

happens that ticket creation when a

ticket gets created

asynchronously is sent to a ticket

router that ticket router basically

finds an expert and routes that ticket

to their mobile device on their

iPhone now that expert will go out to

the field fix fix the problem and then

Mark the ticket as complete which kind

of ends the whole process and all three

of these separately deployed Services

all share the same

database now behind the scenes we've got

our manager that would be Neil over

there which uses a separate user

interface to do operations reporting of

all the various Financial reports expert

reports forecasting and so

on when we take a look at this system

it is a distributed architecture but how

many separate parts are there to it in

other words if we think about that

definition of an architectural Quantum

independently Deployable part of the

system held together with synchronous

Dynamic

coupling now in in lesson 138 I showed

you that Dynamic quantum entanglement

with the use of async and synchronous

communication

so looking at this what architectural

quanta which is plural for Quantum do we

have here totally separate independent

parts of the system well certainly the

easy one here is of course the

operations reporting we see that the

interface the service and the database

are completely independent from all

other parts it doesn't depend on

anything else in the system we might

also take a look here at our customer

facing area here uh the customer login

and profile with that corresponding user

interface um this looks like that might

be part a separate part of the system as

a matter of fact we'd like the whole

backend piece the routing and completion

to all be a separate part of the system

separately Deployable no synchronous

coupling or dependency with any other

parts and that kind of leaves ticket

creation to kind of be also another

custom customer facing piece so we might

say oh there's four architectural Quant

here but if we look at the

definition we have synchronous Dynamic

coupling which binds those architectural

Quant together in other words ticket

Creations needed for that interface and

that customer which means that I showed

in lesson 138 that synchronous call

entangles those two quanta into a single

architectural

Quantum but we also notice ticket

creation has a dependency on a database

used by these other services even though

there's an asynchronous call right here

between ticket creation and router which

does separate architectural quanta

because they're not dependent on each

other that's

async but because of the database

dependency that now forms a single

architectural Quantum which means that

even though we have a distributed

architecture ultimately everything is

entangled and this becomes a single unit

of

architecture hence this is where the

characteristics live they need to be

shared between these because of those

dependencies how do we fix this problem

well one way to address this would say h

well this this line right here of course

sort of bothers me so in order to form a

separate architectural

Quantum what if I created a new user

interface for Ticket

creation and now had a separately

deployed user interface to create

tickets versus maintain my customer

profile and

login well if I do that

now customer functionality is completely

independent of everything else that is

its own architectural

Quantum separate from all of this so

that is one way we can do this and now

we now have two architectural

quanta well this is an interesting

exercise because now we get to the Crux

of this whole Topic in this lesson and

that

is should we do this and the answer on

my shirt says it depends

because now we have to analyze the

tradeoffs of doing so in other

words is it worthwhile having two

separate architectural quanta each

owning its own set of architectural

characteristics versus disrupting the

user experience by having the

complexities of two separate user

interfaces and maybe even the

complexities of synchronizing the

session state between those two separate

deployment units on the interface and

this this is it depends should we do

this it depends on which is more

important the user experience or the

reasons for actually creating those two

separate Deployable units of

architecture well there's another way we

could have solved this problem so let's

go back and say no we we don't we don't

want to disrupt the user experience um

so one other way to maybe do this is to

say wait a minute ticket creation

they're in the middle really is customer

facing although it's ticketing it really

involves the customer so how can I make

that a separate

Quantum well what we can do is create a

ticket creation

database and now ticket creation talks

only to that data which means

that now unfortunately we'd have to have

some sort of synchronization process

behind the scenes a synchronous between

creation and all the other ticketing

backend

functionality so this would in fact

create two separate architectural Quan

it would actually break those

apart so now ticket creation customer

profile and login are all of our

customer facing operations those need to

be highly available scalable responsive

fault

tolerant whereas our second quantum here

is more backend we have only a few

experts so we don't need the scalability

the fault tolerance the reliability that

we need for our external

customers that makes sense but let's

take a look at my

shirt it depends because what are the

tradeoffs associated with this now what

we're talking about is a good customer

experience separate front end backend

parts of the system because of this

async which are completely separate one

can go down and the other one still

lives but the tradeoff is data

consistency and data

Integrity so these are some of the

tradeoffs that we face when we look at

an architectural Quantum uh this concept

everyone is incredibly important for the

partitioning of our systems and

understanding the

dependencies between complex systems and

when some problem happens way down the

line it ends up impacting us over here

because of those dependencies because of

those

Quantum so this is an important concept

what I'm trying to drive in this

particular lesson is take this concept

to Heart

but understand the corresponding

tradeoffs to make that

happen so this has been lesson 189 the

architectural Quantum and the

corresponding tradeoffs associated with

those I know fairly complex sort of deep

architectural topic but one that is

important because try to be pragmatic

about everything because everything in

software architecture is a tradeoff so

thank you so much for listening and stay

tuned in two more months days uh for the

next lesson in software architecture

Monday