it's pretty pragmatic and it emphasizes doing useful things rather than doing things for the
sake of doing things we got quite a few email messages from academics saying could we have
the slides please or we didn't ever write the slides but luckily they kept on using it
security's something that all of your views need to be affected by devops is something everyone
does together. Previously we've heard lots of people say you don't need to write documentation because
you should write self-documenting code, clean code um and there's just
there's been this big kind of anti-documentation movement over the years
folks uh so my name is simon brown i'm an
independent consultant specializing software architecture i'm the author of
a couple of software architecture books joining me today is owen woods who's author of another bunch
of software architecture books uh owen do you want to introduce yourself quickly thanks simon hello
i'm owen woods i'm the cto of a company called in dava and uh simon and i've known each other for a
while one of the reasons being we've both written some software architecture books so i've written a
couple one called software systems architecture with my good friend nick krazanski and one more
recently with murad urder and pierre pereira which is on continuous architecture it's the second of
uh two books on continuous architecture this one's called continuous architecture in practice awesome
and we and we shall get into the title of that book a little bit later on so i i remember reading
certainly the second edition of software systems architecture uh probably when was it released
that 2000 i think was 20 2005. hmm yeah maybe i'm actually getting lost myself yeah it was
it was the last half of the early 2000s wasn't it yeah so i i remember reading that at the time and
that was kind of just after the agile movement came around uh but just on the tail end of the
waterfall rupp uml sort of movement and i remember being a big fan of the book still i'm a big fan of
the book it's on my recommended recommendations list it's a book about two things though right
it's a book about architecture and processes and things and it's a book about documentation
and both of these topics have been let's say shunned over the past decade or two decades
what are your thoughts on that and is the book still relevant for today's audience
that's such a great question yes it was a funny time to be writing the book because it has its
roots right back in the early 2000s when i was working in silicon valley and nick was
working as a an architect in the uk mainly on big finance projects and yeah we were both realizing
definitely waterfall wasn't the answer that had not been the answer for some time and probably
never was rook was quite mainstream but rupp was starting to get sort of almost undermined by a
sort of tools selling process and it was becoming quite waterfall it was going very document centric
and we realized that um really we had to somehow try and write a book that was that was relevant
to people who were going to do a lot of big design upfront as it used to be called but also
we wanted to stress the fact that if you're going to do big design upfront it had to be valuable
and that was something that seemed to seem to me to us seem to be getting lost at that time
people were just producing documents because they were done to produce documents so so that
was really part of the inspiration for the book was um we both believe in capturing things and it
calls it writing stuff down i mean i prefer just capturing because there's all kinds of
ways you capture information it's about having the information but for goodness sake make it valuable
and so i think the book's a little bit uh context dependent it's very much the book of its age
as the world was moving between these two worlds but in terms of more recently
i think we've had this conversation a few times i mean there's a tendency to go agile
i don't write anything down that's not what the manifesto says it's not what any leading
practitioner says it's not what any successful agile team has ever done but somehow it gets
interpreted that way just the same way rock used to be rob's got all these possible documents like
i can write i'm gonna write them all so for some reason people often take a pretty simplistic
view of an approach and unfortunately that doesn't normally end up being successful so i think that's
why the books stay at least somewhat relevant we're still selling copies which is really nice
and people are still referring to it and people start getting value from it because there's a lot
of what's in it actually we had to straddle the two worlds so i hope it's pretty pragmatic and it
emphasizes doing useful things rather than doing things for the sake of doing things it's also used
in a bunch of universities and courses i believe is that right this used quite a lot in academia
that was a great surprise to us we wrote the first edition we had no no ambition at all of reaching
academia completely written for people developing systems every day because that's what we did
and then when the first edition was out we got quite a few email messages from academics saying
could we have the slides please or could we have the worked examples we weren't well we haven't
got either of those why did you think we would and they said well it's really useful for teaching we
use it all the time and the normal protocol is if you want us to use it for teaching you write the
slides or we didn't ever write the slides but luckily they kept on using it and actually now
we still get approaches from master students who are using it as your inspiration for a thesis or
it's being used in some teaching so i think a game is about struggling the two worlds i have
more of an academic background than nick next got a really practical industrial background
and so we were able to bring both of those things to bear so the book these relevant practitioners
were still selling there and they're our primary market but actually lots of academics who want to
prepare students from real industrial work of us of seeing that as a kind of pragmatic text
but it's founded in some quite sound academic principles yeah that's that's really why i look
like and still recommend the book today it's because if you look at some of the uh let's
say older software architecture books uh some of those are very theoretical very dry and very kind
of academic focused uh but your book has that nice mixer too there's lots of theory there but
you also describe how to kind of do it in the real world which i i think at the time it came out that
was something that was really kind of missing uh in in those sorts of texts the subtitle the book
viewpoints and perspectives what's that about yes so that's really where we started we nearly called
the book viewpoints and perspectives and i think we talked to to a professional in the publishing
industry who looked at us with horror and said goodness sake no tell them what the book's about
so viewpoint is really where we started um i discovered this thing called viewpoints when i
was working in silicon valley because i had a real software architecture problem i was working as a
software architect for a new software product line and we needed to describe it we need to write down
the fundamental principles of how it hung together and i like most people started drawing boxes and
lines and put you know i had some information on there and a bit of how we would deploy and a bit
of software structure and nobody really understood it and then i came across this paper the four plus
one paper as it's known by philippe crypt and that really started my personal journey into
some meaningful um kind of relationship with software architecture because phillipe's paper
points out that there isn't one architectural structure there are many architectural structures
he indicated four we actually started there we actually started using those structures nick
and i started using those in our everyday work we came across a few limitations and nick was doing
doing a lot of systems a lot of data in them so he needed an information data type view and
there wasn't one of those and when we when we came to using products and dealing with um software
products that were in operation there was nothing in philippe set to talk to the people in operation
uh the operations group about so so we started extending it a bit
and then as we thought about it a bit more we realized one of the things that software
architects need to obsess about that you talk about a lot in your work too is system qualities
quality attributes so performance and scalability and resilience and security and all those things
and we started thinking about creating a security view and then we'd need a performance view and we
put in here view and so on and our views were exploding and we realized that when we actually
came to do it for real we actually tried this we were duplicating lots and lots of information
between the views and that's when it sort of hit us actually you don't create a view for security
security's something that all of your views need to be affected by so that's why we said
don't create a security view here's the advice on how to think about security in the context
of your other views and so views a view is a way of describing one aspect of a software
system one kind of coherent structure such as its functional structure how you're going to deploy
it how you're going to operate it and so on and they're normally written for one particular group
of people who care the jargon the stakeholders so that's who cares about the functional structure
well not the operations people they really really don't care they care a lot about what's
going to go wrong how to monitor it and how to pick it back off the floor when it's gone
wrong so it's a very different set of concerns so each view addresses some of those people
and then once you've got a candidate system the perspectives are about how you think about these
cross-cutting concerns as we call them like security performance scalability how do you
revisit each of those kinds of structure and think about the impact that meeting that software
quality that quality attribute is going to have on that structure so that's how we came up with
viewpoints and perspectives and be fair to say that viewpoint our set of viewpoints has had
quite a lot of impact it's cited quite a lot perspectives considerably less so some people
quite a lot of people know about perspectives not that many people have picked up the idea
well in the academic literature there are probably two three maybe four new perspectives have been
added by my software architectural researchers yeah it's it's kind of weird isn't it people
if you ask them to think about like a software architecture document template they'll be able to
list out the very sections that they think they might want to cover in their documentation set
but very few people it seems they've heard of something like four plus one which of course
is is the essence of all of their stuff it's let's look at that software system from different angles
one of the big additions you made in addition to your book and i know we've spoken about this
before was the context yes do you want to tell us about that yes well that's that is actually
quite interesting so that was a bit of idealism in the first book um we said well clearly there'll be
people who already have vision for this system and we didn't call them product owners i think we call
them acquirers they're the people who really know what the system's gonna have to do and they'll
probably be business analysts involved it'll be very obvious where the boundary of the system
is and then well we realized after a while that when we look back in our real experience that was
almost never true and when there was some idea about the context it was always wrong because
people haven't actually thought through the technical implications of where the
system boundary was and so when we came to the second edition we just thought no
this isn't credible is it we're going to have to add a context for you because we nearly always
end up doing a context thing it's just we often it's outside the architectural description we
should just include it in the architectural description it's so much neater and cleaner
and if there's something pre-existing well you can always inherit it and evolve it a bit further but
i'm afraid we're just a bit optimistic and kind of ignored practical experience at that point
yeah the number of architecture documents i've read in the past where you kind of get through
the first 10 20 30 pages and it all goes into like very technical details very quickly and you're
kind of left wondering what is this thing and who's using and and why we're actually building
and all of that context is kind of missing so yeah i i really like the way that was embedded into
the uh a few viewpoints and perspectives that you put together that's a great point is that one of
the key things about any deliverable any artifact you create is you need to think about who's going
to use it and what are they going to use it for because otherwise as you suggest you just end
up writing pages and pages and pages that may or may not be of any use to anyone they just become
really sort of technical debt immediately they just become a liability because they become out
of date very quickly or in fact they completely misrepresent how the system really works which
leads me to my next question so one of the things i see a lot of people talk about at the moment
is what should our minimum package of software architecture documentation be what are your
thoughts on that question you know teams who have nothing now and are looking to create
something yeah i think it's terribly context dependent i always start really from who cares
and they've i've basically said the jargon works for that is your stakeholders but they're just
they're the people who care and some people care in a very positive way and they want your system
and they want it to be a success and they tried to cheering you on some people frankly may be at best
rather indifferent as to whether your system is successful or may want it killed at birth because
it's in some way causes them a problem but they're they all have a view and they've all got influence
and i think we're trying to serve those people we some of them are obvious development team
i hope the development organization that the architects in they are very obviously
major stakeholders in an architecture i mean it affects them directly they that they're part of
creating it they're part of part of evolving it um some people like and users are pretty obvious they
maybe don't understand quite how the architecture works but they may need a lot of consideration
during it you've got people like the operations group we talked about infrastructure there's
various groups who may want to know and then there's some people who aren't obvious at all
at least when you start out like compliance in a bank i mean who would have thought you'd have to
have a software architecture view for compliance actually as i discovered many times if you ignore
compliance until the last minute you're just not going live there's no negotiation they don't care
how much money you've spent you're just not going live so actually it's really important
to have some kind of architectural artifact that addresses them so that's where i start is
who cares and in most cases the people who care are the people who have to build it the people
have to operate it and the people who have to um sit in between those two worlds i hate the term
devolves people because i don't think there's any such thing i think devops is something everyone
does together but but think of them as the people who are maybe infrastructure designers application
management experts and so on those groups are probably the minimal set if you can't explain
what the structure of the system is and what are the guiding principles and how to evolve it
if you can't explain where it's going to run how it's going to run what it needs
and if you can't explain how to operate it you're probably in a bad place and then the other group
who don't always want to know but they quite often want to know the people paying for it
so we can't be inquirers you might they might be there the product group those kind of people
then some of them are very hands-off i found about architecture it's really just make magic happen
i trust you but in many cases then of course if something goes wrong then they want to know
why they didn't know so actually the people who are responsible for shaping the funding and the
functional um trained features going into it and who are maybe accountable for the business results
it's important to have some sort of architectural description for them so they understand all the
trade-offs you've made because whether they understand them or really care those trade-offs
actually have a big impact on the potential success of their business so it is important that
something caters to them whether it's unlikely to be the same architecture description that
you and i would like sit with the dev team and kind of debate for hours but they do
need something that explains what those trade-offs are yeah previously we've heard lots of people say
you don't need to write documentation because you should write self-documenting code clean code
and there's there's been this big kind of anti-documentation movement over the years and
i think if there's one benefit potentially that's come out of this covid thing it's that teams have
realized that oh everybody's not in the office anymore they can't have those conversations as
easily as they were before and we've not written anything down so oops maybe we should start doing
something so i think from my perspective that's why i'm seeing a lot more teams figuring out how
do we do documentation so that that kind of brings you back back to my initial question
about how relevant do you think your book is in today's world and i think it's hugely relevant
that's good to hear thank you yes i mean the thing about architecture and code is really interesting
so we have a mutual friend george fairbanks who in his book just enough software architecture
which is aimed very much at teams he talks about this idea of architecturally evident coding and i
mean it's a really simple idea but quite often you don't end up with it and what all george is saying
is if you've got an architectural concept i should be able to go to intellij assuming i'm using java
and search for that name and i should find it and i should find it in the right place with
the right features and functions that you know expect from the whiteboard sketch and that's true
the problem is is that the programming languages we've got today and to some extent the frameworks
they don't actually make the architectural structures very obvious a lot of architecture
by the time you get into the code it's really convention and the problem with convention is
you've got to infer it you can misunderstand it and sometimes people completely ignore it
so that's why even if the architectural descriptions are a little bit idealistic
but it's not always followed and it doesn't quite match i think knowing what the key abstractions in
the head of the person or the people who put it together and actually what how they thought the
system should work that's tremendously valuable five years later when your 500 000 lines have
code in and you need to make a change and you can't really understand why changing one place
seems to have this ripple effect you just didn't understand yeah yeah i totally agree
yeah it's it's um it's super essential and i think a lot of teams have not got to that point yet so
i see uh younger less mature teams from an engineering suspect uh perspective there's
sort of teams to typically shun documentation and and you're right maybe in two three four five
years that they might realize oh perhaps we should have written some stuff down because we've got it
and i guess that's why things are architecture decision records are becoming much more popular
because now we can record that set of uh decisions that ultimately got us got to where we are today
i think that's very much actually how teams if they don't want to produce lots of pictures if
you like on models ideally yeah if you capture your style that you think the thing has as in
what what kind of patterns are you using could you capture your decisions that would be so valuable
in two or three years time the rationale for those decisions yeah it's not a new idea i mean
we've been capturing decisions even checking them into the code for decades but rel at the
game relatively few teams do it and it's really good to see it now becoming quite popular again
subscribe to the go to youtube channel now and join the experts in person or online at
any upcoming go to conference using the promo code book club visit gotopia.tech to learn more
you