.

процесс.

      В идеале, архитектура неизменна, но в реальности это часто не так. В основном, краеугольным камнем становится коммуникационные навыки архитектора, который умеет договариваться, находить компромиссы и доносить решения. Для донесения сути разрабатываемой архитектуры применяют различные отображения, срезы, которые отображаю архитектуру с разных сторон. Для IT это разработка архитектуры различных слоёв. Слои могут быть по TOGAF: бизнес-архитектура, информационная архитектура, Solution Architect, интеграционная архитектура, техническая архитектура). На каждом уровне необходимо отобразить компоненты системы (структурная схема) и бизнес-процессы (динамическая схема).

      В общем, архитекторов можно разделить на две группы: Enterprise Architect и Solution Architect. Enterprise Architect занимается поиском и унификацией технологий, в то время как Solution Architect разработкой архитектуры конкретной системы на основе утверждённых технологий и внесение её в карту приложений. В небольших компаниях, в которых разрабатываемых архитектур систем невелико, корпоративная архитектура не выделяется – её заменяет составляющая архитектуры системы, а именно интеграционная архитектура.

      Solution Architect должен обладать очень хорошими Soft- навыками (коммуникационными навыками). В бытовом представлении может сложиться образ человека, сидящего и рисующего квадратики и стрелочки между ними. Но, давайте представим ситуацию: приходит архитектор на проект, видит команду что-то разрабатывающую и слышит слова от заказчика: продукт тормозит и нестабильно работает, нужно исправить ситуацию. Что, где и почему тормозит и падает, да и просто, где его проект не понятно. Никакие глубокие технические навыки сейчас не нужны, да и проекты разные (на стандартном проекте архитектор не нужен) и уже есть на нём эксперты. Здесь основное отличии не в уровне работы, по сравнению с разработчиком, а в принципиально другой – вместо решения поставленной задачи формирование самой задачи. Если разработчик берёт готовую задачу из системы постановки задач (например, Jira) и её выполняет, иногда, уточняя условия у постановщика, то у архитектора огромное количество уходит на поиск стейкхолдеров, выработку оптимального решения на основе требований и нахождение компромиссного решения. Есть обратиться к менеджеру, тим лиду, разработчику, то ни один из них не скажет в чём проблема. Если же пойти в инфраструктуру, то ситуация ещё интереснее – кто-то, что-то, где-то разворачивал, а как-то это всё работает, а кому задать вопрос тоже не ясно. Если система более ли менее сложная, то интеграций очень много, и за каждой стоит отдельные люди, найти зачастую которых можно, узнав только у тех, кому довелось с ними работать. При этом напрямую просто так задать вопрос интеграторам не получится – у них свои задачи, и зачастую на связь они не выходят. Это типичная ситуация менеджера в проекте, поэтому, в этой части можно архитектора программного обеспечения рассматривать как технического менеджера, который управляет не задачами, а архитектурными