Architecture as data

The first article about our architecture management tool was published in mid-September. DocHub… Two months have passed and the intermediate results of implementation can be summed up. They turned out to be unexpected and interesting.

Structured identifiers

DocHub works with architectural object manifests. A manifest is a YAML or JSON file. For example, this is how the system with the code designation 01000 is described:

rdwsoft.rabota.systems.01000:
   title:  АС Работа.ру (01000)
   entity: system
   type: Целевая, внедрено полностью
   technologies:
       - PHP
       - RabotaX
   aspects:
       - rdwsoft.rabota.employer.brand
       ...
       - rdwsoft.rabota.crm_voip
   links:
       - id: rdwsoft.rabota.systems.06001
         direction: '-->'
       ...
       - id: rdwsoft.rabota.systems.01014
         direction: '<-->'

When we started describing our systems, we quickly realized that peer identifiers were not suitable for us. The fact is that already in the code it is necessary to read which layer of the presentation the object belongs to, and of which it is a part.

To address this problem, structured identifiers were introduced. In the example, this is “rdwsoft.rabota.systems.01000” where:

rdwsoft – legal entity (company);
rabota – product;
systems – systems selling the product;
01000 – system code in the system registry.

Perhaps it will be easier to describe the idea graphically:

Don’t find it very similar to the pictures from C4 Model? Indeed, through identifiers, we can describe the C4 Model in text form. But unlike the C4 concept, the number of layers in DocHub is not limited. This is done meaningfully.

The point is that C4 does not cover enterprise architecture layers. For example, we are part of an ecosystem. Our company’s products are integrated into it. To represent this, we need more layers:

The image clearly shows “holes” in the upper levels. Thus, if there is an obvious similarity of the concept to the C4 Model, structured identifiers do not explicitly implement it.

Visibility of architecture

A notable benefit of introducing structured identifiers has been the ability to view the architecture as a tree.

The topology of the architecture is clearly visible. You can easily determine the belonging of architectural objects to domains.

Controlling architecture consistency

The killer feature, in my opinion, is the ability to control the consistency of the architecture description. Judge for yourself, structured identifiers provide a clear understanding of the hierarchy of objects. If objects are not described at some level of the hierarchy, this means only one thing – they were missed.

This same property allows you to clearly associate the actual implementation of the code level with the upper levels of the architecture description.

It becomes possible to automatically generate (by various analyzers) a description of the architecture at the lowest level, and then, identifying the “holes”, fill them. Going up from the implementation level to the very top level of abstraction.

This feature was expressed in the DocHub consistency control subsystem. In real time, the designer receives information about the problems found in the architecture description. The subsystem looks very simple:

By clicking on the “Problems” menu item, the designer receives detailed information about them.

Analyzing architecture as a dataset

The above solutions led to the concept of “Architecture as data”.

Having a description of the architecture in the form of structured data, it becomes possible to analyze it for various purposes. For example:

Analysis of architecture for sufficiency;
Analysis of architecture for consistency;
Validation of architecture according to accepted standards;
Linking DocHub objects to external objects;
Etc. etc.

But, perhaps, it is worth highlighting a very important profit:

There is a possibility of ML architecture analysis. Prospects for the integration of intelligent design assistants are opening up.

I think this is really important for the design of complex landscapes. Who knows, maybe this is where the image from the Matrix known to all of us will appear.

Total

Of course, this article does not fully describe our implementation experience. Rather, it is just a “side note”. I thought it important to highlight the idea of managing architecture as data in a separate article.