Visualising software architecture with the C4 model - Simon Brown, Agile on the Beach 2019
ฝัง
- เผยแพร่เมื่อ 16 พ.ค. 2024
- In Simon Brown's talk at AOTB 2019 he explores the visual communication of software architecture based upon a decade of Simon’s experiences working with software development teams large and small across the globe.
He looks at what is commonplace today, the importance of creating a shared vocabulary, diagram notation, and the value of creating a lightweight model to describe your software system using the “C4 model”, which he created as a way to help software development teams describe and communicate software architecture, both during up-front design sessions and when retrospectively documenting an existing codebase.
It’s very likely that the majority of the software architecture diagrams you’ve seen are a confused mess of boxes and lines. Following the publication of the Manifesto for Agile Software Development in 2001, teams have abandoned UML, discarded the concept of modelling and instead place a heavy reliance on conversations centered around incoherent whiteboard diagrams or shallow “Marketecture” diagrams created with Visio. Moving fast and being Agile requires good communication, yet software development teams struggle with this fundamental skill. A good set of software architecture diagrams are priceless for aligning a team around a shared vision and for getting new-joiners productive fast.
Visit www.agileonthebeach.com for more information about the premier annual Agile conference.
BIOGRAPHY
Simon is an independent consultant specialising in software architecture, and the author of “Software Architecture for Developers” (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He is also the creator of the C4 software architecture model, which is a simple approach for creating maps of your code. Simon is a regular speaker at international software development conferences, travelling the world to help organisations visualise and document their software architecture. - วิทยาศาสตร์และเทคโนโลยี
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.
What a lovely presentation! Sat through the whole thing easily.
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!
Great presso! Amazing summary of C4 modelling and recommended best practices.
Really enjoyed this. I found my self using old school UML to still describe an architecture. This video really helped refine my approach!
Exactly what I'm looking for. Thanks a lot
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)!
Still awesome in 2024! What a great presentation and explanation to break down such a complex ways of communication into simple process.
Great Talk. Wonderful tool for High Level Abstraction. Paints the big picture very clearly.
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"?
Very clear presentation. Thanks for uploading this!
One of the best presentation not just in terms of delivery and content, but also impact🎉
Great talk, straight to the point
Excellent Presentation. Thank you
Straight and to the point, great to see it's being taught to more people.
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
This is awesome. Wish I saw this talk earlier!
Thanks Simon, great video.
This teacher makes learning fun.
so good presentation
This really clears up amny things,thank you.
I would very much like to see the diagram from the lecture.
Interesting model. Great Talk
Watching in 2022 and this is amazing.
Very good and straight forward intro to c4 thanks for sharing
Great walkthrough!!
Great! Excellent content and presentation skills!
Really great presentation!
LOVED!!!!!
Quite informative, thanks!
Great. I must try this
awesome speech! speaks a lot as itself... 1+
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.
Very helpful!
that's very useful video. Super thanks
Simple ,Fantastic & Excellent
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?
Thanks! It`s a very interesting lection!
Great demo. You can also use Miro boards, if you don't want your sticky notes fall off.
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
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.
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
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.
really cool, thnx!
thanks!
Thanks.
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.
what's the advantage of using C4 over uml ?
UML is C++ of architecture design.
I use OmniGraffle mostly and it's perfectly fine.
good themes
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.
Nice talk, but the conference template is an unfortunate waste of screen real estate.
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.
One major problem is that his software-architectural floorplan diagram is actually brilliant.
Great stuff - time to get rid of Visio - great comment ...
what a rare intelligence
So C3
Whoa Martin Freeman is looking great these days
34:37
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
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.
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
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.
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.
The bite-sized throat bacteriologically flash because move disappointedly rot excluding a loving helicopter. protective, insidious use
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.
You were very late in coming to the point and you were explaining things which were not relevent
Knowfa Mallity. Did nobody get the joke?