Architectural diagrams and metadata generation – Kirill Vetchinkin – E-community 2023 (Category Architecture)

Interesting. report from Kirill, in which he continues the theme of the architectural repository, which he lift up on ArchDays 2022. This sequel deals with how to make architectural diagrams relevant and the main points of the report are the following: Kirill begins by posing the problem of irrelevant schemes and highlights 4 moment: In an irrelevant scheme it is impossible to make decisions Low confidence in an irrelevant scheme among all participants in the development process It is difficult to analyze the state of the system for those who need to do it. (auditors, participants in the development process) Such schemes do not help during operations - technical support and SRE can not use them effectively To solve the problem, we create an architectural repository, where C4 Model and DDD approaches describe our services (The components that make up our system). And the list of components should be maintained centrally so that we can uniquely identify and reuse them within our circuits. In order for the architectural repository to be updated automatically, we need to link to our configuration data about our services: Description of the service - in Sber Market it is app.toml (configuration TOML). By the way, the data from this file is used to replenish the service catalog, which is used for description in the Archrepo. Service configuration and dependencies - this values.yaml file is used to deploit services in production, so it contains current parameters or the service simply will not work as intended in the sale. Well, for architecture, you can use files from different services, you can build a dependency graph for services. Description of the database - in Sber Market it is structure.sql, which contains a database schema and can be used to compile ER diagrams.

As a result, the construction of architectural diagrams looks like this:

• Read files app.toml, values.yaml, structure.sql Converting data from files to object models Building a relationship graph for different services Rendering diagrams for all services - inside the service there are ER-diagrams, as well as container diagrams, on which both the services we knock on and those that go to us are pulled up. (They are pulled from the values.yaml consumers)
• Preservation of the scheme
• Display diagram

In general, this approach seems to me to be the right move toward architecture, like code. Use of standard tuling for architectural documentation Information about services and their relationships is not filled with hands, but drawn from the system, which is the source of truth and determines how our services are deposited in reality. Tests to control the architectural integrity that are raced in pipelines are rolled over. (Fitness functions from Building evolutionary architecture)

P.S. On the subject of architecture management, there have recently been several posts that are also interesting to read.

• Architecture as Code - Roman Piontic - ArchDays 2022
• Architectural repository based on GitLab and C4 Model for a large company - Kirill Vetchinkin - ArchDays 2022
• Architecture at T-Bank: How we design our solutions
• Since architecture is code, why not test it?
• We conduct an architectural review of product features
• Experience of using the "Architecture as a Code" approach in Airplane Group - Roman Piontic, Valentin Kozlov - ArchDays 2023

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