Jeremy Stafford
I agree. The C4 model has this concept accounted for but it's a supplementary diagram that's not part of any particular layer. I think right now you have to use groups but then you start to muddy up the simplicity of the layer 2 diagram which could have a couterproductive effect to different audiences.
My two and half ideas are:
1a. Add display layers that allow you to overlay visual elements. For example, I'd have a layer toggle called 'Deployment View' that would overlay groups that I construct. The challenge here is the UX. If you modify something on a different layer, then other layers will not adjust with it like they currectly do. So maybe...
1b. Instead of approaching layers like you would in Lucid chart, maybe you can assign elements to a "layer" which really just acts as a flag that would toggle the visibility of those elements. This might actually be useful in other scenarios.
- Introduce a more general concept of "supplementary diagrams" that can be attached to any of the major icepanel entities (systems, apps, components, etc). It could just be unconstrained diagram that you link to that entity and maybe it just shows another icon (like the magnifying glass, or step out icon we have today) that indicates there's a supplementary diagram (or more than one) attached. So in this case, for example, you'd attach a deployment diagram to the FooBar system or app and go to town. At least that way, it's not in your face unless you ask for it.
R
Ralf S.
Our company needs the ability to map several (different) deployment situations / diagrams. Unfortunately, this is the reason why we are not (yet) using IcePanel.
E
Edwin Goddard
Do you know if this is going to make it onto the roadmap? It seems to be the most voted for idea that isn't currently in progress
B
Brett Dudo
I feel like this veers too much away from C4, doesn't it?
Kevin Greene
Brett Dudo I wouldn't say so, it'd just be IcePanel encompassing the ability to model one of the three supplementary diagrams - https://c4model.com/diagrams/deployment
Jacob Shadbolt
Kevin Greene: Agree. You can already technically do this with the use of groups. The main things missing are 1) groups assigned to groups (for different levels of deployment detail) and 2) multiple instances of an object.
D
Dennis Cohn
Jacob Shadbolt, while groups can be used to visualize deployment nodes (and the relationship to its containers), there are no dedicated element for diagramming Infrastructure Nodes (such as load balancers, proxy servers, etc.).
The other problem with using groups (in terms of the ordering of objects in the model object repository) is that they end up appearing in the repository as level 0 elements (such as actors and systems) instead of level 1 elements (such as containers).
Jacob Shadbolt
Dennis Cohn: Interesting. Why do you think a group can't represent a load balancer or Proxy server?
I agree with the second point, I guess really they want to be shown as deployment groups within each system, so a system owns that group as opposed to level 1 (Context) being owned by the domain.
D
Dennis Cohn
Jacob Shadbolt: I would recommend having a separate element for groups due to the need to be able to differentiate between "Groups" that could be created to group containers, components, or deployment nodes that will have related behavior versus their use to represent infrastructure elements.
Using the same visual element for both situations can cause confusion both when browsing the object repository and when reviewing the created diagrams.
Garik Hakopian
We can't do this with context/containers?
Tim Gaweco
Garik Hakopian it's possible. We recommend creating a separate diagram (in L2 usually) to represent deployment information specifically. You can either use Groups and/or Tags for deployment attributes.