Software Architect vs Solution Architect26.11.2024 00:00

Я расскажу вам о двух типах архитекторов: Software и Solution. Статья не про должность или функциональные обязанности, а про образ мышления. Должность и то, что написано в трудовой книжке могут быть какие угодно: системный архитектор, архитектор ПО, ведущий инженер или главный аналитик.

Статья поможет понять подход каждого типа архитектора к решению своих задач. Если вы хотите стать архитектором, то статья поможет понять в какую сторону вам лучше развиваться. Также она поможет в разговоре с другим архитектором, понять к кому типу он относиться и как правильно построить с ним разговор.

Рациональность

Что делаю архитекторы?… Они структурируют и организуют нечто в систему, используя разные способы, выделяют компоненты и модули или группируют функции в сервисы, или выстраивают сервисы вокруг доменов/поддоменов предметной области. При этом они применяют паттерны и лучшие практики, которые прочитали в авторитетных книгах и статьях различных гуру. Однако это условные и временные знания, потому что проектирование — это мыслительная, рациональная деятельность, а не научная, доказательная работа. Любой человек, который используя такой подход, никогда не может знать все возможные решения задачи. А решение в таком подходе подразумевает, что человек в любой момент пытается сделать менее оптимальную ситуацию чуть более оптимальной, в рамках своей рациональности. Именно это подразумевает абстрагирование в архитектуре и анализе. Архитектор упрощает представление о реальности, чтобы можно было отобразить свое решение в виде плоской схемы на экране или бумаге. Он ставит приоритеты одних целей в ущерб другим целям.

Это предисловие про рациональность необходимо чтобы прояснить суть того, что я расскажу дальше.

Два понимания архитектуры

Есть два образа мышления архитекторов, и базируются они не на определении, что такое архитектура, а на том, для чего она нужна, то есть какая от неё польза:

1. архитектура должна сокращать совокупную стоимость владения;

2. архитектура должна обеспечивать согласованное понимание.

Что касается определения «архитектура», то архитекторы с первым типом мышления в основном придерживаются понятия, что архитектура — это проектные решения, которые тяжело изменить. А архитекторы второго типа считают, что архитектура — это проектное решение, которое набор проектных решений организует в систему, соответствующую целевому назначению.

Архитектор первого типа — это образ мышления Software Architect (Архитектор программного обеспечения, хотя слово «обеспечение» привносит неправильный оттенок второстепенности). Второй тип архитекторов — Solution Architect (Архитектор решений).

У вас может возникнуть вопрос: «А почему нельзя достигнуть сразу обе цели одновременно?». Сложность согласования этих целей я постараюсь раскрыть в статье.

Архитектура «как предмет» и «как практика»

Сложности начинаются с понимания того, что является сложным в архитектуре.

Для Архитектора решения прикладная архитектура — это один из архитектурных слоев. Гораздо сложнее согласовать всю архитектуру решения, которая включает слои бизнес-архитектуры и исходный замысел, который определен стратегией. Архитектору нужно быть убедительным, одновременно настойчивым и гибким, чтобы добиться консенсуса между всеми заинтересованными сторонами. Поэтому для Архитектора решений архитектура в большей степени является практикой (проектной деятельностью), чем предметом.

А Архитектор ПО больше сосредоточен на конечном результате и на том, как архитектура влияет на жизненный цикл системы. Для него архитектура — это больше предмет, чем практика.

У вас может возникнуть вопрос: «Почему горизонт актуальности Архитектора решений не растянут во времени как для Архитектора ПО?». Дело в том, что Архитектура решения имеет в составе слой бизнеса, который более изменчив и непредсказуем, чем программное системы. Прикладная архитектура вряд ли изменится со временем, а если всё-таки нужно что-то кардинально изменить, то, скорее всего, придется делать новую систему.

Представление архитектуры от Архитектора ПО

Перейдем к наглядным примерам. Начнем с Архитекторов ПО. Они любят описывать архитектуру по модели C4.

