Lesson189 - Architectural Quantum Tradeoffs
Summary
TLDRIn 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
📚 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.
🔍 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.
🛠 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.
Mindmap
Keywords
💡Architectural Quantum
💡Trade-offs
💡Dynamic Quantum Entanglement
💡SISP Squad
💡Distributed Architecture
💡User Interface
💡Synchronous Dynamic Coupling
💡Asynchronous Communication
💡Database Dependency
💡Fault Tolerance
💡Data Consistency
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
Посмотреть больше похожих видео
5.0 / 5 (0 votes)