Sber Enterprise Architect Framework (SEAF) (Category Architecture)

Interesting. speech corporate Sber frameworkIt allows you to look at one of their approaches to documenting architecture.

The main points that I learned for myself This framework was made for several years by a team of experts to solve the problems of architecture management and ensure its integration into the production process. The philosophical content of this framework is described in article "Architect" 2.0on Habre The framework does not contrast itself with other frameworks, but rather complements them by accumulating and digitizing practices - the illustrations show DDD, TOGAF, C4 Model, etc. The framework contains within itself tools, rods, methodology and artifacts (Good thing ontologies no) The purpose of the framework is to create a digital model of the enterprise, which will have undeniable characteristics and allow to produce derivatives. The automation tool is DocHub, which I categorize as architecture documentation as a code. The tool allows you to create a workspace for architects of different stripes, who will now draw on squares and arrows for visualization - now they will be able to write it in yaml files. There will be dualism as before: 1) What is happening in the code and infrastructure 2) What the architect drew in his yaml. But now it can be called as a code. The framework is suitable for federal management of architecture, which can be extended and adapted to the needs of each domain. In the list of tools there is a package manager that allows you to download and manage packets with metadata. SEAF encourages the community to adapt the framework to their needs and use successful methodologies The author agitates for the transition from architect 1.0 architect 2.0. Architect 1.0 A person who visualizes a visual scheme and model while an architect 2.0 A person who creates architecture and constantly works on improving and borrowing practices. In the report, the author tells about the metamodel, which is also described Github

To structure the metamodel, the approach of dividing it into layers and verticals was chosen. Layers highlight functional areas while verticals permeate and connect them. There are layers:

• Business architecture;
• Applied architecture;
• Technical architecture.

Verticals:

• Information architecture;
• Requirements management. An important principle of the metamodel is adaptability. It should be easily adapted to the needs of use. Provide for partial application, expansion and modification. Thus, the decision on the actual use of the metamodel is left to the user.

In general, this is a good attempt to create a framework for implementing the architecture documentation as a code approach.

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
• Architectural diagrams and metadata generation – Kirill Vetchinkin – E-community 2023

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