After watching this video I went on to read a book about architecture - opened this book named Software Architecture for developers and as I started reading the book then I realized it's a Simon Brown book...what a coincidence. Really good content. Thankyou.
My current company is obsessed with UML diagrams for EVERYTHING and it drives me crazy. Something that I did in education in 90s and it should have stayed there.
"A good software architecture enables agility" this is something I've thought about in the past couple of weeks, and it's lead me to ask the question, "How does our architecture support our way of work?"
I like to add that there is no architecture or architect as higher in hierarchy. Only levels of abstraction or angles of focus. Neither 🦉 nor 🐸 are more important. So focus on solution rather than roles.
Great talk! Recommended to anyone who doesn't have much experience with design :) Especialy with the UML thing, I've met some people who used more UML and it gets very confusing very fast.
UML is just a documentation language using diagrams. I have looked at some UML diagrams where I've walked away thinking "I don't understand this design. I can't see how it works" and that's when you realise that the documentation is poor.
Excellent talk! It reminds me of a very good book I read on a quite regular basis that touches on these subjects many times: Code Complete by Steve McConnell. Really good read!
"You don't need to speak English" - of course not, but if everyone speaks that language it's a good idea, even if it's their second or third language. The problem is, if people just know words but don't understand how to use them properly to create meaningful sentences then poor communication occurs. The same with most people's use of UML.
If you can't understand the boundaries / bounded context, you will suffer in microservices, even if you are writing a monolith which you think you are going to break into micros.
Cost to change is a bad example because something could be super critical and important to a system but fairly cheap to change. Hard to change is a better example
Depends on the design methodology. An OOP architect, for instance, makes every single anal decision for the team that crops up and a million on top of that that are completely unnecessary in the first place. ;-)
Not necessarily. There are object relationship diagrams which do support a design done with objects. I don't give a stuff, I use a mix of everything, from flow charts, to data flow diagrams, state diagrams, to UML sequence diagrams. Use whatever is most effective.
![FNAF vs TF2 - Episode 2 [SFM]](http://i.ytimg.com/vi/z5b3V2-VLb0/mqdefault.jpg)
This is one of the best discussion on software architecture I’ve heard so far
After watching this video I went on to read a book about architecture - opened this book named Software Architecture for developers and as I started reading the book then I realized it's a Simon Brown book...what a coincidence. Really good content. Thankyou.
My current company is obsessed with UML diagrams for EVERYTHING and it drives me crazy. Something that I did in education in 90s and it should have stayed there.
"A good software architecture enables agility" this is something I've thought about in the past couple of weeks, and it's lead me to ask the question, "How does our architecture support our way of work?"
6:04 - “lol I’m two steps ahead of him, I’ll just start with a well-designed, decoupled monolith and then convert it to microservices”
6:31 - “oh”
Great talk! Cheers Simon.
Very good talk. It reveals misconceptions about the subject and delivers good advice
I like to add that there is no architecture or architect as higher in hierarchy.
Only levels of abstraction or angles of focus. Neither 🦉 nor 🐸 are more important. So focus on solution rather than roles.
Good presentation.
Very good presentation.
Thank you!
Flawless.
I like it, it suits my principles: "The software architecture role is about coding coaching and collaboration"
Really great talk! Touches on many important points of software architecture
Good work
Awesome presentation Simon. How architecture affect the Lead Time?
19:56 the storm trooper - 🤣🤣🤣
Great talk!
Recommended to anyone who doesn't have much experience with design :)
Especialy with the UML thing, I've met some people who used more UML and it gets very confusing very fast.
UML is just a documentation language using diagrams.
I have looked at some UML diagrams where I've walked away thinking "I don't understand this design. I can't see how it works" and that's when you realise that the documentation is poor.
@@deang5622 yes exactly!
Excellent talk! It reminds me of a very good book I read on a quite regular basis that touches on these subjects many times: Code Complete by Steve McConnell. Really good read!
very liked, thank you
Great 👍🏻
Thanks!
"You don't need to speak English" - of course not, but if everyone speaks that language it's a good idea, even if it's their second or third language. The problem is, if people just know words but don't understand how to use them properly to create meaningful sentences then poor communication occurs. The same with most people's use of UML.
cool video)
Good talk. I feel that majority of the topics comes from the Craig Larmans book.
One Love MPJ - Fun Fun Function!!!
If you can't understand the boundaries / bounded context, you will suffer in microservices, even if you are writing a monolith which you think you are going to break into micros.
Cost to change is a bad example because something could be super critical and important to a system but fairly cheap to change.
Hard to change is a better example
Risks are subjective? No. What to *do* about them can be and sometimes should be, however. Rest of the talk is excellent, however.
I believe while design once should be able to define macro vs micro decision.
Depends on the design methodology. An OOP architect, for instance, makes every single anal decision for the team that crops up and a million on top of that that are completely unnecessary in the first place. ;-)
goto; Karan Dwivedi
A good architecture enables agility, but this agility would need to be an actual one and not imagined (overgeneralizing for too many cases).
Why did you zoom on a tax heaven ?!
Genial
UML relfects an OO design approach. Hopefully you don't use OO, so you can skip UML too
Not necessarily. There are object relationship diagrams which do support a design done with objects.
I don't give a stuff, I use a mix of everything, from flow charts, to data flow diagrams, state diagrams, to UML sequence diagrams. Use whatever is most effective.
Most software products today use OO based languages.... so what are you hoping for, exactly ?
Software architecture is the equivalent of the evil boss of Dilbert. ;-)
Wow
Did I just watch a product placement video?