Architectural repository based on GitLab and C4 Model for a large company - Kirill Vetchinkin - ArchDays 2022 (Category Architecture)

Interesting. report Kirill on the topic of an architectural repository for a medium-sized company, in which Kirill spoke about the implementation of architectural processes with the growth of the company. Main thoughts: With the growth of the company, it is necessary to formalize the design processes This formalization in a small company can be done centrally and for this you can act trying to go to the approaches of Arch as Code, which in the version of Kirill is based on the following approaches and tools:

• Usage plantuml chart (In fact, it's diagrams as a code.) I love this tool for creating diagrams. It allows you to describe the C4 Model and UML diagrams. Use Markdown to create documentation (From markdown, you can generate any necessary variations of documentation in Pipeline steps: site, pdf, ...) Use of Gitlab and TBD - proper markdown documentation and plantuml diagram descriptions lie in the code (Hence the name Arch as a Code.)
• Archreview process looks like a review of changes in the architectural description and getting applications from the right guys: staff engineers, infra, security, etc.

Then Kirill interestingly talks about what their architectural repository looks like, which is tied to the use of subdomains from the strategic patterns of DDD and C4 Model for hierarchical display of the system architecture at different levels of abstraction. Interestingly, Simon Brown, the creator of the C4 Model, made his tool for modeling architecture - structurizr, where you first describe the model of the system, and then you can do different views for different purposes. (more specifically in my post)

As a result, the architectural repository of Kirill has the structure of the species.

• Domains -- Subdomains --- Teams ---- Services Kirill goes on to explain how all this machinery works, like how common components are set up, how teams describe their services, and so on. And then he goes on to describe how ADRs are written and revised in this architectural repository. (architecture decision records). In fact, when creating a new service, an init ADR is created, in which there is 3 piece Description of problem
• Link to the event storming (about which I've been told earlier)
• Description of the decision Plus, the main diagrams are attached:
• Container diagram
• Component diagram
• ERD diagram
• Use case diagram With further ADRs, when the system changes, the reasons for the changes are described + diagrams with diff was-steel are attached, and the original diagrams are updated. It all goes through a review that has an SLA on the speed of a review. (It is alleged that the SLA is exhibited in 2 day). After appruv, it's all marred into a repository.

In general, I think this approach might work well on the scale of a few hundred people. But there’s a problem with this approach – the reality of architecture exists alongside the code, as diagrams are drawn by individuals in a single turnip, and code is written by others elsewhere. How close these different realities are is a big question. But I wouldn’t call this approach architecture as a code, but rather architecture documentation as a code:) But this is already a big step up from the way companies usually manage architecture, so if you don’t have anything, try implementing something similar.

#SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment #DistributedSystems