Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/2200 Thanks!
So welcome back to the cast
on the TV stage, the next talk
is about software architectures
and software. Actually, architectures are
one of the things young programmers
should learn in the early years.
Maybe.
I hope to do so.
They are the solution for problems seen
by more experienced programmers when they
have to fix code, which in some
shady path found its way from
the first visibility prototype by
a tinkerer to a production code in the
field.
I respect this pick, Alex.
He study that Informatics Andreessen
took the usual way of a dissertation
apprenticeship, an industry job, and from
that came to be trained and a
consultant.
He gives seminars for project management
and software architecture,
and he intends to talk about
the when and why software architecture
is important for us as hackers and
make us.
He give you a very, very basic
introduction. And he condensed some weeks
of details in the 40 minutes of video
stream.
He did his very best, and the
software architectures found
in that case may be a commented
the spaghetti code.
I know and went on big
ball of mud.
Maybe the guy can give us
better examples and alternatives
in the next 40 minutes and
the stage is yours.
Nice introduction, and don't get me
started about prototypes and prototypes
coming production software and something
like this, and
I'm still a little bit
scared about the scope and I still don't
know what came over me
to change that.
Anything even remotely
resembling a meaningful introduction
to software I should take to could
somehow be into compressed
into a 40 minute talk.
So but what I try to do
my best to have some meaningful talk
for you and I,
I really, really should
have known better keynotes
already announced me.
I work on a I
talk on a regular basis about
software I should take with others.
And once we decide to dove
into the topics
do, you can spend hours
to cover the basic ideas
and principles.
But what
made me do this talk is that
there are some things that I wish
I would have known.
Then I started taking on
complex projects and
more, more bigger long term
software projects, and I want
to give to you a short introduction.
What software I should talk to really
about what,
what, what you should consider
to be.
The problem I have with this talk
is a bit on
the what what snake makes me even more
scared as the audience of this
talk, because every one of you
for sure has his
or her scar tissue and
campfire horror stories
about software I should take.
And software I should take.
And usually, as hackers or makers,
we have to deal with the results
of bad software.
I should take place in our hands of
it, and some of us
you can consider I should take
this to the people who do not
or cannot code anymore or want
not cold anymore.
And everyone also
had already met in his or
her professional life.
Those people God trolls false.
The cold.
I should take trust humans.
So he says.
So we had a really great rant about
those type of I should ticked
and to say, as they're so high up
in the abstraction and saying on such
a remote level that what
they create is basically useless.
They create high level abstractions, high
level ideas about
our system.
And but they
they're good and timed out well, but they
are not of any use to someone who
wants to implement the system for
you, but you definitely want to avoid
this.
And the other horror stories
are most of us possibly
had. So what
sometimes is called conference?
I should you that there are some
big hype topics in your company
or community where you have
to go. Yes, we have to use
microservices and the customer wants
blockchain. And, you know, it's
a big steaming pile of whatever
garbage.
But this is what a customer
wants or what others see as important
and or what leadership
seem to be important when
it comes to marketing slides.
And it really, really hurts developers
as this is done without
proper reasons and intention.
I don't say that all of
these technologies are bad
or or horrible.
Microservices can totally make sense, but
there has to be a reason for this, and
not just because someone told your
project manager while golfing that
you need to do Michael.
So it was I should take trust on Google
to become the next Netflix, or Google
has to do it.
There has to be a reason for this.
So what I want to do in
this talk, we can only
cover really, really the
absolute basics of software.
I should take trouble at
first. I want to start out, but
then my I should take Charles
offer. I should take to be relevant for
you, be relevant for Hechos American
soldiers community. If I do, I think this
might be important for you.
The next thing is what it is really
about what is meant by software.
So this is the thing that
someone would have told me at the very
beginning before diving
into this topic and then why
it matters.
And then I
will give a very, very brief
introductory what you can do to
come out of the corner.
Good architecture, what can be
a good? I stick to what what I thought is
so sweet.
Talk about this later on.
So let's start for some
assumptions about you.
Why should I should take to be
relevant for you and
why should you care about it?
So what what I have in mind about
the people in my Cale's community
and concern and treat me to
the Hechos. So why should
they care about I should stick to what
they usually do is completely
opposite to I should take to just
want to have fun with technology and
find new creative uses.
But if you really want
to use the system in
another way that it is
intended, you
have so much to know some common
structures or design rules or technical
limitations of the system.
Just put us under scrutiny by you.
So typically every
class of system has its trade
offs. It's oh, it's
it's back.
At least someone did possibly
cut corners to make life easy
for the development team or to bring it
faster to the market on something like
this on software. Actually, texture
possibly could
tell you something about this.
So for me, so to make a community,
this is also not quite that obvious.
Five people, would you want
to use AI?
If you want trust to tinker with
technology and play around and
create new friends and stuff,
that's totally fine.
You might very well this adult
architecture.
But the thing also at the moment,
you want to create some
sustainable software solutions,
something some projects on Lightroom
of framework or some
Arduino application
that you want to use for
a longer amount of time.
Or you want to build a community
of developers or users around
that, then you simply can't lift
that out. Knowledge of software because
it's important
success factor to make the stream
flow without software actually texture,
you might run into trouble,
and the last people
of our community pulls up beside all the
software professionals they have to deal
with.
I should take share every day here
social, political actors, those people
working and mix politics,
those people wanting
to make sure that we get better
software in our daily lives from
government politics and so on.
And the thing
a software actually tech is not only
about technical discussions than poacher
trails of or big government
project one one is
trade. This is not necessarily
cause because there are bad software
developers and bad software architects of
this project.
There are a lot of other drivers
for four projects or for AI
systems that
has sometimes
a much, much bigger impact on technology
on the system.
So there are political reasons to this
context of persistence by two
people what software projects
fail and do nothing and big corporations
or organizations may be the
hat in the industrial.
Some case of big software projects,
which had a great architecture
and they are not that type and successful
like commercial project
works that are
not so good architecture.
So if you are a political
actor, you might want to know
what was behind, of course.
So before we continue,
let's first codify
the term software architecture
because people use it a lot.
Of course, when I talk about software, I
should take to one thing it could mean
it's an engineering sites.
So the other uses of some
of the terms of architecture
are usually you what?
You want to end up the decisive
definition about us, and
this is quite to the point.
This is a software architecture
is about the fundamental concepts or
properties of the system,
which is embodied in its element.
How does how its decomposed
into components and building blocks?
How they relate to each other?
How do you relate to the environment?
So this is a prospective, still
a proximal health also.
But then the second part is important
that the principle of its design
and evolution is what are the rules?
What other constraints do you use
to decompose the building blocks?
But what are the rules you apply
to communication and relationship to
those building blocks?
The other meaning of.
Software architecture
is, of course, what you will, and it
isn't so on the
set of software architecture is
so set of design decisions
which was made incorrectly may cause
your project to be canceled.
So it's of.
At the end of the day, when we
talk about software architecture
of software architecture, it's
just a property of choice.
I choose this system just
hasn't. I should take.
It's not a description of its
intended to sign
on, and it's not
probably should not be some
treated, but it should not be some
upfront signed by some
enterprise. I should take it or someone
will chose to.
How to write code, how to run software.
This is not what I should take truths
about just a property of a system.
So the problem is
you can choose to ignore it,
but that's totally fine.
If you have reasons to ignore us, you
can choose, but you
cannot tell us, nor I should take.
You always have an architecture, and if
you don't care about the architecture
of the system you create, it
takes the pros of it on it.
If you don't actively shape it or
you have to deal with the results
of trust to design decisions, then
it takes just any form and
you have to defend it.
And this can become
very, very nasty at the end.
The longer the project goes through, you
all know those at the beginning of each
project. Everything thing is easy.
Everything is beautiful.
You have a screen for you to build
things.
But the more releases you have,
the more difficult becomes changed.
And this is a real problem.
If you don't care about you, I should
take to you. I should take should help
you with this.
So
let's let's take a super, super
oversimplified examples for this.
You want to make
light up your express who want to have
more things, more shining lights and so
on. So and if this is just
a project of just something cheap
you throw away after several months or
after the party is over you
or if you just want to learn,
do you know and programing
or architecture might
not be that relevant for you,
just go to scrapbooks,
just take away and start your auto, you
know, idea or choose any
of the existing open source projects
that can light up entities and.
You know, you can be totally fine with
this, but what happens of
dissociates escalates into
something bigger?
Let's imagine you want to light up the
whole building or you want to light up
the assembly at the next tempo.
Something like this that you have not
won any stripes, but or
100 or more.
Or if it turns into something
like an open source project that rules
for dealing with those altitudes
Typekit like they learned
from a cookie or something like that,
which is a really, really nice project to
do. If you just want to have lights who
don't have to hack it yourself anymore,
who just can install it on
your year's PGA.
So.
But oh,
isn't it?
If that's what you do that
for to transcend to something
like such a project which
evolves over years, which is
chaired for by a community of developers,
and that
short run that different kind
of leads that different
user extensions and so on.
Then then it's time to think about what I
should do.
So as we have already said,
you just have an architecture.
Your system just exhibits
some architecture.
It is just there.
And what you want to do is
you want to be to you, give
it the form. You want to give the tools
to want it to be a good architecture,
whatever this means
now and also a good architecture
in one idea or introduced it
helps you cope with change comes on
the problem. You have a tent,
each hacking project
transistors.
Right now, when you develop stuff, you
have to make some design decisions,
and those design positions
can be very, very fundamental.
For instance, programing
paradigm or what programing language
to choose to use the inside
or use of platform
I, what technology to
use so that it's run
on the rest of the pie on USPTO,
should it run on an
older Arduino or
something like this and
the next closest, you have to make it
even more difficult and complicated
to have to decompose
your system into manageable,
isolated building blocks,
you have to give it the structure you
have to find in this component.
To divide it and hold those components
should depend on each other.
Of singles flopped
on.
What you work
that right now is
a set of requirements
that is far from complete, you
only know some of the requirements
you, for instance, want to say
yes if you want to have at least
five different ready strikes and
with each one hundred and eddies and
the short term nice fading effects
and you know, some
of the quality requirements,
but not all of the system, this is what
for you to take your own pocket.
Think about your own prejudices for
ethical, ethical of it.
A very, very abstract, very, very
malleable idea of
requirements and constraints.
There are some industries out there that
all the requirements are there at the
beginning, but this is true for most
of our quota, usually not the case, and
it's definitely not the case.
If you do just a hacking
project on making projects
for, the next thing is
to have to work for some assumptions
about the future.
You have to make decisions based
on things you don't know yet
and what it makes even more complicated.
When it is a long term project,
you do not only have to think about
your AI system itself
those requirements, but also about
the process of developing a business
or something that can spend
months or years and usually
large I.T. projects in company
develop over 10 or 15 years
of. And that's just a lot of time.
And this development process
puts additional constraints on
your on the development of your AI
system that
in many, many cases, not technical.
You are not allowed to choose the best
engineering solutions.
So you are a good engineer and you
want to build
the best ready light out there, but you
do not have any time to do it or
you do not have resources to do it,
or you do not have the skills you.
You just have to learn
to just plus or something like this who
just start learning to work for the
original idea and your
development team, the other people
of hackers and Macon's to
contribute to your project.
You don't know what what
they are good at and how they are
available and if they do commit
to recruit trekked for the
next coming months or years, especially
an open source project commitment,
a difficult thing that requires
you to onboard people
just because they like
to do it.
And this this is completely different
from our company works.
And the next problem is this
is a moving target.
All those changes over time in
the time span for your project over
several years, a lot of things can
change. People change old
requirements and constraints, change
the technology's change
over time.
All those changes in the end,
you somehow want to
manage this and still want to
come out with a of good architecture, and
this is the difficult part and such
projects.
So this leads us to
two major question Question one
What really is a good architecture?
Or at least I should make sure that it's
good enough for your needs.
And the second question is
how can we make design the solutions
that can solve them in good
architecture, folks who are coachable
and doing this without big upfront
design because you don't know the future
if you don't know the future and can
foresee it.
You just have to hope that change.
Somehow, you have no major crystal
balls that tells you what to.
Requirements will be several
months or years.
So let's go to the first
question what really is a good idea?
And then you hear the answer
the phone software.
I should take the tell you and
nobody really like it depends.
It depends, is always a good answer to
software architect because it really
depends. And the really good software I
should take will tell you what it depends
on, and it depends on your
goals and objectives.
So is it just a fun project
or do you want to really light
up the next fusion and want to use
it over the next year and
so on? And that is no
good or bad.
She take it out of taking
the context into account
and by context, I do not own
the media.
Requirements on your system by context
also mean your
development process.
What skillset skillset to you have,
how much time do you have, how much money
do you have whole skill to develop versus
what your experience?
That such systems and so on,
and only if you take this context
into account, you can come up with
an architecture that really sets a neat.
So if you talk about
a good architecture in general,
the short one thing, what
it should provide to us to help
you minimize the resources
or to build your
system and to maintain
your system. The second part people often
forget they only think about building the
system as fast as possible.
But if your system developed
over several years, the maintenance of
your system keeping it up to date,
keeping it up to changing requirements
is to be a difficult part.
And this is also the part we don't know
about. This is something that still
happens in the future.
We don't know of the
certain libraries you choose
to vote for. It are still available in
two years or something bad happens
like for block for day.
That turns out to be a major issue
and you have to update your system.
So then the next thing a good I
should take a shot to
Earth and humans
to understand a system that is
probably one of the biggest issue
in systems design and systems
engineering that
our systems became increasingly
complex.
The great phrase Hopper once said
before World War Two, when
everything was easy after that
we had systems, though, and
the complexity of our AI systems
are now so big that it's
really a limiting factor for
humans to understand how they work and
how to change them, or how to
implement new features or how to
adapt to changing
requirements.
This is why your
architecture should help you in this
process. That means at least you have a
meaningful division and separable
components to contain complexity,
and you want to have some means
of abstraction.
You don't want to think about every
detail of every and each subsystem.
If you want to change something, you want
decoupled instance.
And of course, you want to do it because
I should take to help you to cope
with changes which also happen
in the future and provide
new guidelines toward your design
decisions.
And the problem you have with those
to sign decisions is
they are not necessarily
rational design decisions or rational
decision or something.
There you can vary all your
options to find out everything you need
and then choose the best options
you have. And this doesn't
happen very, very often that
I should take to design decisions.
They are so-called bounded rational
decisions because you have limited
information available.
You only know some of the things that
a lot of what you call
each of uses.
I know it when I see it, if you ask
someone how it's how the system should
be. That said, I don't really
know or just build it, and I tell you,
if it's like this, I know it.
When I see it as the usual thing, we have
to give it.
So but you also have limited time
to make the decision because if you
do not make it within the next two
days or so on, you lose a lot of time in
your program and you have
a limited cognitive capability
to do this multidimensional
optimization.
So how do we come up?
What is a good thing to come up with
good design decisions that lead
us to a good I should picture?
So how to come up with a good I picture?
And step number one,
shoot all this or
try to be sure about
your requirements and the system context
if you don't know what
to what drives to what tries
to discussions, what was important to
you, then you cannot do
really good.
Design the system because of design
decisions are always a trade off, so you
have to sacrifice something
for something else.
And if you do not know your goals and
constraints and what is the most
valuable thing for you?
And I'd like should do.
You cannot make a good design
decision.
And the other thing is about
requirements and constraints and
contexts. They often have the best
by date.
If you do not fulfill the requirement
of connecting all the
maps and the acid free vote
at these two day, then
your environment becomes pointless.
So you have to know how your requirements
change and how stable are.
So if you ask someone to see you or she
really needs it, then
it can say, Guess someone told me,
I really need this feature, I want to
have it. But it turns out it's
not the thing or just really interested
in what makes money, but just
because he or she has just been told
that everyone needs to.
So you should know.
What are your goals for Georgia
influencing factors to
show how important they are
until stable?
How they will at least make an assumption
about how did it change over
time? And one, especially
in this kind of requirements or quality
requirements because of
its functional requirements change.
This is something we can cope with
in our everyday life is
normal. Somehow, more or less,
if the quality requirements of your
system changes since you are alleged, you
should not provide on
TV and frequency of 1000
hertz and not only of 200
hertz. For some reason, this can
be a major problem because this
might change the whole system and
you might have to redesign the system
completely.
So you should really watch out
that you have the most important
quality requirements on your radar and
find out how good
your system should do things.
What how stable it should
be. How maintainable, how changeable.
Because all the change in one of those
quality requirements can mean
that your system design becomes
obsolete and will come have to come up
the whole new architecture to cover for
it and
to not let this happen.
One good thing or to
Virg incremental
do not try to
fix everything at once at
the start of your project, but a
big upfront, the scientist usually
doesn't work. You don't know everything
in the beginning.
Use iterations use small
steps to improve your picture,
so it's OK.
You should have some course idea
how your eye should take should look like
some guidance.
If you don't have some guidance, you
cannot do design decisions,
but you have to prepare.
Prepare for it to change.
And what your architecture should
enable you is somehow
to cope with those changes.
And one important thing that
you are able to do is that, you
know your tradeoffs.
This
is a I think
my questions are going to trim
everything and I should take a job
as a tradeoff.
So and
also the corollary to this is,
if you nice, take
on something that is not a trade off, you
just have discovered the tradeoffs
behind that.
So to make good design decisions,
you have to find out which components
of your system are somehow connected,
how they are coupled to each other.
And if I change one
component or the requirements for
one component, how does it
impact the other components?
This component is two, and
even if you take such a simple example,
like our LG lights that,
oh, it is such a lot of tradeoffs and the
real big project is this
even though, for instance, we could
decide.
So you have to design decision to use
software power to support
a lot of these stripes or to use hardware
pavilion, which has a lower load
of defeating us a few.
So, so you cannot have some
features, you have no stripes on, you
want to have a higher
frequency to don't have
to also tell us
those those things.
Then you move your eyes.
But the higher your PBM frequency,
the more electronics problem you get,
and the lower is so dynamic range
you cannot have very, very low
steps between the brightness of
your stripes and don't.
That's considered about such
optimizations between frame rates.
And then you want to have a very high
frame rate to have animations.
You have a very high load on the systems
who might have dropouts.
You might not be able to synchronize
it. For instance, if you want to load the
stage shredders and switch the light and
you want all the lights to switch at one.
And this is sometimes
this is absolutely a tradeoff
to have to have a high frame rate, to
have a really synchronous.
And don't let's get started about
features and about quality attributes.
For instance, do you want to have some
nice the update to have
it maintainable about not having
to go to each of these lights
or to change
or from there?
But this has a lot of security
implications.
Do you want her to have something in
your network like this?
So also to lose a lot
of memory, to enable or update
and so on and everything
in your design position as a trade
off and what you should do is identify
what you trade against, what
are a quality of feature
or or attribute
options system.
This is something you should.
Playing out in the open, make them
visible.
And the good thing to do is, for
instance, choosing I should take the
decision because you should make your
trade offs because these tradeoffs
are not visible in the code you write.
They are just usually just in
your documentation.
So next thing, you
have to cope with change and to be able
to transfer evolve, you have to identify
the things that are really, really
hard to change.
And those what those
are depend on your specific
project or system, but usually
hard to change of things like
programing paradigms.
If you choose functional or imperative
programing or your programing language,
it's difficult to change it later and
you have to rewrite everything or
the platform you choose or the middle
there or some of the library.
Is it true? Sometimes it's very, very
difficult and change them.
Or if your system provides
some public API to understand
a lot of other components, a lot of other
users to use, then
on assistance to you will stand those
things. Transient or sense always
comes quite at a cost.
You can decouple from
those changes just because
it's totally impossible.
But even decoupling brings
to additional complexity in your system,
and complexity is what really
might your project because you must only
have a small amount of cream and can
only have so much complexity.
So how would you
like to it? What do I do
when things start?
How to change change anyway?
Unit sales, or Fightful Strategy
for it, basically
has a set of small tools that do
exactly one thing well,
and they communicate through a standard
protocol. So they are very,
very nice decoupled, which means
if we offer you small
Unix tools can be changed
really bit by bit, no pun intended.
So it's already
talked a bit about cutting the users
a lot, and
that's an important concept to have.
So what does this cutting
company mean?
So there is some kind of
dependency between your components.
When you change one component, it
might probably have implications
to other components.
So as a programmer, you know
about cutting a lot as I asked
and trainings about cutting.
Usually, people come up with Kupperman
by call. If you want to call
not a component or something of
a method of an object, you are coupled
to this.
They are covered by a
data or data structures and methods,
signatures and so on.
If you use a common database,
for instance, all common data type
and one of those is changed.
Then you have to look
out to other components were also used
as a stick and code for the change.
This is something most programing
languages or a lot of modern
programing languages just take care for
you, type, safety and so on.
But not all programing languages, too.
So you might want to watch out for the
content of our data as
text or as dreazen that are
adjacent, but all the JS and schema.
And then one component changes
all of the what in those
days and file and suddenly your
application.
This was a sign that you are a couple of
wired data.
Also, what programmers use it is
no, they are covered by inheritance,
inheritance between classes.
It's a very, very strong kind of coupling
both, but a lot of other
modes of comfort, and this list
is by far completely
not complete.
But of course, we might be covered
by the fact that two components have to
run on the same system on the same
virtual machines
to some components have to create
other components.
It's also some kind of coupling or, you
know, the coupling via a
time that you rely
on something happening before
you can do something.
And this is something that is
usually not visible, visible in your
code.
Modern programing languages provide
constructs for us to make it easier
to handle. So some of these
things, but you cannot handle
all those two things. And that might also
thinks you're a company by which
you don't have any representation
in your code at all.
Like, for instance, all your components
need to be deployed at the same time
because you have you are layered
monoliths, you have strong dependencies
and you have to
have.
To implement fix, to leave state so
that everyone can chisel her
changes onto your project so that
you can make a new deployment so
you can decouple or to
short decouple
as good as it gets of what what you
really want is not to have that
much coupling between your components
because it makes changing your system
difficult and that makes thinking about
your system political and
you have a lot of ripple effects when you
change something.
But even loose coupling
is a tradeoff. If you couple something,
Lucy, it usually it's more
complex to your system.
It's overhead to a system.
So and you shouldn't really
know when to decouple
the. And you have to
have coupling in your system you cannot
get rid of.
You have to structure it somehow.
So what you want to do is
you want to sign to be
prepared for changes but
limit the impact of changes,
limit the ripple effect and
reduce unwanted complexity.
And softer architecture
provides you with a lot of the same
principles that helped you do this.
Some of them, most of you already
know they are so common sense that
you just grew up with them.
Like information hiding most modern
programing languages provide one or
the other means of information.
Hiding or separation of concerns
is something you should definitely choose
those people from object oriented
programing
note a single responsibility
principle which is not quite
the same, but basically the same.
So if you separate your concerns
of your separate functionality,
then you have a looser coupling
between those things.
You have blessed relationships between
this component, a lot of other
things or design principles.
Software architecture has to see if
I could make an own talk
on social Bogdan.
So, so if you want to
have a follow up on this talk, the next
thing for sure only
be about the same principles.
You should definitely look into that.
But one thing
you should notice us you
do not or strive for
the perfect adherence to
this the sun principle.
You should strive not if
you can violate them, because
the thing is, some of these design
principles are really the trade
off in their own.
For instance, every programmer knows
the truth a true to the right principle.
Don't repeat yourself because
the opposite of Cry was swept based
everyone's time but not
adhering to the trite principle.
Hence, duplicate fraud in this system
can be very reversed for you.
Because we can independently develop
this code, you have decoupled the
development you can give it to different
teams. So basically,
if you think about microservices,
microservices violate
right all the time because
you do not want to have into service
communication because it's so expensive.
That's fine. It's a good reason to
violate trade because if you stick to
trade, it may increase or accompanying
the calls. If you do provide
an abstraction for some form, something
you had when you use tried
before and deployed in the sector,
you are suddenly coupled to this
abstraction. And so everything else will
trade off you.
I think you get it.
So we are running a bit
out of time. That's fine.
I don't want to talk that much about
pet them pet on a very important
concept of software.
I should take to
say you don't have to invent,
ask a single cells pet, then provide you.
But we use of those solutions
for software, for your problem that
probably someone else already have.
So and also they provide something
to talk about to give you structure and
terminology are a lot of
good sources for people.
Don't invent your own pattern.
Parents are not inventive.
Parents are discovered, but
look out what patterns you might use.
And there's also a lot more
than just architectural design,
which we have covered in all sorts of
troubleshooting to. The most important
thing is right stuff.
Nobody likes documentation.
Everyone wants documentation,
saves time later on.
But it might not be your time that the
saved. This is a problem.
The documentation.
So but make make it easy for
others to provide documentation.
For instance, you set the template based
documentation, and if you do,
I should take it and you are suddenly in
marketing and politics.
You have to train artists.
You have to convince others
about your solutions.
Talk to other stakeholders
and make it work for them.
So and if it doesn't work,
then do my.
Ida, a serious problem
that what you designed doesn't
fit the needs of your stakeholders
or your team or the people you
work on this project in this
case for Headspace.
Then you should find out what their
needs are and should find out
if your design matches two requirement
and context.
But also a lot of non-technical things
can go wrong, for instance, and
companies, you have to problem that
compliance that harass you
very often the big thing you are
not allowed to do.
Actually, take two calls.
You don't have a certificate or something
like this. This inevitably
leads to road conflicts.
All you have someone that's just
got assigned to to
to. I should take and the
most this person becomes a bottleneck
because you don't do.
I should take it, and you still
doesn't care if he doesn't reach
a high enough level of
abstraction. It's not that you should
become an I should take trust note, but
you need some level of acceptance.
You do everything yourself you cannot do
actually teaching anymore.
So that usually works best.
If you want to make sure I should take
flight and accompany
you on the crew of us or make us,
you should definitely avoid
assigning architectural responsibility
by high ratio to.
I think this also will not happen in our
community.
Our community is quite immune
to that. So but what you
should if you watch it in your company,
look out architectural responsibility
very often very well
exist without expensive titles
of someone being and I should Typekit.
So let trust people grow into
the role. Experienced programmers
usually become architects
themselves. I don't have to teach
them anything anymore.
They do it intuitively,
right? So this is the same
thing. That responsibility
for us to picture comes to those
people who really care about you.
I should try not to you assign to
it. And if you
don't have and I should take show,
it can be shared by
a team.
So this is usually
you. This is totally doable
and development teams that you
can share the role
of the architecture between people
according to their skills.
Just go into a meeting and ask,
who can tell me something about
how the debt,
for instance, over the air updates on
all of our Ali describes so
and who comes up with answers to
kind of explain it?
So this is someone who might
have an I should.
Well,
so our times set up.
I'm sorry and sometimes late, and
we didn't cover
everything really well that I want
to cover. What we covered so far is only
the tough to stick to why it
matters a little bit of what
is good. I should take the and very
basics of architectural design.
There are a lot of more things to talk
about, like how do I
do a good decomposition and
components?
How do I separate concerns
for you? What do I do with cross-cutting
concerns? Documentation told you I find
my influence and practice on Sundays
is all of things that just didn't
fit into those formats.
I'm very, very sorry about this.
But anyway, we are at
the end of this talk and
thank you very, very much for
your time.
Big thanks you for your patience, and
I'm really looking forward for your
feedback and for your questions.
And maybe after the talk, we can also
meet Andy Coulson,
as he wrote, If you have any questions
or this council, or if you have
questions concerning just your project,
I'm very fond of looking
in the architectural problems
you run into to talk about this,
to find out what you
did or what your problems were.
And how do you do you make it work
because of being a good
I should. It means always to learn
something from people who do.
I should correct.
Thank you very much, and
I'm looking forward to
your questions.
So they have a little delay here in the
stream, I think.
No, I think we're on my
dear Harold.
You Shenfield.
Well, here I am.
I mean, I know.
Great.
So we may not have
the time for each and every question
asked, but let's pick out some
of them.
Most important, and of those we'll
get into time, I think goes to the
internet later on.
And yes, of course, I will give
you the I give you all the
answers.
And after the talk,
so softer, our protectors are like
knots and seafaring.
They help. The one who is responsible
for openings are not to
be able to open it as if they'll
that if they are, well, not until he
knows how to hold
the one who threw the knot did it.
So our software architecture is known
and present in the standardization
like it in the Sun?
I saw how you see a Triple E, rf
c and you name it.
And which one is the
standardization organization for software
architecture?
A standardization?
I Triple E cares about
software. I should take truck, but
I took that. He cares about software.
I should take in the sense that it
treats as a subset of system.
I should picture if you look at how
the ISO and I Triple E standards
changed over
the recent years, Devils
studio spectacle still a definition of
software I should take.
So no, there's only a definition
of system I should take, which was
completely OK because of
software I should take to basically
this system. I should take training for
two systems so
I can't talk about other standardization
organizations.
How she takes are involved.
There are organizations
that care about the knowledge
of software architecture.
I don't want to make any
recommendations here, but
out of
there isn't a very, very
active software architecture
community of, um,
in my opinion, very, very clever and
very, very excellent people
here in Germany, Austria and Switzerland
and Europe. And also there are a lot
of outstanding individuals
in other parts of the
world for good offers and who care about
software.
I stick to, but I cannot say
anything about the involvement
or evaded work together with standard or
standardization organizations to trust
the thing.
I know things about that
sponsor somehow or like the grassroots
standardization ripe and the beginnings
of the internet, maybe.
But the problems you have with the
standardization and stuff for some terms
which don't even have the standardization
of people, talk about the interface,
they can talk about the contact between
component, they can talk about the
implementation architecture, can talk
about the interface of as a kind
of abstraction.
So yes, standardization like
the Facebook
or something like just for software
engineering would be good.
I completely agree with that.
So that was
optimal for the next answer.
How does a software architecture interact
with the systems architecture you
mentioned right now?
And how does a software architecture
reach into a DSM to Fuze
like hardware, firmware, licensing and
so on? And how do they communicate in the
optimal case?
So, so those are two questions that I
told the software I should take to
interact with systems I should picture.
Software architecture
is a part of systems architecture.
Then your system has substantial
software parts in it, then your
software. I should take it as a part of
the system. I strongly interact
because you have a lot of dependency,
because quality and capabilities
of the system to build inference
requirements and constraints
of your architecture.
So and it's not only our
entire system I should take to interacts
with other architectures as
well, like information I should take to
all the business architecture
for enterprise and also into
the top I should take to certain
software doesn't work well on
a single threaded process, for instance,
that I saw.
So you want to have some?
I should take true separation
here.
So.
If you can think about softer
as you take two, then you probably are.
We really, really got about can also
think about system.
I should take two and vice versa.
The application domain is a bit different
to have to have more domain knowledge
for systems like structure because you
might have to divert
a or something like this.
So that's just the second part of the
question is how to
involve people to communicate
and the optimal case.
I think that's what the optimum case
like, maybe in the requirements,
documents or whatever
their thing is. What is your optimal
choice of optimal
chase us as the framework
side in the end,
what what your optimal case depends
on the resources to
have the distribution of your team
and so on.
It's probably a
good or in the past we
had a separation of concerns
by teams.
You had teams that were responsible
for hardware.
You had teams that were responsible for
front end and people or something
developers, backend developers and so
on.
This usually doesn't work.
It can work. But
what works better is to have
cross-functional teams to
involve other stakeholders
in your decision making to
a certain point.
You cannot have them all in your
decision, but
it also has to do with
Congress law because the
system you the structure of your system,
of the system, your built,
but the logic of
the structure of the system you build.
This also defined by
the structure of your development,
this happens inevitably.
So if you have a strong separation
between those teams, then
through automatically your
system develops an interface
on the boundary of your team, which
is how to change would cause
a lot of effort to change.
So
if you want to have optimal
communication between,
let's say, systems architect
and software actually to
then point a
show, right, a lot of documentation,
but before divide a lot of documentation,
they should talk with each other and find
out what information the other
stakeholders needs and
what the tradeoffs of explain
their tradeoffs to the.
So one big
elephant in the room, I
think coming out of the coming
architectural patterns is that everybody
should know.
I'm b we had
a.
This is really a big elephant,
and this is not a new distraction.
Six minutes for that elephant
is humongous elephant.
The thing is,
what pattern you
need depends on the system
you built and on what level
you operate.
You should as a developer,
you should definitely know,
have the gang of four
to design patterns laying around
because it helps who there's
a lot of implementation
and the same problems
and coding deficiencies.
Architectural patterns really
depend on what type of system you're
built in the software
agitator community.
You had a lot of discussion that
threatens to include in our curriculum.
And what we ended
up with was taking out most of
the pet on safety because
if we want one, we came up with
a list of 30 patents or something.
And most of these patents
didn't work for the other
people training I should take.
And so what we
kept doing what there.
I think layers, microservices,
pipes and filters.
And some folks one
does this idea of the must have
done but must know only because
they are relevant for for
for for the training, not because they
are really relevant for the person
using them in practice.
So what the what
I can offer, the person who had this
question is that you meet up later on and
find out what kind of systems
he or she looks on and what patterns
might be relevant to pose a little
literature issue.
So, for instance, distributed
into different looks
depending on
what kind of software you build.
For instance, if you have a distributed
system, then you usually have other
patterns and then you have a monolithic
system and you have a very, very
system that's very close to your heart
that, well,
maybe we understand that's right now.
Is there any literature that
should read? And I think that's almost
our last question to ask for a
next part.
Maybe next time,
OK, recommending literature
of it's a bit difficult
if I should only recommend
one
book.
If you have only a few
good books on, I should take
if if it's a German speaking person,
I would recommend
one book by going on strike.
For instance,
if it's for the English community,
the most modern and most comprehensive,
and the latest and most by
my good trips. And you thought you
fundamentals of software architecture and
engineering approach, which is from
2020, but just fired up to
date and if
efficiency talks of Richard and
Ford. They always were at the time, they
you do my stuff.
They also did a new book Just Here
on modern trade off analysis,
which I didn't read,
but I went to the workshop
they had for this book before it
went out. And this is more for
those people, the distributed systems
for things about service oriented
architecture. So it might not apply
to people coming from all
embedded systems and so on.
But the fundamentals of software
structure was quite good.
Simon Brown has a good folks of
software architecture for developers.
There are sensitive.
Books are good.
Of course, they are a bit older, like
Boss Clements and Kazman.
They are also a bit older,
those folks. But this should
get you covered and the most important
and to any good.
Also, I didn't mention jokes.
It's really difficult to comment
on cookbooks, although
stepping on anyone's toes.