Architecture as Code - Roman Piontic - ArchDays 2022 (Category Architecture)

Interesting. speech About Dochub by the author of the ArchDays tool 2022. Up-to-date information on the instrument is located hereBut here I will talk about the main points of the report: The main idea was to create a tool to cover all stages of the company’s development, from a startup to a mature organization. This tool should be adequate for a specific domain, be built into production processes and analyze the architecture. The tool was supposed to support an extensible metamodel, allowing to analyze data architecture. The tool should support team development of architecture and control of global standards. What turned out allowed to make "living" documents and templates that are validated and updated There's a combination of instruments inside. -- PlantUML and Mermaid - for diagrams as code -- Markdown - for markings and documentation -- Swagger and AsyncAPI - for documentation of API contracts -- YAML/JSON manifestos description -- SmartAnts language for requests for these descriptions n All this allows you to wind up on top of checking this architectural documentation, which allows you to control important things for architects using queries in the SmartAnts language.

In general, in my opinion, from this report we get something like this scheme: Some system for documenting architecture based on Dochub is proposed This system employs special people who have the name of an "architect" They don’t write application code, they write code that documents the architecture.

• They write validators for this description of architecture.
• And SDE (software development engineers) Write their code in production systems The question then arises: who maintains the relevance of production code vs architecture code and within what process? For example, if this is a mandatory stage for any feature and it has to be passed before its release, then lead time skyrockets, if it is done by a heavenly architect, and if it is done by SDE, then it is unclear what advantage he gets from these actions. If this is done after the fact, then we again get a lag between the real code and the architectural description, no matter how it was obtained: drawn in pictures or generated from the description of the picture by the code. (You can also ask chatGPT to generate pictures.).

P.S. In this approach, it embarrasses me that everything interesting is swept under the carpet. Conventionally, I would like to be able to connect architectural description and reality, and go from the second, and not draw the first at least code, even with hands. As a result, the process described with Dochub seems to me complicated, expensive and inconvenient for everyone in the development team, except the architect who is on the outside and comes up with rules and checks, and draws diagrams with code.

P.P.S. It is interesting to compare the story of Roman from Sber about Dochub and that in the same 2022 Cyril Vetchinkina from Sber Market told about their archrep and the process of writing ADR (me told yesterday). Kirill’s approach seemed to me more down-to-earth, practical and useful.

P.P.S In the next post, I’ll write where I’d like to dig into the architecture to make the architecture work non-invasive and useful for the developers themselves.

#Architecture #Software #SoftwareArchitecture #Management #Processes