Небольшое введение в концепцию модели С4. Архитектура описывается в представлении статической структуры с 4-мя уровнями:

• контекст. Система и окружение, в котором она работает;

• контейнеры, из которых состоит система. Это не Docker контейнеры, а подсистемы. Например, приложения и базы данных;

• компоненты, которые включены в контейнеры. Они отражают связи с другими контейнерами или другими системами, еще они формируются по функциональному назначению;

• код. По кодом подразумевается описание отдельных аспектов в компоненте.
  Например, в виде диаграмм последовательности или диаграмм классов.

Модель C4. Концепция описания

Теперь пример — «Система интернет банкинга». Этот пример приводит сам автор модели С4 Саймон Браун, пример можно найти на его сайте c4model.com.

Представление системы на уровне контейнеров следующее:

• Интернет-банк в виде Single Page Application для работы в браузере;

• Мобильное приложение;

• Backend — приложение предоставляющее API для Интернет-банка и Мобильного приложения;

• База данных для хранения учетных записей клиентов.

Уровень 2: Диаграмма контейнеров

Далее описана структура приложения, которое предоставляет API, тут есть:

• контроллер аутентификации;

• контроллер сброса пароля;

• контроллер управления счетами;

• компонент обеспечения безопасности;

• компонент для отправки электронных писем;

• фасад для АБС.

Уровень 3: Диаграмма компонентов

Рассмотрим схему декомпозиции. Тут нет требований чтобы все рисовать на разных схемах, по крайней мере диаграмму на уровне контекста можно легко совместить с уровнем контейнеров. Но декомпозиция всех контейнеров на компоненты на одной диаграмме будет трудно восприниматься. Диаграммы на уровне кода Саймон Браун не рекомендуют рисовать без крайней необходимости.

Модель C4. Общая схема декомпозиции

Исходя из понимания архитектуры и ее пользы, Архитектор ПО считает своей задачей «структурировать». Для него очень важна «Структурная простота». Чем меньше сложностей, тем меньше вероятность ошибиться, сделать что-то нереализуемое. Архитектор ПО считает, что функциональные требования не важны для построения архитектуры. Функциональные требования постоянно меняются, важнее иметь архитектуру, которая дает гибкость для реализации изменившихся функциональных требований. У вас может возникнуть сомнение по поводу этого утверждения, но тут я могу посоветовать перечитать книгу Роберта Мартина «Чистая архитектура» или книгу Криса Ричардсона «Микросервисы. Паттерны разработки и рефакторинга». Это образцы мышления Архитектора ПО, все ваши сомнения отпадут. Среди нефункциональных требований в первую очередь важны масштабируемость, надежность, безопасность.

Представление архитектуры от Архитектора решений

Теперь давайте посмотрим, как Архитектор решений выполнит описание для того же условного примера Системы интернет банкинга.

Архитектор решения нарисует одну схему для прояснения задачи, которую решает система, и того какие услуги она предоставляет. Из формальных нотаций больше всего подходит ArchiMate.

Концептуальная диаграмма решения

Первая особенность, это то, что архитектура разделена на слои. На слое бизнеса есть клиент и продукт, который ему предоставляется. Это договор комплексного обслуживания (ДКО). ДКО нужно воспринимать, как определение из предметной области, а не документ. Это продукт в рамках которого могут быть предоставлены банковские услуги: вклады и счета, платежи и переводы и др. Представляться эти услуги будут посредством интерфейсов: web-приложение и мобильное приложение.

Вторая особенность и отличие от привычных программных определений то, что «Интерфейс» для архитектора — это точка, в которой предоставляются услуги. Эти интерфейсы являются частью создаваемой Системы интернет банкинга, базирующейся на сервисах, которые предоставляет ядровая АБС. Также используются служебные сервисы управления данными и отправки электронных писем.

