Notes of an IT Architect - страница 12

In general, the tasks of architecture development are the coordination of components, the choice of new technologies, the achievement of the desired result without alterations, and the simplification of acceptance. The main task for managers of architecture development is to accelerate implementation and accelerate the entry of new employees. For the customer – compliance of the implementation with the intention and in case of deviations during the development of the correction at the early stages, which reduces the cost of fixes. For developers – quick and easy implementation into the production process.

Ideally, architecture is immutable, but in reality this is often not the case. Basically, the cornerstone is the communication skills of the architect, who knows how to negotiate, find compromises and communicate solutions. To convey the essence of the architecture being developed, various mappings, slices are used, which display the architecture from different sides. For IT, this is the development of the architecture of various layers. The layers can be by TOGAF: business architecture, information architecture, Solution Architect, integration architecture, technical architecture). At each level, it is necessary to display system components (structural diagram) and business processes (dynamic diagram).

In general, architects can be divided into two groups: Enterprise Architect and Solution Architect. Enterprise Architect is concerned with finding and unifying technologies, while Solution Architect is developing the architecture of a specific system based on approved technologies and entering it into an application map. In small companies, in which the developed system architectures are small, the corporate architecture does not stand out – it is replaced by a component of the system architecture, namely the integration architecture.

Solution Architect must have very good soft skills (communication skills). In everyday life, the image of a person sitting and drawing squares and arrows between them can be formed. But let's imagine a situation: an architect comes to a project, sees a team developing something and hears words from a customer: the product slows down and works unstable, the situation needs to be corrected. What, where and why it slows down and crashes, and just where his project is not clear. No deep technical skills are needed now, and projects are different (an architect is not needed on a standard project) and there are already experts on it. Here the main difference is not in the level of work, in comparison with the developer, but in a fundamentally different – instead of solving the task, the formation of the task itself. If a developer takes a ready-made task from a task setting system (for example, Jira) and performs it, sometimes clarifying the conditions with the director, then the architect spends a lot on finding stakeholders, developing an optimal solution based on requirements and finding a compromise solution. If you contact the manager, team lead, developer, then none of them will tell you what the problem is. If you go to the infrastructure, then the situation is even more interesting – someone, something, somewhere deployed, but somehow it all works, and who to ask the question is also not clear. If the system is more or less complex, then there are a lot of integrations, and behind each there are separate people, who can often be found by learning only from those who happened to work with them. At the same time, it will not be possible to directly ask the integrators a question – they have their own tasks, and often they do not get in touch. This is a typical situation of a manager in a project, therefore, in this part, the software architect can be viewed as a technical manager who manages not tasks, but architectural components.