well i suppose i should say good morning but I'm from the east coast and so my
body's craving lunch at the moment so good morning doesn't seem kind of
appropriate and I'm talking about architecture and this is kind of an odd
thing
gross the the reason I'm up here talking is because the organizers said we'd like
you to talk about software architecture in 10 minutes
ok but architect has always been an awkward slightly awkward thing for me
I don't really like the term software architecture because it's someone's up
these images of some senior person in an organization who is setting rules and
standards the hell software should be written but haven't actually written any
software for maybe 10 or 20 years and these architects else polski used the
term architecture astronauts often caused a lot of problems for software
projects and so the whole term architect and architecture has that kind of nasty
taste to it and this is particularly something that what we need to change
his industry because the way we write code is important when we have that
opening little thing at the beginning of the show you see little bits of software
code put in there because that's because the open source community has always
believed code is important but if you're going to be a technical person you have
to be someone who's familiar and comfortable with the reactive
programming and of course there has been for quite a while in architecture
particularly this notion that architecture is going to beyond
programming and if you're an architect you shouldn't be programming anymore and
that's something the life I've always thought it was very wrong
but that meant only raises the question well well what really is
architecture what does the even the word mean in the software context because
because we're borrowing the term from buildings and construction and where we
actually means something completely different and i won't go into all of
that if you want to come up with some kind of official definition of what
architecture should be
this is probably the closest you might get I travel the software standard and
that kind of definition has been around for a while but when I think of what
architecture ought to mean on does mean I actually think of a reaction to a
statement like that and that was made by this guy and then how many of you
recognize him
this is ralph johnson and probably best known as one of the office of the design
patterns the Ganga for book
he's also and and work by people like him has been a major trigger for my
career in the sense that it was his students that originally and formalized
notion of refactoring that and actually wrote the very first refactoring tools
so I've nicked a lot of stuff from Ralph and his his folks over the time and he
would be sent an email once that was a reaction to that definition of
architecture and I liked it so much for ended up stealing it completely and this
column on architecture that i wrote over 10 years ago for our trevally software
basically takes the entire email and pads it out a bit to be the column you
can find it if you if you want to hunt around for it and he makes it he took
this definition and said the problem with this stuff definition is it
it relies on this notion of somehow what are the highest level most critical
important components a lot of the earlier versions of this talk about the
highest level concerns in something and he said but what does that mean how do
you select which components
what relationships are important is obviously a gazillion components and and
relationships in a product
what matters to make some of them architectural some of them not
in his view he said that well what really matters here is that if you go to
a reasonably healthy software project and you talked to the expert developers
on that project the people who most capable who are most familiar with a
code base they will have some common understanding of how the thing works and
it's that common understanding that is effectively architecture and this is
important because it is also a brings out the fact that architecture is very
much a social thing it is that fuzzy embedded understanding that really
matters
and yet there may be diagrams here and there they might be documents here in
there and there may have architecture written on them but they're just a
representation and usually in perfect representation of that shared
understanding what you're trying to do with a software project particularly a
software projects grow is you want to make sure you have a good shared
understanding between the people who were leading the project that's really
what matters but that definition
although it's very common there's another one that's also quite important
which you also see which is saying that architecture should be the decisions you
need to make early on and Ralph also was able to poke a hole in that one he said
well really it's what you wish you could get right early on because the point is
the decisions you might need to make early you don't have the information you
only learn about what the software product should be structured like as
you're building it and what it really boils down to is you concerned about the
decisions are hard to change and that is actually a quite useful way of thinking
about architecture what is hard to change and he does lead to some
different and forth learn what are the bank components and how do they fit
together because programming language
the choice of programming language is a decision that's hard to change but it
isn't usually considered what are the top level components
so having gonna have taken these two routes he then continues by saying well
really we've got two things here
shared understanding and hard to change but they actually boiled down to
really what in his view and and I'm echoing it because it in my view to is
the definition of architecture
and I hear all of the laughter right because that sounds like an almost silly
statement the important stuff right whatever that happens to be but actually
I think it's a very profound statement it says that if you're trying to think
about your software system and what its architecture is what you them first
thing you have to do is you have to figure out well what is important
what do we as the lead the technical leadership of a project consider to be
the most important things in there or even our solar project
what is the key things about this I'm system
what is the most important thing in the code base that I have to keep at the top
of my head when I'm working on it
that decision about what is important is really the key thing that goes on and
that is really the thing that trumps everything else so that if people ask me
what my definition of architecture it is
I follow Ralph illness and I say it's the important stuff that talks about
what
architecture is the next thing I want to look at is another question which is
well why should we care about software architecture
why easy as important as you know to have me come along then undo a 10 minute
talk about it and really the finger triggers that is something like this
that you hear from time to time
so how many people have heard something like this on the software project that
they've been working on . this kind of line
you know we need to sort of don't worry so much about modularity in these design
ideas we gotta crank out features and the reaction of a lot of people to this
is they get frustrated and they try to argue in terms of what we we've got to
do a decent job of software professionals we gotta move stand up to
our professional standards
it's almost like taking a moral response to this and saying what software
architecture is important for moral reasons we need to do a good job
we need to be craftsman unfortunately my view is that if you take that line
you've lost as soon as you start track pacing that argument you lose because
what you're doing is you're
making a battle between craftsmanship and economics economics always wins
and if you wanted to say well why is architecture important you have to
instead cast in economic terms
the problem with this argument this argument up here is it's got a notion of
what is quality based on an idea of equality something i can trade off the
cost
we do this all the time when we buy things when we buy cars when you buy
clothes we do this trade-off in quality and cost but quality in software means a
whole bunch of different things and the point is that some of these things I an
external person a user manager customer they can see them but some of them they
can't
so whether your software has a good architecture a good modular design or
whatever
that's not something that's visible and so I think of it as saying well we've
got two forms of quality here that this external not internal and architecture
is about internal quality and the thing about internal quality is it is not
directly visible if somebody offers me a software product product with great
quality the costs a hundred dollars more than software that does exactly the same
thing but has poor internal quality
what's my motivation to pick the great quality one moment i'm going to pay a
hundred dollars more for something that does the same thing i'm going to go for
the poor internal quality surely but what matters in terms of internal
quality is more of a long-term picture and I have this rather convoluted
statement that tries to sum this up i call it the design stamina a hypothesis
horrible long-term I know but it's tries to capture this and I do it but plotting
this pseudo graph of the functionality of the software over time as it grows
and he about don't pay attention to design and architecture during the
project
you get a curve that looks something like this but as time goes on every time
you want to add new features it seems to get harder and harder and harder because
the existing code based kind of slows you down as you add more stuff
how many people have been on a software project that feels like that
pretty much everybody that's a big reaction but it doesn't necessarily have
to be that way if you've got a good architecture and you pay attention to
keeping it healthy and refactoring regularly and making sure that the
software code base stays clean
you can get a different experience we're not just as that slow down attenuated
you can even reverse it and feel that I can build new features faster and faster
because the software is already nicely component I just need to make a change
here in a change fair
it's easy to find where to make the changes and I can accelerate because the
software its existing the existing code base is a platform that I can build up
and go faster
how many people have had that experience on the software project less hands but
this place still quite a few of them
I ask this question every time I give this talk i always get that same result
lots of hands of the first less but still enough for the second
what we want is at second case and that is why software architecture is
important because yes
if i buy the product that's a hundred dollars cheaper and has low internal
quality
I win at the moment but what will happen is that the better internal quality
software will be able to make new features more and more rapidly and soon
the slow on can't keep up anymore and we can probably think of cases competitive
cases where we've seen this happen where a product that looked like it's
dominating has been it up being eaten away over time and that's particularly
relevant now as we push more and more towards continuous delivery continuous
deployment features updated over the internet all the time that degree of
being able to respond to change becomes important and that's the economic reason
why software architecture is important
because if we don't keep good architecture if we don't put that effort
on internal quality
we are in the end deceiving that customers of in fact stealing from our
customers because we're slowing down their ability to compete and that
crossover line
we're good design counts even in the short term happens remarkably quickly
it happened when I talk to people about how long its weeks not months so that's
the what and the why of architecture
i would like to talk about how but I have 19 18 seconds left so unfortunately
that's going to be tricky but fortunately the whole track at this
conference talking about the house of software architecture
so I'm going to delegate all of that to them and i hope you'll enjoy listening
to them
