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?
_____________________________________________________
🔗 LINKS:
Stefan Tilkov – “Good Enough Architecture” ➡️
Martin Fowler – “What is SW Architecture” ➡️
The “-ilities” from ISO ➡️
Intel Security Flaw ➡️
_____________________________________________________
📚 BOOKS:
🚨 📖 Dave’s NEW BOOK “Modern Software Engineering” is now available here ➡️
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.
📖 “Continuous Delivery Pipelines” by Dave Farley
paperback ➡️
ebook version ➡️
📖 The original, award-winning “Continuous Delivery” book by Dave Farley and Jez Humble ➡️
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
————————————————————————————-
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley’s courses
➡️
📧 JOIN CD MAIL LIST 📧
Keep up to date with the latest discussions, free “How To…” guides, events, online courses and exclusive offers. ➡️
————————————————————————————-
CHANNEL SPONSORS:
Linode offers Linux virtual machines with global infrastructure and simple capped pricing. No surprise bills, no lock-in, and the same price across every data center. See if Linode works for you with a $100 60-day credit by signing up HERE ➡️
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️
Nicely done. Thank you.
is the the book "Modern Software Engineering" good for beginner programmers?
last 5 minutes in your video was so impactful to me
💻🚀✨
I agree with you to enhance security of the web app at the end of the development.
As a Junior software engineer who's just starting his career, I appreciate your contents. This will help shape my career and the e way I see software development
When is a distributed monolith a good choice?
Dave, i greatly appreciate your content. Your calm, grounded pragmatism and the experience it shows are genuinely helpful to my day to day work. Thank you for sharing!
Iterative software design. You are right. You can start doing a monolith design for a simple application and as business requirements evolve, so it does the architecuture the application Is built upon. Software architecture design Will heavily rely on business requirements as it evolves.
Dude, I call this "distributed monolith" a "microlith". you should help me spread the new term… it's awesome. you said it was good in some cases? I would be interested in hearing your thoughts on it as I found that these microliths usually are worse then monoliths or microservices…. I had not tried to come up with how they might be good!
I think s/w architecture is a useful set of components that has be put together in a very explicit way, to solve a particular non trivial software problem.
Hey Dave! What do you think about the concepts of „ETL process“ and „API-Gateway“. Maybe you can make one or two videos about those. IMHO both are some kind of anti-pattern.
Another great video. Binge watching your videos today. "It is a snap shot of the shared understanding…." best definition of architecture I've heard. Agreed…good design often requires an iterative approach enabled by good architecture. Progressive refinement vs no design. Design change requires roadmaps and change management planning.
Such a great well condenced talk. Thank you.
great talk on architecture and design fpr software development. My take aways:
– keep in mind that it is an evolutionary process
– engage every developer
– have a rough design as early as possible
– make first guess based on your understanding and use this as basis of your further experience
– check whether your architecture fits the need of the system
– approach: incremental design
– don't try to have too precised architecture.
This one was really special Dave
I love this take. It boils down to don't
over think it. Often all we have to go on are informative guesses of what our stakeholders truly want, in time we learn more as we start peeling away the layers. Use the tools we have to try and make good decisions. It's very easy to feel overwhelmed in the fledgling stages of designing a system. Very often 1st 2nd and even 3rd iterations aren't 100% right. It's good to be aware of the entire system but try and keep scope lean it'll help to keep yourself and the team focussed. I've worked on pieces of software that have gone through multiple stages of redesign and or rework because we had put ourselves in a corner or just made it so complex in the early stages of design that it became almost unmaintainable.
nothing interesting
☝️and that's why I decided to learn software development – for that seam part! Creating within and without constraints until this begots that. Thank you for confirming my decision to become a software developer at 49 years old was my best move yet – Much love from New Orleans ❤️
For me being Agile in software development is a myth, you need to slow down, specially on early stages, to be fast. Common sense, simplicity and maintainability are not typical discussion in planning. Most projects now are designed to be cv/resume centric. Methodology and tools becomes the primary focus, and not what needs to be solved or delivered.
If you will check the Agile Manifesto, its a fail early and fail frequently in early stages. Most we could do ar the start is to assume things. But it's a different story if we don't verify our assumption or make corrections on wrong assumptions. Management will not allow you to throw away some sprints because you made some wrong assumptions. The tendency is to sweep things under the rug. But to old dogs like me, mistakes are normal and actually welcomed early on.
In summary, as always a good architecture is the one that properly solves the customer's problem.
The biggest issue right now with Software Architecture is the internet. Its too easy for someone to read something and say "this is the right way to go" without even thinking about consequences. I've been in teams that right from the gecko the software already had tons of concepts, different technologies, different patterns, etc… And the complexity to even start messing around with the system was gigantic and the only thing the system was doing was presenting a couple of simple CRUD meaning a complete overkill. Also most developers / software architecture do not think about costs. For them having 10 different technologies and dozens of patterns is ok because it makes sense for them, but the consequence is that it limits the amount of recruitment / experience of the potential recruitments.
Dave! You did it again… this content is pure gold. I will be chipping pieces off out of the video to include in my presentations. 🤓😜
You say "What do they mean" and "to be fair to Wikipedia" as if 'they' are somebody else.
Wikipedia is ours, created by us. Dave, Nicholas, some other people too.
You should be saying "what do we mean" and "to be fair to us".
Very interesting topic, too often I hear 'I'm the architect so you have to do it like this…' not giving any ability or safety to the development team to try things. What I like is when and architecture team are acting as guides, having visibility into the wider strategy or roadmap to ensure that the individual parts that the teams are working on will fit into the wider long term application and avoid wasted work or create more work later on
Dave, great video: thank you! What do you think of architectures such as the Hexagonal Architecture, Onion Architecture, or Clean Architecture? Do you think they help approaching architecture in a more disciplined way? Do you think these architectures are more broadly applicable?
@5:32 beautiful. Getting it wrong means we learn and get it right … paraphrase but you get the gist…
11:40, I use to think the general flow of data as a simple thing. But in practice, some ugly measures have to be done. Splitting classes to keep data security, more layers of data access to become clear, and so on. All things that I rather not do, but technically I feel compeling to.
People discuss how much inheritance can mess things up, but I don't use to have such issues: I start with a simple thing, focused on what I need now, and throughout time I come back to make little upgrades. It's a kind of "become forced by practice" motto.
13:15, there's a problem in multithread, called "false sharing": each time a process read a cache line (32 or 64 bytes), it blocks to all other threads the access to that line (those bytes). To solve this: put data from each thread in different cache lines.
17:20, someone said, in a recent presentation: "Classes work as black boxes: we put things there and forget about it" . I appreciate this in design: the less 1 needs to keep in mind, the easier it will be to upgrade the architecture.
Loving your book, very inspiring and educative. Thanks for the hard work.
Great content. I want to agree with your views on flexibility in the system architecture solution.
My group is working on migrating hundreds of applications from legacy on-premises to the cloud. So we are not dealing with much uncertainty as to the feature set.
And we still find ourselves rethinking and tweaking the architecture on many occasions.
I like your books, but I don't agree with your definition of architecture when you just say evolutionary.
Let us make a system that runs on the cloud and we start with EJB3 and evolve from there?
You still gave a developer-centric or confined approach.
This has caused mayhem in the software world.
A developer can't ever work with business people, and he is just happy with the system working on his desktop.
Architecture to be evolutionary is a thought, and before that many design decision has to be made, including Event-driven, ETL, and pipeline.
Much has to be there as a process for, computing, network, database, security and right provider has to be understood and documented.
Your definition is pretty dangerous as it tells us to run blindfolded just like a headless chicken.
@Dave: can we get an affiliate link to the US Amazon store for the book? I looked it up myself but without the affiliation, that doesn't do you much good!
Theory/Architecture of software is CRAP without solid definition and proof of these terms: Module, Program, Source-code, Intermediate-code, Runnable-code.
This is why I always recommend this channel…
Thank you very much!
No amount of evolution will make a bridge out of Swiss cheese.
In some Projects, you are architectually extremely limited, by an „architecture“ that was intended by nobody in the team. It comes from some ridiculously badly implemented classes that are used everywhere and nobody feels responsible to get it out of the way. And there are guys in the team who have lost years of their life to maintain this. They protect this bad structure.
Some good concepts in this video Dave but the one thing missing for me is "Requirements". Software Architecture isn't guess work, it is always based on the client requirements, which obviously can change and hence why architecture should be an agile process.