The beginning of the system architecture. Philosophy and language. Part 1

I will say right away - I am a novice architect who is re-learning this craft from system administration.

In this article there will be no reasoning on the following topics:

• How I got into the industry and the troubles of system administration;
• The presence / absence of sane literature and articles, school system architects;
• How I feel in the new position and future plans, etc.

I will begin the introductory part with my limited understanding of the place of an architect in a large company.
')
In the information technology department there are many participants in the process of software maintenance and development: programmers of various directions, analysts, testers, system administrators, technical support at various levels, etc. Each of them sees either part of the system or the whole system, but from its own point of view (for example, a first-level technical support specialist “sees” the system as an advanced user).

A bit of philosophy. All information assets of the enterprise (applications, databases and repositories, data sources, integration services) are a single whole. A modern enterprise does not have fully autonomous services. From the assets that do not interact with the services of the enterprise, integration will be required in the future.

So, from the architect in all this cauldron of logic and data a special one is needed - the architectural vision of the information system. An architect is a person who knows almost everything and almost everything. No, I do not mean that he is able to climb into the code and fix the bug. I mean “vision” in terms of data and the connections between them. The integration of information systems is now the most complex and critical task of the architecture. All the houses are already built - enterprises often prefer samopisnym purchased systems. Yes, buildings do cosmetic repairs, but this is not the most important thing. (If you do not work in a software development company). The main task of the architect is to build communications and build infrastructure.
But the company, in most cases, does not live in an isolated environment. Does it make sense in a city with good infrastructure, to which no highways lead? The company interacts with the IT systems of various organizations and individuals directly or through intermediaries. It is much more difficult to organize such interaction, because you need to agree with all the participants of the system on the subject and exchange formats. The matter can be simplified by the fact that these agreements have already been reached and specified in international standards, but in practice very few people adhere to them.

Now a little about the "cosmetic". Our city already has internal and external infrastructure - what else, it seemed necessary, if only people would not live in the city. And people constantly have new needs, from apartment renovation to the construction of a new building. So it is in IT, where a continuous stream of new requirements is quite normal. The task of the architect is to trace the requirements and their implementation, as well as influence the decisions on their implementation. We can not allow the demolition of the wall in one of the apartments destroyed the entire building or we have built a house that nobody needs.

There are cases when developers release a product that does not meet the requirements of the user. And here comes one of the unpleasant, but the priorities of the architect - to follow the process of implementing user requirements in the program code. The architect must understand and document not only the decisions, but also the reasons for making these decisions.

From the previous paragraph follows the main difference between the crafts of the system architect and the city planner. Ready? I will reveal a simple truth - the laws of physics do not affect the software architecture! No, of course there are system limitations, best practices, patterns and principles. But all this can be easily circumvented, we can build a house of both stone and sand, and both will stand for hundreds of years. We can run a pipeline through the core of the Earth or place the house upside down - and all this will work perfectly if the decision is made weighted. Information assets, in a sense, are not real and there is no limit to the flight of the developer’s imagination (within reasonable limits, of course).
One of the methods of limiting the flight of imagination of developers are architectural principles and limitations. They are a set of system and business level rules. For example, one of the principles may sound as follows: “For the project we use ASP.Net technology”. It’s not bad to write the reasons for these principles right away.

Naturally, all of the above should be stored in two places: briefly in the head of the architect and in detail in the documentation. Record keeping is a task no less important and complex than all the above. The architecture document itself should be somewhere in the middle between the requirements and the source code. This document is something like the history of the transformation of user requirements into a subsystem.

One of the difficulties of document architecture is frequent changes. And there is no unambiguous methodology for monitoring and maintaining the history of these changes. I also have no understanding of the principles of maintaining this document, but I will try to reveal them in the third or fourth article of my cycle.

That's all for today. I decided not to write too large articles, but to split everything into small parts (By the way, this is also one of the architect’s tasks). In the next article we will talk about the language of architects - UML and abstractions.

UPDATE. I beg you to comment on the subject. My level of competence does not need to be assessed.