Options for modeling solutions using the C4 DSL?

[mawid6]

I am working on a POC for implementing C4 DSL at our department. I have found the extensive docs, examples and discussions found around these parts interesting and inspiring.

I have started on a list of "challenges" to solve - where the first one was to decide on a setup/convention for sharing elements (mainly systems - common, external and from internal library-teams) across all department teams/products. For simplicity, we will sacrifice some dev/arch devexperience and force "library" teams to declare all shared elements in one file that is then aggregated into a department workspace which all teams will extend in their workspaces - to get all common elements, including their own.
But on to the topic at hand and the background to my question, the second challenge I am thinking about is:

The "business solution" "level", which I am trying to conjure up options for handling.
Essentially "multi software-system solutions".
What is it? Many "products" are composed of several independently deployable and manageable software systems. We often call this grouping a (business) solution. This entity maps to a support budget, configuration in support products, channels, etc. A business solution may be composed of 3rd party systems and internal products. The products may be developed by one or several teams working together to deliver the solution ( for example a backoffice system which supplies data specific to a product, etc). When introducing people to our architecture, we start out on this high level and then we go down into the product they will be working with - often not going further down in any of the other systems, atleast to start. OK, I suspect you know what I mean here, so:

My question:

How would you suggest that we model this business solutions level using the C4 approach and toolset?

Options I can think of:

• Plain C4 solution, meaning to "skip it" and just use groups. This will mean we cannot identify the elements, nor create a high level landscape view using those elements - and sync with other metadata systems (the EA system catalogues) that we have, and that we will not achieve the goal of having "all" relevant architecture in the C4 model that each team is responsible for. I mean, ideally, most of the important metadata we manage or link to from the C4 data that lives in the repos of each team and it is their responsibility to update and deploy the updates so that other systems are updated.
• Parallell C4 model for this level: Everyone gets a separate model ( e g [product]-solutiondesc.dsl or something) that are then merged into one workspace for the department as part of the build. We could perhaps import the software systems catalogue.dsl and somehow express the composition dependencies solution -> softw.sys.
• Parallell C4 model in the model, use filters. Similar to above really, but solution software systems get their special tag and are filtered out from most views - details of this approach to be explored, if I decide to explore it... Benefit is one model perhaps, but it seems more cluttered... hmm...

So any tips, comments, ideas or hints appreciated.