ГОСТ Р 57100-2016 (docs.cntd.ru/document/1200139542) на основе международного стандарта ISO/IEC/IEEE 42010 даёт определение архитектуры как "Основные понятия и свойства системы в окружающей среде, воплощённых в её элементах, отношениях и конкретных принципах её проекта и развития". Но, определение не самой архитектуры, а фиксации архитектуры на бумажном или электронном виде и только одно слово "развития" говорит нам об каком-то процессе улучшения. Если же речь идёт о строительстве зданий и сооружений, то понятно, что они проектируются, создаются, эксплуатируются, и практически никогда не развиваются, что не характерно для бизнеса, системы которого, в том числе IT системы, должны адаптироваться к изменениям. Более широко даёт определение компания Microsoft в Microsoft Application Architecture Guide, в которой трудятся архитекторы и которая сертифицирует архитекторов для проектирования на основе своих продуктов у заказчиков. Так, программная архитектура описывается, как процесс определения структурированного решения, которое отвечает бизнес, техническим и операционным требованиям, он включает в себя серию решений, основанном на широком круге факторов, каждое из этих решений может иметь сильное влияние на качество. И действительно, на практике, архитектор разрабатывает архитектуры на определённый временной горизонт, указывает как архитектура текущей системы будет переведена в целевую архитектуру этой системы. Архитекторы не просто разрабатывают, но и сопровождаю проект: делают presales, собирают требования, популяризуют решение, актуализируют архитектуру в след за изменения требований, делают проверку (архитектурный надзор) и это процесс циклический (далее рассмотрим циклический фреймворк TOGAF). Архитекторы решают проблемы и ищут тоски возможностей: корпоративные архитекторы – для компании в целом, архитекторы решений – для решения. Результатом работы архитеторов может быть не только диаграммы, а и концепции, стандарты, работающий опытный прототип (PoC, Proof of concept).
Разновидностей её существует довольно много, но мы выделим основные по уровню абстракции: архитектуру приложения (Application Architecture), программною архитектуру (Software Architecture), архитектуру приложений (Solution Architecture) и корпоративную архитектуру компании (Enterprise Architecture). Архитектор приложения занимается разработкой архитектуры самого приложения, используя для этого паттерны проектирования и распределение задач, и, зачастую, совмещает свою роль с ролью Team-Lead или ведущего разработчика ответственных компонентов (Tex-Lead). Software Architect занимается тем же, что и архитектор приложения, но работает с несколькими командами, добавляя унификацию используемых ими технологиями. Часто это позиция востребована в аутсорсинге, где много проектов и есть возможность снять нагрузку с Team-Lead, чтобы они больше общались с заказчиками и командой. Для этой позиции характерны требования для вакансии по знанию языка программирования и основного стека используемых на проектах. В такой ситуации архитектор ограничен в выборе технологий и найме им новых сотрудников. Начиная с появления в 1959 году, архитектор занимался декомпозицией системы, распределением частей по разработчикам и отвечал за последующую интеграцию разработанных компонентов в изначально требуемую систему. Ныне ситуация упростилась с появление микро-сервисов.
Корпоративный архитектор проектирует взаимосвязи между системами использую интеграционную шину данных предприятия, а архитектор приложений проектирует сами системы, декомпозируя их на приложения. Границы между приложениями определяются границами использования: разработки, развёртывания, предоставлению поставщику. Ранее, приложения, также объединялись по технологическим платформам и технологиями, но с приходом контейнеризации, положение могут содержать компоненты, созданные на разных платформах, языках и стеках, заключённые в контейнерах. Также потеряла актуальность формирования границ на основе выкатки приложения в силу того, что выкатываются компоненты (контейнера) и уже тестируются в окружении других компонентов. В идеале группа микро-сервисов сгруппирована по выполняемой функцией бизнесом и командой, разрабатывающей ею, но зачастую в бизнес-процессах участвуют общие компоненты, что размывает границы приложений. Подобная специфика привела к появлению отдельной специализации – Cloud Solution Architect.
Исходя из уровня архитектуры, который предполагается проектировать, можно из абстрактного вопроса – как стать архитектором – можно превратить в набор требований, необходимый для решений поставленной задачи: от чисто технической, до организационной. Так программный архитектор может все организационные мероприятия делегировать на Team Lead и сосредоточится чисто на техническом описании структуры программы, и зачастую он является чистым технарём и по совместительству Tex-Lead, но никак не может делегировать техническую. В противовес, корпоративный архитектор может быть не техническим специалистом, например, директором, проводя коммуникацию для организации связей автоматизированных систем и удовлетворения этих систем нуждам заказчиков. Исходя из этого можно догадаться, что на вопрос – как становятся архитекторами – можно ответить, что архитекторами до Solution Architect эволюционно по технической ветке, а корпоративным, либо по технической ветке, либо по менеджерской, включая бизнес—аналитика. При этом стать архитектором можно в любое количество лет.