Как понять, что вы разговариваете с настоящим ИТ-архитектором

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

Как нам разобраться кто из них настоящий ИТ-архитектор, суждениям которого можно доверять, а чьи рекомендации стоит перепроверить? Я бы не стал делить ИТ-архитекторов на настоящих и фейковых. Внимание к архитектуре системы, решения или организации в целом – это уже хорошо. Тем не менее, полезным будет иметь некоторую шкалу, характеризующую уровень доверия к предложенным тем или иным экспертом архитектурным решениям(architecture decision). Примерно так же, как в свое время Леонард Ричардсон предложил использовать модель уровней зрелости для проверки соответствия API архитектурному стилю REST.

Итак, начнем. К нулевому уровню мы отнесем экспертов, которые долго и с удовольствием готовы порассуждать об архитектуре информационных систем, но в их суждениях мы не можем обнаружить характерных черт архитектурного подхода. Пусть они считают себя ИТ-архитекторами. И даже ничего страшного в том, чтоб слово архитектор использовалось в названии их позиции. В конечном счете, многие из нас начинали именно с этого уровня.

На первую, чуть более высокую ступеньку я поставлю людей, демонстрирующих определенный характер суждений, формируемый пониманием того, что архитектур, идеальных во всех ситуациях и подходящих для решения разных классов задач не существует. Впервые обратил на это наше внимание великий Фредерик Брукс статьей «No Silver Bullet», а развил тему Rick Kazman в методе анализа компромиссов в архитектуре (см. подборку материалов на странице Architecture Tradeoff Analysis Method сайта Software Engineering Institute, Carnegie Mellon University). Архитекторы довольно осторожны в суждениях о том, что такое хорошо и что такое плохо. Крайне редко можно от них услышать, что что-либо — это действительно здорово! Обратные высказывания встречаются заметно чаще, но всё же основной тип архитектурных утверждений – это сравнение альтернатив. Причем архитектор не ограничивается простой констатацией, что решение A лучше, чем решение B, а рассуждает о конкретных характеристиках: с точки зрения доступности А лучше B, но достигается это за счет ухудшения таких-то других характеристик.

Возможно, что в ходе таких рассуждений вы заметите, что архитектор концентрируется на одних аспектах системы, оставляя за скобками другие. Ваши аргументы и возражения… нет, не пропускает мимо ушей, но словно откладывает на потом. Он обязательно к ним вернется при обсуждении каких-либо других свойств системы, но проигнорирует их сейчас. Практически невозможно не разглядеть эту своего рода профессиональную деформацию, формируемую принципом Separation of concerns, архитектурными фреймворками, рассматривающими систему с разных точек зрения и вычленяющими в ней отдельные представления. Ему так удобней. Об это написал еще Эдсгер Дейкстра лет эта пятьдесят назад в On the role of scientific thought. И это еще одна характеристика, выдающая в вашем собеседнике ИТ-архитектора.

А следующей отличительно чертой являются особенности создаваемых им картинок. Обычно достаточно одного взгляда, чтоб понять рисовал ли картинку архитектор или кто-то другой. И речь здесь не о нотации моделирования. Даже при использовании нотации boxes and arrows (см. на рисунке пример из C4 model Саймона Брауна) компоненты и коннекторы не только именуются, но и стереотипизируются. На такой картинке всегда понятно, что означает та или иная фигурка или стрелка. В отличии от имен элементов,  стереотипы – это слова, как минимум, известные Википедии: названия протоколов, технологии разработки, а чаще окружение исполнения (run-time environment), стандарты взаимодействий. Если же имени и стереотипа недостаточно, то компонент включает вполне осмысленный текст. Как правило текста включить в описание требуется существенно больше, чем позволяет размер компонента, а архитектурная диаграмма становится больше похожей не на граф с вершинами в виде точек и множеством пересекающихся линий, а на хорошо сверстанную статью с колонками и окнами, уголками, подвалами и подверстками. Статью, слегка разбавленную стрелочками. Другой причиной отсутствия впечатления «взрыва на макаронной фабрике» является привычка мыслить:

паттернами (patterns) или чанками (chunking). Нотации моделирования описывают типы вершин и бинарных ассоциаций между ними, отрисовываемые в виде ребер. Необходимость выразить N-арную ассоциацию влечет добавление в модель дополнительных, часто суррогатных, элементов. Архитекторы так не думают. Услышав аббревиатуру CQRS, архитектор представляет сразу штук пять элементов, объединенных петлей «command-query». Каждый архитектурный паттерн (см., например: Enterprise Integration Patterns) это уже «топология» как в смысловом, так и в визуальном плане. Зачем перерисовывать её каждый раз по-новому. Речь скорее идет о том, чтоб разместить элементы конкретной задачи в типовой узор или разложить продукты по полкам холодильника: презентация вверху, логика посередине, данные внизу. Ну, или всё тоже самое слева направо если к этому есть предпосылки. Всё прочее, всего лишь уточнение и расширение паттернов, которые следует включить в уже скомпонованную типовую картинку.

Безусловно, перечисленные выше свойства не претендуют на полноту и не могут рассматриваться в качестве объективных критериев (например, на собеседование). Есть много других особенностей, выдающих, на мой взгляд, в собеседнике ИТ-архитектора. Какие-то из них могут восприниматься не вполне позитивно. Например, я редко замечаю у архитекторов желание подчеркнуть во взаимодействии типичный ход событий («happy path»). Другие, как способность рассуждать на любом уровне абстракции, не теряя его и не застревая на слишком абстрактных или конкретных вещах – вполне позитивны. Возможно вам захочется поделиться своим набором наблюдений. Ну, так не стесняйтесь перечислить их в комментариях к этому сообщению

  1. Я придумал теперь кратчайший путь, как стать архитектором (шутка):

    Долго и с удовольствием рассуждать об архитектуре информационных систем.
    Повторять фразы:

    No Silver Bullet!
    Remember Separation of concerns!
    N-арная ассоциация!
    Enterprise Integration Patterns!

    Рисовать картинки только с надписями.

  2. Единственный критерий архитектора — принимает ли он архитектурные решения (архитектурно-значимые решения). Какие конкретно, когда и сколько.

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

  3. Интересная статья, в дополнение я бы к «архитектурным» признакам указал:
    1. Умение выделять значимые неопределённости, которые мешают достижению целей и формулировать их в виде некоторых формальных «исследовательских задач».

    Как я это вижу:
    — «Мы можем сделать микросервис, поддерживающий процесс А, для предварительного проектирования его интерфейса нам нехватает на данный момент сведений о взаимодействиях процесса А с процессом Б, а так же о наличии скрытых взаимодействий процесса А.
    Это ведёт к возможному риску переработки и переделок, примерно Х часов.
    Для того, чтобы предотвратить наступление риска затрат Х часов на перделки, мы можем подключить аналитика, который проведёт исследование связей процесса А за время X/100.
    Его задачей будет дать оценку состава упущеных и неопределённых связей процесса А.
    Если упустили, какова их сложность в составе и количестве объектов данных при обмене и количестве уникальных элементарных операций на взаимодействие.
    Это позволит уточнить степень достоверности наших представлений и выделить самые проблемные части постановки задачи по создаию микросервиса, и спроектировать его интерфейсы так, чтобы при снятии неопределённостей со временем снизить трудозатраты на возможные переделки. Ожидаемое снижение трудозатрат на переделки составляет от 0,3Х до 0,7Х за счёт… и т.д. »

    Привычку каждый раз переходя от картинки к картинке показывать как на этих картинках сопоставляются «квадратики» .

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

    Привычка выделять «решения» от «обоснований решения» и строить свою беседу в научном стиле.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s