Третий момент, каждый нижний слой архитектуры поддерживает или полностью автоматизирует работу вышестоящего слоя посредством представления сервисов. С точки зрения сервисного подхода именно так должна быть построена архитектура.

Основные требования к архитектуре для Архитектора решений — это «понятность» и «согласованность». Он не структурирует, а организует решение таким образом, чтобы достичь согласованного понимания всех заинтересованных участников. Что касается нефункциональных требований к самому решению, то в первую очередь важны:

• эффективность — это стоимость использования логики и данных;

• надежность — кроме отсутствия ошибок, это также означает безопасность и непрерывность работы;

• гибкость — это стоимость внесения изменения.

Таким образом для Архитектора решения основное представление — это то, что делает система и ее составные части.

В реальных проектах архитектура решения будет выглядеть намного сложнее и может трудно восприниматься. В отличии от модели C4, которая построена по принципу матрешки «Контекст-Контейнер-Компонент», метамодель ArchiMate на порядок сложнее. Архитектор решения борется за понимание. А Архитектор ПО борется со сложностью. Кажется это про одно и тоже, но тут есть неочевидные моменты, так как контекст и цели работы архитекторов разные, то и подходы их разные.

Это таблица сравнения по описанному мной ранее, но ее мы пропустим, потому что намного интереснее, что каждый из архитекторов считает хорошей архитектурой.

Хорошая (рациональная) архитектура

Но хорошая она с точки зрения определенного типа архитектора, поэтому я заменил «хорошая» на «рациональная».

Архитектор ПО старается обеспечить удобство работы на всех стадиях существования системы, и таким образом снизить стоимости владения системой. В тоже время, он понимает, что система будет меняться и характер изменений непредсказуем, а в его понимании архитектура — это то, что тяжело изменить, поэтому его стратегия — это как можно дольше иметь как можно больше вариантов для любых изменений.

Архитектор решений старается добиться архитектуры, которая реализуема с текущим уровнем бюджета и уровнем компетенций команды разработки, согласована всеми заинтересованными сторонами. Также он должен быть уверен, что создаваемое решение будет применяться и несет пользу. Он также понимает, что невозможно один раз спроектировать неизменную архитектуру, поэтому его стратегия — иметь на руках некоторое целевое описание и последовательно улучшать его.

Архитекторы работают в разных контекстах, с разным количеством участников. Рациональные действия при одних условиях не будет выглядеть рациональными в других. Допустим, Архитектор решения возьмёт стратегию Архитектора ПО — откладывать принятие решений. Как долго он может выбирать варианты? Ведь, к нему первым же делом придет Архитектор ПО и скажет: «Давай уж определись, что мы делаем? Мне тут нужно понять архитектуру».

Эти два типа архитектора я представил в виде двух крайностей. В реальности выбор рационального поведения зависит от многих обстоятельств. Далее рассмотрим подходы к работе каждого типа архитектора. Исключим очевидные способы, такие как «Разделяй и властвуй».

Подход Архитектора ПО

Если вы Архитектор ПО, то я рекомендую не использовать на схеме структурные отношения: композиции и агрегация. В место них лучше отображать структуру посредством вложенности. Рекомендую не использовать стрелки, обозначающие различные зависимости, такие как «реализует» «использует», «обсуживает». Лучше, чтобы стрелки обозначали только потоки команд, потоки данных или потоки событий.

Спроектировать качественную прикладную архитектур очень сложно. Проблемы могут возникнуть из-за недостаточной вовлеченности Архитектора ПО в бизнес-задачу. Его решения должны быть согласованы с результатами работ аналитиков и Архитектора решения, которые объясняют, какую задачу надо решить, какую функциональность предоставить. А в тоже время на Архитектора ПО может давить команда разработчиков. Он старается упростить систему для разработки и тестирования. Может произойти инверсия, когда аналитики начинают подстраивать свои модели под решения, которые уже выбрали разработчики с Архитектором ПО.

