💃 Throw Some C4 at Your Salesforce Org!🕺

Good morning, Salesforce Nerds! Honest question ... how's your diagramming game? 🤔 Are you able to communicate a clear picture of your system and its components? Does the room fill with groans anytime you pull up one of your diagrams? We got you! Today we check out how to communicate the ✅ right level of information to the ✅ right people at the ✅ right time with the C4 Model!

Agenda for today includes

• Foundations

• C4 Model

• Daily Principle

• All the Memes

Foundations

First things first - the C4 model is an approach to diagramming that aims to help tech teams describe & communicate software architecture and functionality. It's a way to create visualizations of your org at varying levels of detail - kind of the same way you would use something like Google Maps to zoom in and out of an area you are interested in. 🤯

What does that really mean? Sounds kind of complex. It's actually not though. Here's how it breaks down. There are four levels of C4 diagrams, each one potentially for a different audience and containing a different level of detail. These are the Context, Container, Components, and Code diagrams. Let's look more into the details of each level.

C4 Model

🗺️Context | Level 1 - See the big picture

These are the most high-level description of what your system does, who will use it, and what other systems it will interact with. A context diagram helps describe the scope of a project and the what problem you're trying to solve is.

Picture your system as a box in the center of a diagram, surrounded by its users and any other systems that it interacts with. Details are not important here so keep it high-level. Keep the focus on systems & people.

Intended audience: Tech and non-tech people inside and outside of the team.

🏛️Container | Level 2 - Understand the high-level shape of the architecture

This diagram takes the first step into describing the inner workings of a system. It begins to list details like the applications, APIs, databases, and services that the system will use. But not too many. We're effectively zooming in to a system that was defined within the Context diagram.

Each of these applications or services is represented with its own "Container" and the interactions between them are shown. Now, the high-level shape of the systems architecture and how responsibilities are distributed across it begins to form.

Intended audience: Developers, admins, architects, operational staff

📦Component | Level 3 - Identify building blocks and their interactions

This diagram shows how a Container is made up of a number of Components, what each of those Components are, their responsibilities and the technology/implementation details. Here we're able to detail groups of functionality/code that exist within a single Container to even greater granularity.

We're here to look for in-depth details about a particular Components within the system. So, details on specific operations is supports (i.e. user login flow, commission calculations, integration details, etc.), how data flows within, how data is formatted and what its interaction with other components looks like.

Intended audience: Developers, admins, architects.

🏗️ Code | Level 4 - Drill into the implementation details

Finally, we arrive at the last level. This diagram shows the details behind how the Code of a single Component is implemented. This can be considered an optional level of detail reserved for the most business critical or complex Components. Best case, these diagrams can be auto-generated using an IDE, UML, or ERD tool).

Intended audience: Developers, architects.

There you have it! A framework and methodology for creating technical diagrams that will ensure you're documenting your system from each angle you need! If you're interested in more, check out this Salesforce Architects resource about How to Build Salesforce Diagrams.

Daily Principle

and now....Your Daily Memes