— Как я пришел в Solution-архитектуру? Просто в один прекрасный момент поймал себя на мысли: мне хочется постоянно решать сложные задачи и при этом ещё и писать код, — вспоминает Николай Зенькевич. — На своих проектах я ежедневно сталкивался с задачками, которые мне проще было решить самому, в силу своего опыта, знаний, тяготы ко всему непростому. С тех пор так и продолжается — занимаюсь архитектурой, бизнес-анализом, моделями данных, контрактами, интеграций и так далее.

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

Итак, в чём заключаются основные задачи Solution-архитектора?

1. Уметь мыслить и видеть частности

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

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

2. Быть готовым к обычному дню

• Отвечать на вопросы команды, заказчика.
• Проектировать и писать техническую документацию, разбираться с требованиями.
• Изучать новые технологии.
• Работать с кодом проекта, заниматься прототипированием, оптимизацией, рефакторингом.
• Делиться знаниями.

3. Уметь говорить, слушать и читать

Читать в прямом смысле слова: быть готовым вычитывать документы по 100-200 страниц. Причём делать это так, чтобы всё закреплялось в твоей памяти, откладывалось на полочках в «хранилище», и ты в любой момент мог достать это и применить. Это очень важно: прочитать документ, пропустить его через себя и осознать. Я преподаю в БГУ на РфиКТ «Прикладное программирование» и «Безопасность корпоративных систем» и вижу, что студенты потеряли этот навык. Почему? Они перестали работать с бумажными документами.

Понятно, что книга в электронном виде – практично. Но есть один минус: когда ты работаешь с электронной версией, ты не воспринимаешь её как книгу. А потом в курсовой или дипломной работе студенты противоречат сами себе, и разницы в этих противоречиях — страниц 10. А всё потому, что не видят общей картины. Это погрешность современного чтения.

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

4. Постоянно задавать вопрос «зачем»

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

5. Уметь читать чужой код

Одно из самых важных качеств не умение писать код, а умение читать чужой код, анализировать чужие данные, готовые контракты. Почему? Мы реже сталкиваемся с созданием чего-то совершенно нового, с нуля. Сегодня много реверс-инжиниринга. Сделаю акцент: не нужно уметь, например, написать новую программу на Коболе, но надо суметь прочитать и работать с ней дальше. Ещё всегда нужно думать и искать альтернативу — а для этого требуется хорошая техническая экспертиза.

Зачем альтернатива? Чтобы убедиться, что найденное решение — оптимальное. Но убедиться в этом самому мало — придётся доказать это команде, бизнесу. А как проще доказать? Правильно — сравнить с чем-то. Вот я, к примеру, при поиске решений всегда строю матрицу: решение — положительные стороны — отрицательные стороны. К слову, это отлично визуализирует работу SA.

6. Проявлять гибкость мышления и находить 5-6 решений

Кстати, как правило, шестым оказывается решение do nothing. Оставь всё как есть. Между прочим, это решение, с которым бизнес часто соглашается. На нашем проекте была ситуация, когда на границе года не очень корректно обрабатывались события: произошло в конце декабря, а обрабатывается в январе. Мы аккуратно прописали варианты её решения, среди которых был do nothing. Из профитов — ничего не нужно делать. Из минусов — какие-то проблемы останутся.

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

Или вот ещё классический пример. На сайтах многих авиакомпаний ты можешь сделать новый заказ, отменить его, но не можешь его модернизировать. Почему? Потому что это происходит редко. Тот, кому это понадобилось, может позвонить по телефону и решить вопрос. Если же мы начнём делать это онлайн, будет сложно.

Но и это не самый главный аргумент. Вопрос в том, кто из пользователей сможет этим воспользоваться!? Бабушка из Оклахомы? Кнопочки «сделать всё хорошо» не будет. И в результате велика вероятность, что 80 процентов сложностей, которые мы реализуем, понадобятся лишь пятой части клиентов… Поэтому с точки зрения архитектуры, сразу важно вычленить тот минимум, который необходимо оптимизировать.

Кстати, об оптимизации.

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

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

Что мы видим? Требование «нам надо быстро добавлять страны Карибского региона» бизнес превратил в техническое решение, причём не самое оптимальное и правильное. Граница между бизнес-требованиями и архитектурными решениями очень тонка. Важно этот момент понять и отследить. И это задача Solution-архитектора.