Подход Архитектора решений

Задача Архитектора решений дать понимание, но вместо этого он может выбрать опасный путь борьбы со сложностью своих представлений, а не сложностью решения. То есть он не делает решение проще, а начинает рисовать попроще. И то, что он нарисовал начинают воспринимать лучше, но таким образом Архитектор решений может создать проблемы в будущем, так как на его схемах не проявляются моменты, где есть расхождения в понимании. Простую схему легче согласовать. Но у заинтересованных сторон складывается ложное впечатление о об уровне сложности и стоимости проекта. А в ходе реализации вскрываются несогласованные детали и скрытые сложности, которые требуют переработки архитектуры, удлиняют реализацию, генерируют технический долг.

Также Архитектор решений может прибегнуть к такому приёму, как раздельные представления, но тут есть риск рассогласования представлений друг с другом. Это случай, когда делаются диаграммы в разных нотациях. Человек, читающий такие схемы, должен в голове выстроить общую модель и найти в ней расхождения.

Раздельные представления

Для работы аналитиков раздельные представления приемлемы, но по моему опыту, для архитектора, чем меньше раздельных представлений, тем меньше риск получить рассогласованное решение.

Допустим архитектор не используете ArchiMate, так как никто в компании ArchiMate не понимает, поэтому архитектор проектирует в простых прямоугольниках и стрелках. Но такое упрощение не должно создавать волшебных прямоугольников на схеме, в которых подразумевается, что происходит какая-то магия. Архитектор хорошо и однозначно должен представлять, что подразумевает каждый элемент и стрелка на схеме. В этом вопросе, ограничения и правила формальных нотаций как раз помогают.

Становление архитектора

Но всё же если начать обобщать, то я субъективно могу сказать, что независимо от образа мышления архитектора, осознание, что такое архитектура и какой нужен к ней подход, приходит только после того, как архитектор проживет со своей архитектурой весь жизненный цикл системы или решения. Потому что спроектировать архитектуру — это только половина работы, а вторая половина — убедить команду следовать ей и довести ее до промышленной среды. Дальнейшее развитие — это осознание всего многообразия проблем, решений и различных факторов, которые есть в разных предметных областях, IT среде и всего того, что влияете на архитектуру. Таким образом архитектор получает способность проектировать решения охватывающее многофункциональную среду и многообразие факторов.

Например, Система интернет банкинга. Нужно подумать о регистрации клиентов; безопасности; защите персональных данных и банковской тайны; как будет формироваться отчетность и аналитика; какие есть новые требования законодательства; какая будет нагрузка; какое базовое ПО закупить; нужно ли сделать предварительное проектирование; оценить трудозатраты; и многое, многое, многое…

Материалы

Ниже указаны книги и ресурсы, которые я считаю полезными для изучения. Не все они про архитектуру. Но совокупность знаний в них, я надеюсь, поможет вам выработать свой рациональный подход.

• «Микросервисы. Паттерны разработки и рефакторинга» / Крис Ричардсон

• «Фундаментальный подход к программной архитектуре» / Нил Форд, Марк Ричардс

• «Современный подход к программной архитектуре: сложные компромиссы» / Нил Форд, Марк Ричардс, Прамод Садаладж и Жамак Дехгани

• «Черный лебедь. Под знаком непредсказуемости» / Нассим Николас Талеб

• «Чистая архитектура» / Роберт Мартин

• «Chess and the Art of Enterprise Architecture» / Gerben Wierda

• «Сумерки идолов, или как философствуют молотом» / Фридрих Ницше

• «Mastering ArchiMate» / Gerben Wierda

• «Простите, я разрушил вашу компанию» / Карен Фелан

• «Системное мышление» / Анатолий Левенчук

• «Производные Нуля: Дневник Структуратора» / Влад Горячев

• https://c4model.com/

• https://ea.rna.nl/

• https://architectelevator.com/

© Habrahabr.ru