We’ve finally done enough poking around this kata to use the C4 model to create some architecture diagrams – first up is the top-level Context Diagram…
This is part of a series of articles about how I use Architecture Kata as a capability building exercise and a recruitment tool at ThoughtWorks.
Here are the previous articles in the series:
All these articles will be focused on the same kata; “I’ll Have the BLT“. I’ve chosen this one because it’s in a domain (retail and food ordering/delivery) that most people have some innate understanding of, from either a consumer and/or employee perspective.
The C4 Model Context Diagram
I have no strong sense of loyalty to the C4 model for these diagrams, but it seems like a popular and pragmatic approach to producing consistent visual descriptions of software. If I’m working on a whiteboard, my default diagram style is everyone’s favourite, the Box And Line Diagram (BALD), but given I have time and software available for these articles, I’m using a C4 extension for VS Code to generate the C4 diagrams from text.
Given we’ve spent time identifying the roles/actors relevant to our system and also created some sequence diagrams showing much of the interaction between these roles, there is very little mental effort required to create the initial C4 Context Diagram (see below).
Even though this diagram is a bit of a mess (this was the best layout option I could use), it does highlight some aspects of my thinking that hadn’t been obvious up until now:
- There is only direct interaction between the system and the (a) Marketing, (b) Customer and (c) Cashier roles. I’ll remove the other human actors in the next version of the diagram.
- Marketing then becomes the only relevant actor within the Parent Company scope… I suspect this will result in separation of components required for promotions and those with more in-store usage in the next diagram.
- Some of the internals within the Store boundary would typically not appear in the Context diagram if we hadn’t gone through the trouble of thinking about the business processes in previous articles. This leaves the Context diagram a little more cluttered than usual.
Which leads to the next version (see below). These changes produce a more typical Context diagram.
Ideally, I would have a diagram with the System larger and more central, but I think it’s sufficient for now.
Public Service Announcement
At this point, I need to unburden myself of something that’s been on my mind since I started this series:
Architecture diagrams are not the same as architecture
Architecture diagrams are perspectives on architecture. The real architecture is only truly present in the actual implementation of the system (i.e., the code itself). In the same way, even if the Sydney Opera House was designed to be a boxy, utilitarian bunker, the true architecture is still the sail-shaped reality with which we’re all familiar.
All we are doing by creating these diagrams is producing low-investment representations of what the architecture might actually be.
With our C4 Context diagram behind us, the next article will see us diving deeper into the implementation of our solution via a Container diagram.
Did you find this article useful/interesting?