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.
Let's take a closer look at the communication and interactions of the service architect:
* He is in contact with TeamLead to view the current team backlog. The backlog contains a roadmap and requirements. This will allow and determine the amount of work that she can do and their priorities.
* He contacts the Product Owner to obtain a business description of the required service, and on what features he agreed with the customer, business processes.
* He liaises with the corporate architect to get the conceptual architecture of the functional area of the service and the requirements of the standards that the service falls under.
* He contacts the platform architect to get the component base.
* He contacts the server architects with whom he integrates.
* He contacts with specialists responsible for procurement (if new servers, paid software are used), security, technical support of the service (if new stacks are used), support, legal department (if OpenSource products are used).
When joining a project, like a manager, it is necessary to familiarize yourself with what is available and identify the stakeholders (stakeholder). Stakeholder – related to the project. He may be interested in success or, conversely, not interested. ITIL4 (IT Infrastructure Library version 4), a collection of recommendations for the use of ITSM (IT Service Management) from 2019 created by more than 150 authors to build IT developing since 1986, defines such basic types as Sponsor, Customer, User, Service Provider and others:
* User – a person who uses the service. For example, if the system is developed for the accounting department, then the accountants will be the users, although the customer can be the head of this department. Often they will test the product being developed and evaluate it;
* Customer – make demands and is responsible for the result from its consumption. For example, if the system is being developed for an internal department, then the head of the department orders this system for his employees in the expectation that their work will become more efficient;
* The sponsor is the resource owner who approves the payment. For our example, it may be a CFO who considered it economically justified to develop this system to increase efficiency for such a volume with such risks in the current situation;
* Contractor – an interested party responsible for the provision of services. The contractor can be both internal and external. For architecture, they can be a development team, system engineers, individual departments integrating with their various services, and others;
Конец ознакомительного фрагмента.
Текст предоставлен ООО «ЛитРес».
Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
