Documenting architecture: an introduction (remastered)





I read the article Documenting the architecture: an introduction and decided to describe the above with a different approach.



I will not paint the diagrams in the text, try reading them in Archimate. Imagine deciphering an Egyptian hieroglyphic script. Here is a hint - the character set for decoding the Summary of Language Notation



Description of motivation and strategy



Let me remind you of the definition I introduced earlier :

Architecture is a design solution that organizes a set of design solutions into a System corresponding to the intended purpose.


So you need to determine the purpose of the system. We are not directly set goals and requirements, but we can consider it on a larger scale using the JTBD approach.





Business layer and application layer



Let us assume that β€œMan” has chosen the information product β€œBlog” from the available alternatives.

The product is digital, so the business layer (functional architecture) and the application layer (application architecture) can be connected immediately.





At the same time, the services "Commenting" and "Managing comments" will not be used yet, since moderation requires time resources.



Technological layer (technological architecture)



There are many platforms for blogging, you don't need to implement anything from scratch. To select a specific platform, you need to draw up a comparative table based on the requirements (which, alas, are not specified). You can supplement it with other criteria. Here I think everything is clear. Let's say you chose Ghost CMS, Apache HTTP Server and MySQL.





Now we need to place all this in some infrastructure, which we will also select according to the relevant criteria. Let it be GCP.





Summary



Well, that's all. Yes, I understand that there is little explanation.

What questions may arise:

1) Is it possible to place all the information on one image?

Answer : Yes, if you need to control the connectivity. But you need to maintain a balance and carefully combine the layers (business, applied and technological, etc.). The fewer different charts you create, the less likely you are to get mismatch. The more elements in the diagram, the more difficult it is to understand the meaning. Therefore, a balance is needed.

2) Can the Viewpoint concept be used?

Answer : Yes, but make sure that the Views are consistently aligned with each other, otherwise then you will have to agree on the people who read your diagrams. see item 1)




All Articles