One of the best presentations I've seen so far. Not boring at all. Not reading the power point slides. Simple bullet points. Amazing presentation. Interesting topic. Amazing content. Big applause to Simon Brown
We loved the C4 model, and this video helped us understand it in more detail, right from the author. We will soon be supporting C4 inside Archipeg, too. Seems to be a very promising metamodel for architecture. Thanks for this amazing video!
27:11 from my experience the hardest decision to be made when modelling C4. Both stories are very important, true and even necessary. Omitting kafka as a box: you don't see kafka needs to be deployed as a stand-alone thing. You don't see the dependencies at a glance. In some cases the diagram might get very complex, when many components talk to each other instead to a single box. Any suggestions?
@@adelyawn indeed, thats what I mean. From a theoretical point of view its the same like when alice and bob communicate with each other. You could draw a line between them. It would be correct. You could also draw a line to some cloud in between or some routers etc (okay somehow out of scope C4). However, proxies, brokers etc are deployable units and a layer below alice and bob. If you draw a line between them you see the purpose better. Through the middleware, you see the architecture better, but the purpose is lost. As of you need both to understand the system, I tend to draw 1 line through all 3 entities to have the purpose and the high level architecture at a glance. Multiple diagrams or multiple lines with seperate descriptions would make more confusion in most cases imho. Do you have another approach?
Nice Presentation! I always struggle what the Architect is trying to convey using the boxes and lines, a lot of hidden details even in a well organized (not documented) diagram. The Architectural diagrams are very valuable resources and C4 will definitely help to make the Architecture models self explanatory (hopefully)!
I honestly think if universities around the world taught this first - and *then* UML - software teams (and engineering teams generally) would start to have saner (read: actually valuable) documentation within the next 10 years. After a decade-and-a-half of secular software engineering experience, I've only just discovered the C4 model. It's done more for my career than half of my formal education. Without hesitation I would say to anyone reading this: *start here*. Start with the C4 model. And stick with it until you have reason to break from it. And do your next employer/team a favour: pass this message on.
nice mr simon brown, you are inspired us to create content about software architect for our college in UINSA, thanks a lot #amflearning #amflearningbydoing #amfedukasi #amfedukasiforeveryone
I used to be the person that you talk about "Just use a whiteboard" and use those diagrams to talk around. However, it doesn't hurt to have a simple, common notation. UML always felt too detailed and more applicable to application design rather than architecture.
Great talk... except... Where is the "workspace.dsl" file for this talk? That would be incredibly useful to have as a reference! Attempting to find a tutorial on writing this DSL file is extremely frustrating.
Interesting topic - definetly worth a try. Just one nitpick: Wouldn't it be better to call it C3 model because, as mentioned in the talk, one shouldn't do necessarily code diagrams? I feel C3 model would convey the idea more clearly. What do you think?
AFAIK Calling it C3 would lead to more confusion with the already existing C3 tool (which you probably know if you've done Exploratory Data Analysis and visualisations). SC3 might or SC2 might have been more accurate for the model IMO.
Code diagrams are great. But usually you should do them on demand and if possible auto-generated. Also, giving the component level diagrams you should be able to determine the code artifacts quickly. So yes, level 4 in C4 is only some set of recommendations. But it also borrows UML or other helpful notations on that level, instead of reinventing the wheel. That also means, I'd explicitly label such a diagram as "c4 code diagram", even though it might be UML. Just to make its relationship with the other diagrams obvious.
what about the file and directory structure? Robert Martin talks about that. Although I think he did server side programming which is a lot easier than programming where you have to keep track of state. It's almost like maybe other languages should copy server side programming so you don't have to keep track of state. However I think Javascript got rid of that so that you have to keep track of state without concurrency. We need some criteria by which to choose good design. Design should make it easier to add features, easier to fix, it should allow the software to run faster. It should be more secure. it should be easier to fix by third parties. It should be easier to add features to by third parties. It should be as small as possible. It should be compatible with the most systems. There may be more requirements. There will be specific requirements. How can it's design serve those requirements?
AWS diagrams are excellent for Deployment Diagrams. You immediately see AZs, regions which are extremely important to understand limitations (e.g. SPOF). I don't think C4 is good for Deployment diagram. At least with PlantUml, where alignment options are quite limited.
through level 4 in the trash :) lol....i remember long long time ago...we use to use a tool to autogenerate "class diagrams"..i don't think that is a thing now days.
“UML notation is too complicated” Yes, I see that when design a DB. Merise, yep, the oldie, is easier to understand for an audience. Even devs. I reckon UML tried to be a jack of all trades making it….. a tad over complicated in some cases.
Simon took his argument one step too far and is very incorrect when he referenced the AWS/Azure symbol diagrams as pointless. Those diagrams are very useful summary to practitioners that are fluent in the symbology. If you're not fluent in the symbols, you're not the right audience. The symbology diagrams would compliment an L3 diagram and provide a helpful, service specific summary. Audience targeting is a fundamental rule in a communications - know your audience and label your diagramming accordingly. It is not always a choice between A -or- B.
My experience suggests that the number of people fluent in the various AWS/Azure icons is actually quite small ... especially with the rate that AWS releases new services. That's why I recommend "icons supplement text, not replace it". Here's a blog post I wrote about cloud architecture diagrams: dev.to/simonbrown/cloud-architecture-diagrams-3pbm
Am I crazy or did he end up basically with the same diagram structure as all the previous teams... There was really nothing special in his approach other than layering which is not a new concept.
The key concept here is that it's not supposed to be innovative, but to help clean up the mind mapping mess that drive people insane while trying to use those previous innovative approaches. It's about the abstractions made throughout the process (he emphasized the term "abstraction first" in the video), not the final result.
unfortunately yes, I was excited at first but got disappointed at the end. If those teams in the workshop he mentioned used C4 they will end up rating each other's diagrams as 7/10. I don't see a concrete representation of the "abstraction" here.
C4 model Context = System (but Context is fine too) Container = Component Component = Module Code = Code I guess the weird naming, is to be able to call it C4 instead of SCMC
Just an FYI: Acronyms by definition are pronounce-able abbreviations. Just say abbreviation if you mean abbreviation. (sure, "up for debate" wise arses can go speak their gibberish while other people try to maintain a consistent, comprehensible language where all words with individual meanings don't just become synonyms of one another)
I think you searched for English grammar architecture and ended up in Agile Modeling, since the only thing that you could point out from the talking was his use of the word Acronyms...
This can't get any more dishonest. Examples for bad modelling carefully chosen to include obvious works in progress, general ideas or helicopter views, with crossed out names, written on wrinkled paper. You spent no time to try to explain those, yet you've spent quite a bit to explain what you have modeled in C4, even though it was supposed to be so clear. And you've done multiple levels of presentation of your design and did not compare those to any other techniques. Absolutely nothing new here, just promoting old design under a new name.
One of the best presentations I've seen so far. Not boring at all. Not reading the power point slides. Simple bullet points. Amazing presentation. Interesting topic. Amazing content. Big applause to Simon Brown
Those are my words too. Excelent presentation.
Still awesome in 2024! What a great presentation and explanation to break down such a complex ways of communication into simple process.
What a lovely presentation! Sat through the whole thing easily.
One of the best presentation not just in terms of delivery and content, but also impact🎉
We loved the C4 model, and this video helped us understand it in more detail, right from the author. We will soon be supporting C4 inside Archipeg, too. Seems to be a very promising metamodel for architecture. Thanks for this amazing video!
Best video I have seen on drawing architecture diagrams. I'm glad I'm not the only one that looks at others diagrams and say "what"?
27:11 from my experience the hardest decision to be made when modelling C4. Both stories are very important, true and even necessary. Omitting kafka as a box: you don't see kafka needs to be deployed as a stand-alone thing. You don't see the dependencies at a glance. In some cases the diagram might get very complex, when many components talk to each other instead to a single box. Any suggestions?
Yeah. Rearchitect.
@@PaulSebastianM what does it mean?
yeah, I also feel like C4 lacks a concept of a "proxy" for CDNs, event buses, proxy servers etc
@@adelyawn indeed, thats what I mean. From a theoretical point of view its the same like when alice and bob communicate with each other. You could draw a line between them. It would be correct. You could also draw a line to some cloud in between or some routers etc (okay somehow out of scope C4). However, proxies, brokers etc are deployable units and a layer below alice and bob.
If you draw a line between them you see the purpose better. Through the middleware, you see the architecture better, but the purpose is lost.
As of you need both to understand the system, I tend to draw 1 line through all 3 entities to have the purpose and the high level architecture at a glance. Multiple diagrams or multiple lines with seperate descriptions would make more confusion in most cases imho.
Do you have another approach?
@@christians6843 don't have any approaches yet, but I'm 100% with you on this
I found out about C4 thanks to a job interview, and now I am implementing it to design some processes, and I love it.
Watching in 2022 and this is amazing.
Really enjoyed this. I found my self using old school UML to still describe an architecture. This video really helped refine my approach!
Nice Presentation! I always struggle what the Architect is trying to convey using the boxes and lines, a lot of hidden details even in a well organized (not documented) diagram. The Architectural diagrams are very valuable resources and C4 will definitely help to make the Architecture models self explanatory (hopefully)!
I honestly think if universities around the world taught this first - and *then* UML - software teams (and engineering teams generally) would start to have saner (read: actually valuable) documentation within the next 10 years.
After a decade-and-a-half of secular software engineering experience, I've only just discovered the C4 model. It's done more for my career than half of my formal education.
Without hesitation I would say to anyone reading this: *start here*. Start with the C4 model. And stick with it until you have reason to break from it. And do your next employer/team a favour: pass this message on.
This is the best thing for creating diagrams... even after 5 years
Exactly what I'm looking for. Thanks a lot
nice mr simon brown, you are inspired us to create content about software architect for our college in UINSA, thanks a lot #amflearning #amflearningbydoing #amfedukasi #amfedukasiforeveryone
A very detailed and very useful explanation about C4 Model. Thanks.
Great presso! Amazing summary of C4 modelling and recommended best practices.
What a great presentation. Thank you Simon
I used to be the person that you talk about "Just use a whiteboard" and use those diagrams to talk around. However, it doesn't hurt to have a simple, common notation. UML always felt too detailed and more applicable to application design rather than architecture.
UML is C++ of architecture design.
Great demo. You can also use Miro boards, if you don't want your sticky notes fall off.
Great talk... except... Where is the "workspace.dsl" file for this talk? That would be incredibly useful to have as a reference! Attempting to find a tutorial on writing this DSL file is extremely frustrating.
Straight and to the point, great to see it's being taught to more people.
Interesting topic - definetly worth a try.
Just one nitpick: Wouldn't it be better to call it C3 model because, as mentioned in the talk, one shouldn't do necessarily code diagrams? I feel C3 model would convey the idea more clearly. What do you think?
or C3 +1
@@rosey182 or C3++
@@aldosolorzano5734 or just C++
AFAIK Calling it C3 would lead to more confusion with the already existing C3 tool (which you probably know if you've done Exploratory Data Analysis and visualisations).
SC3 might or SC2 might have been more accurate for the model IMO.
Code diagrams are great. But usually you should do them on demand and if possible auto-generated. Also, giving the component level diagrams you should be able to determine the code artifacts quickly.
So yes, level 4 in C4 is only some set of recommendations. But it also borrows UML or other helpful notations on that level, instead of reinventing the wheel.
That also means, I'd explicitly label such a diagram as "c4 code diagram", even though it might be UML. Just to make its relationship with the other diagrams obvious.
This is awesome. Wish I saw this talk earlier!
Great Talk. Wonderful tool for High Level Abstraction. Paints the big picture very clearly.
What is Simon using for the presentation to get this zoom circle and give the rest of the screen a shadow?
This can be done using obs. I don't know though what Simon is using per se
very good points.
On the AWS example with icons, context is king. If you know the cloud, it makes sense and it is actually very helpful
Exactly my thought. Most of the whiteboard examples make sense for all ppl who were attending at the meetings as well?
Great! Excellent content and presentation skills!
@MilanJovanovicTech Hope you can write your next blog around documenting your Modular Monolith with C4 models. :)
what's the advantage of using C4 over uml ?
Very clear presentation. Thanks for uploading this!
This really clears up amny things,thank you.
I would very much like to see the diagram from the lecture.
Excellent Presentation. Thank you
Nice talk, but the conference template is an unfortunate waste of screen real estate.
This teacher makes learning fun.
what about the file and directory structure? Robert Martin talks about that. Although I think he did server side programming which is a lot easier than programming where you have to keep track of state. It's almost like maybe other languages should copy server side programming so you don't have to keep track of state. However I think Javascript got rid of that so that you have to keep track of state without concurrency. We need some criteria by which to choose good design. Design should make it easier to add features, easier to fix, it should allow the software to run faster. It should be more secure. it should be easier to fix by third parties. It should be easier to add features to by third parties. It should be as small as possible. It should be compatible with the most systems. There may be more requirements. There will be specific requirements. How can it's design serve those requirements?
AWS diagrams are excellent for Deployment Diagrams.
You immediately see AZs, regions which are extremely important to understand limitations (e.g. SPOF).
I don't think C4 is good for Deployment diagram. At least with PlantUml, where alignment options are quite limited.
Great walkthrough!!
Really great presentation!
Very good and straight forward intro to c4 thanks for sharing
so good presentation
Great. I must try this
Quite informative, thanks!
that's very useful video. Super thanks
One major problem is that his software-architectural floorplan diagram is actually brilliant.
Thanks Simon, great video.
Great talk, straight to the point
I use OmniGraffle mostly and it's perfectly fine.
For those who came to learn about the C4 model, just jump to 9:30.
Before that he's just mocking someone else's diagram...
That "mocking" serves an important lesson in what not to do - it wouldn't be included otherwise.
Interesting model. Great Talk
LOVED!!!!!
through level 4 in the trash :) lol....i remember long long time ago...we use to use a tool to autogenerate "class diagrams"..i don't think that is a thing now days.
really cool, thnx!
awesome speech! speaks a lot as itself... 1+
Simple ,Fantastic & Excellent
Brilliant
“UML notation is too complicated”
Yes, I see that when design a DB.
Merise, yep, the oldie, is easier to understand for an audience. Even devs.
I reckon UML tried to be a jack of all trades making it….. a tad over complicated in some cases.
Great!
Thanks! It`s a very interesting lection!
Very helpful!
Great stuff - time to get rid of Visio - great comment ...
Thanks.
thanks!
34:37
Whoa Martin Freeman is looking great these days
good themes
what a rare intelligence
9:35
Simon took his argument one step too far and is very incorrect when he referenced the AWS/Azure symbol diagrams as pointless. Those diagrams are very useful summary to practitioners that are fluent in the symbology. If you're not fluent in the symbols, you're not the right audience. The symbology diagrams would compliment an L3 diagram and provide a helpful, service specific summary. Audience targeting is a fundamental rule in a communications - know your audience and label your diagramming accordingly. It is not always a choice between A -or- B.
My experience suggests that the number of people fluent in the various AWS/Azure icons is actually quite small ... especially with the rate that AWS releases new services. That's why I recommend "icons supplement text, not replace it". Here's a blog post I wrote about cloud architecture diagrams: dev.to/simonbrown/cloud-architecture-diagrams-3pbm
So C3
Am I crazy or did he end up basically with the same diagram structure as all the previous teams... There was really nothing special in his approach other than layering which is not a new concept.
No, he explained very well why use c4 model, that's the key of the video.
Exactly, nothing new here. Just separated each layer out to its own diagram
Yep. I listened at 2x speed and still skipped through it manually. Not much here.
The key concept here is that it's not supposed to be innovative, but to help clean up the mind mapping mess that drive people insane while trying to use those previous innovative approaches.
It's about the abstractions made throughout the process (he emphasized the term "abstraction first" in the video), not the final result.
unfortunately yes, I was excited at first but got disappointed at the end. If those teams in the workshop he mentioned used C4 they will end up rating each other's diagrams as 7/10.
I don't see a concrete representation of the "abstraction" here.
C4 model
Context = System (but Context is fine too)
Container = Component
Component = Module
Code = Code
I guess the weird naming, is to be able to call it C4 instead of SCMC
Just an FYI: Acronyms by definition are pronounce-able abbreviations. Just say abbreviation if you mean abbreviation.
(sure, "up for debate" wise arses can go speak their gibberish while other people try to maintain a consistent, comprehensible language where all words with individual meanings don't just become synonyms of one another)
I think you searched for English grammar architecture and ended up in Agile Modeling, since the only thing that you could point out from the talking was his use of the word Acronyms...
@@namaste3089 It's worth saying. Software modelling is more of the same, little to say about that hasn't been said already.
What a bunch of nonesense.
This can't get any more dishonest. Examples for bad modelling carefully chosen to include obvious works in progress, general ideas or helicopter views, with crossed out names, written on wrinkled paper. You spent no time to try to explain those, yet you've spent quite a bit to explain what you have modeled in C4, even though it was supposed to be so clear. And you've done multiple levels of presentation of your design and did not compare those to any other techniques. Absolutely nothing new here, just promoting old design under a new name.
The bite-sized throat bacteriologically flash because move disappointedly rot excluding a loving helicopter. protective, insidious use
You were very late in coming to the point and you were explaining things which were not relevent