What Software Architecture Should Look Like • Dave Farley • GOTO 2022

We’re so pleased to announce that we’ve teamed up with Dave Farley, author of “Continuous Delivery” and frequent GOTO Conferences speaker, for a monthly video series featuring ideas about continuous delivery, DevOps, test-driven development, BDD, software engineering and software development in general.
Find plenty more from Dave on his Continuous Delivery UA-cam channel: / @continuousdelivery
Dave Farley - Continuous Delivery & DevOps Pioneer, Award-winning Author, Founder & Director of Continuous Delivery Ltd.
ABSTRACT
What is Software Architecture? It’s a surprisingly difficult question to answer. We can describe software architecture patterns and argue about what is the best software architecture, but in reality, most definitions are vague enough to be unhelpful or so over the top to be more like a list of everything that you need to think about when building software. Popular descriptions of what software architects do often focus on checklists of architectural qualities, which can help us remember things we may otherwise forget, but don’t really tell us what the job is for and how to do it well.
In this episode, Dave Farley author of Continuous Delivery and Modern Software Engineering gives his take on what software architecture is, why it matters and how it is important for all of us to understand and use. The design of the systems that we create is important, in sustaining our ability to make change, and for them to meet their needs. There is no one-size-fits-all in software architecture, microservices is probably too big a cost for many teams that choose it for example. The architecture of our system, that shared understanding that helps, or hinders, our ability to make progress matters, so how do we choose the right architecture for the job?
CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
bit.ly/DFTraining
RECOMMENDED BOOKS
You can grab Dave Farley's new book 'Continuous Delivery Pipelines' here:
leanpub.com/cd-pipelines
Dave Farley & Jez Humble • Continuous Delivery • amzn.to/3ocIHwd
David Farley • Modern Software Engineering • amzn.to/3GI468M
/ gotocon
/ goto-
/ gotoconferences
#GOTOxDaveFarley #Programming #SoftwareArchitecture #CD #ContinuousIntegration #DevOps #DaveFarley #GOTO #GOTOcon #ContinuousDelivery
DAVE'S LINKS
www.continuous-delivery.co.uk
/ davefarley77
www.davefarley.net
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
ua-cam.com/users/GotoConf...

[@FranciscoTena]

You are my Carl Sagan in the Software space. Thanks for sharing your thoughts!

[@coolY2k]

Interesting comment. But, I don’t think computer science has a great science communicator like Carl Sagan, Richard Feynman etc.

[@dinoscheidt]

16:53 love that quote

[@conalmckeever9368]

Good clear thinking David. Like it

[@frailas]

Couldn't agree more, that architecture has to be evolutionary process.
I liked the 2nd, updated definition, that architecture is a snapshot of shared understanding that the expert developers have of the system design.
I even want to expand on it by saying, that "time" is the most important factor. Maybe at the moment your monolith application is "perfect", with team of 3 developers and 100 users using it. Once your application scales to 30 developers with 3 teams and 10000 of users, situation might be different.
I don't agree with the first Ralf Johnson definition though: - It's the stuff we wished we could get right at the start of the project.
It implies that we made mistakes in the beginning, but architecture is a moving target, whether it's good or bad might largely depend on if you evaluate it "yesterday", "now" or "tomorrow".
A good software architect should be in constant pursuit for perfection, but always behind the target. You should be able to say, that it's GOOD for CURRENT situation, and it is nearly PERFECT for YESTERDAY`s situation. For instance, it's OK to start with monolith and see how far you can go, but you should always be aware of your constraints and try to address them before they start becoming problematic.
And all these *ilities is not something that drives architecture design, but rather it's something that must be maintained all the time in order to have a working project that is able to evolve.

[@Bosslogq]

Nothing wrong with monolith, specificallt modular monolith which follows DDD in terms of contexts. This way we can start with single app without of the all overhead of microservices and if we scale up we can split whichever module we need into separate app and team. The hardest part is defining the contexts itself and to keep them loosly coupled.

[@ovidiuc4]

Some real world examples on how the theory was applied would help.

[@sabarinathrajendran3954]

Who can do a code review on vscode source code to explain its plugin architecture to the people

[@matthiasg30]

I can do it for Eclipse's Plugin System 😉

[@bbs32]

lol, what do you want to call those NFR?

[@m13v2]

here, from 0:55 to 1:55, jim coplien shows how to recognise a software architect: ua-cam.com/video/3txy_maxtk8/v-deo.html

[@dogaarmangil]

Interesting points. Caveat: 14:32 ❝if you are Netflix or Amazon, [then microservices are] fantastic. If you are a small dev. shop […] it's almost certainly overkill.❞ 💬Not necessarily: if microservices are provided by 3rd parties, then they will be useful regardless of company size. Buying is generally more cost-effective than building it yourself.