Читать книгу Из разработчика в архитекторы. Практический путь - Евгений Сергеевич Штольц - Страница 2

ГОСТ Р 57100-2016 (docs.cntd.ru/document/1200139542) на основе ISO/IEC/IEEE 42010 даёт определение архитектуры как Основные понятия и свойства системы в окружающей среде, воплощённых в её элементах, отношениях и конкретных принципах её проекта и развития. Разновидностей её существует довольно много, но выделим основные по уровню абстракции: архитектуру приложения (Application Architecture), программною архитектуру (Software Architecture), архитектуру приложений Solution Architecture и бизнес архитектуру (Enterprise architecture). Архитектор приложения занимается разработкой архитектуры приложения (паттерны проектирования, распределение задач) и зачастую совмещает свою роль с ролью Team-Lead и ведущего разработчика ответственных компонентов. Software Architect занимается тем же, что и архитектор проложения, но работает с несколькими командами, добавляя унификацию используемых ими технологиями. Часто это позиция востребована в аутсорсинге, где много проектов и есть возможность снять нагрузку с Team-Lead, чтобы они больше общались с заказчиками и командой. Для этой позиции характерны требования для вакансии по знанию языка программирования и основного стека используемых на проектах. В такой ситуации архитектор ограничен в выборе технологий и найме им новых сотрудников. Начиная с появления в 1959 году, архитектор занимался декомпозицией системы, распределением частей по разработчикам и отвечал за последующую интеграцию разработанных компонентов в изначально требуемую систему. Ныне ситуация упростилась с появление микросервисов.

Корпоративный архитектор проектирует взаимосвязи между системами использую интеграционную шину данных предприятия, а архитектор приложений проектирует сами системы, декомпозируя их на приложения. Границы между приложениями определяются границами использования: разработки, развёртывания, предоставлению поставщику. Ранее, приложения, также объединялись по технологическим платформам и технологиями, но с приходом контейнеризации, положение могут содержать компоненты созданные на разных платформах, языках и стеках, заключённые в контейнерах. Также потеряла актуальность формирования границ на основе выкатки приложения в силу того, что выкатываются компоненты (контейнера) и уже тестируются в окружении других компонентов. В идеале группа микро сервисов сгруппирована по выполняемой функцией бизнесом и командой разрабатывающей ею, но зачастую в бизнес процессах участвуют общие компоненты, что размывает границы приложений. Подобная специфика привела к появлению отдельной специализации – Cloud Solution Architect.