Архитекторами называют не только людей, занимающихся проектированием ИТ-решений, но и просто хороших специалистов, разбирающихся в определенной области. Многим присваивают титул архитектора по совокупности заслуг. Многие эксперты, занимающиеся самыми различными видами деятельности, в душе считают себя немножко ИТ-архитекторами.
Как нам разобраться кто из них настоящий ИТ-архитектор, суждениям которого можно доверять, а чьи рекомендации стоит перепроверить? Я бы не стал делить ИТ-архитекторов на настоящих и фейковых. Внимание к архитектуре системы, решения или организации в целом – это уже хорошо. Тем не менее, полезным будет иметь некоторую шкалу, характеризующую уровень доверия к предложенным тем или иным экспертом архитектурным решениям(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»). Другие, как способность рассуждать на любом уровне абстракции, не теряя его и не застревая на слишком абстрактных или конкретных вещах – вполне позитивны. Возможно вам захочется поделиться своим набором наблюдений. Ну, так не стесняйтесь перечислить их в комментариях к этому сообщению