Роль Архитектора

На выходных обсуждали роль архитектора в принятии архитектурных решений.

Было высказано два тезиса:
1. Архитектор не принимает решения. Это делают менеджеры. Роль архитектора переоценена.
2. Архитектурные решения хорошо принимаются и без архитектора.

Позволил себе не согласиться )

1. То, что менеджерам кажется разумным и единственно верным решением - это то же решение принятое каким-то архитектором. Только чужим.
2. Если это решение стало популярным или даже необходимым, значит это кому-нибудь нужно. То есть кто-то с этого зарабатывает. Не вы.
3. Свой архитектор мог бы разработать альтернативное решение для своего бизнеса. Тут нужны навыки и опыт.
4. Свой архитектор может хотя бы сбалансировать интересы чужого и своего бизнеса.
5. Если вы ещё не почувствовали зачем вам нужен архитектор, то он вам и не нужен. Для архитектуры нужно созреть.

А в общем как и везде. Можем взять свое решение, но кто его будет делать. Или платить за чужое, но дорого, и результат непредсказуем.

#РольАрхитектора

Obsidian
не реклама)

Хочу порекомендовать obsidian, как основной инструмент архитектора.
https://obsidian.md/
Я с большим удовольствием перенес в него:

1. Формирование ADR и RFC в формате md (до этого использовал intellij idea)
2. Захват интересного из Интернета (использовал Notion и Evernote)
3. Ведение заметок (использовал Evernote)
4. Записи в процессе проведения встреч (использовал Notepad++)
5. Подготовка кода для презентации (использовал разные утилиты и intellij idea)
6. Подготовку диаграмм в различных форматах (draw.io, excalidraw, plantUML)
7. Оформление и показ презентаций (использовал PowerPoint)
8. Управление списком дел (todoist)

Основной формат - md
Есть интеграция с Git
Есть мобильный клиент
Масса плагинов от комьюнити

Если интересно, как обустроил пространство под архитектуру, могу рассказать.

#АрхитектурныеИнструменты

Две стадии развития системы

1. Черновик (прототип)
На этом этапе обкатываются интересные идеи. Втискиваются модные технологии.
Разработчики придумывают нестандартные ходы.
2. Чистовик (продукт)
На этом этапе система удовлетворяет потребности стейкхолдеров и приносит доход.

Переход от первой стадии ко второй часто происходит ВДРУГ.
Упс, наш прототип стал продуктом, и заявлено, что он умеет все, притом быстро и надёжно.

Архитектура как код (AaC)

Сейчас многие говорят об AaC. Появляются продукты с поддержкой этой идеологии (например DocHub)
Я тоже задумался над вопросом, чего бы я, как ленивый архитектор, хотел бы получить от этой концепции.

Мой список:
1. Ведем модель как данные (архитектура как код) на основании которых можно автоматически сгенерировать любое требуемое представление
2. ADR - это commit в код архитектуры. Система должна помочь мне в формировании ADR исключив из процесса механическую составляющую (минимум - шаблонизатор)
3. Фиксация ADR приводит к автоматической интеграции новых решений в модель
4. Попытка зафиксировать ADR должна автоматически порождать задачу на проверку и согласование (RFC как merge request)

#AaC

Автоматизация архитектурного процесса

Что лично я ожидаю от инструментов автоматизации архитектурного процесса.

Презентовал доклад в IT-One

Выкладываю здесь:

https://disk.yandex.ru/d/_GIBNU85PSS4mQ

👆 Кстати презентация выше подготовлена с помощью того же obsidian.
Плагин Advanced Slides.

https://mszturc.github.io/obsidian-advanced-slides/

Скоро боты заменят технических писателей.

Компания «Яндекс» планирует заменить технических писателей на ботов. Об этом сообщает «Коммерсантъ». Предполагается, что боты будут писать тексты для внутренних проектов компании. Сейчас в компании работают 22 технических писателя, которые пишут тексты для «Яндекса». Боты, в свою очередь, смогут писать для «Яндекс.Карт», «Яндекс.Музыки» и «Яндекс.Такси».

Архитектурное совещание
или работа по контексту

Как известно, архитектор принимает осмысленные эффективные решения не так как проектировщик.
Проектировщик (разработчик) видит условия задачи (дано) и выводит решение (ответ).
Архитектор кроме "дано" имеет еще и понимание контекста задачи.
В контекст входят интересы стейкхолдеров, ограничения, понимание рисков и др.

Эффективность работы архитектора пропорциональна его погруженности в контекст.

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

Что делать если погруженность в контекст не произошло, а решение требуется?

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

Первый вариант обычно дает крайне неоптимальное решение.
Второй вариант - затратен.

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

Опубликована запись последнего архитектурного митапа в IT-one
https://www.youtube.com/watch?v=vD8ixHEugf0&ab_channel=IT_OneInnovation%26Technologies

Профессиональная деформация

Известно, что всякое решение плодит новые проблемы (Закон Мэрфи).
Отсюда одно из определений специалиста:
Специалист не только решает проблемы, но и знает где их стоит ожидать.

Архитектора это касается в первую очередь.
Архитектор активно прогнозирует неприятности на всём пространстве будущей реализации.

Пример:
Дано:
Сотни тысяч клиентов. Каждый порождает небольшой трафик из сообщений, которые необходимо складывать на диск.
Задача:
Обеспечить приемлемую задержку записи.
Решение:
Пишем сообщения пакетами, смешивая в одном пакете сообщения различных клиентов (например в Apache Pulsar)
Порожденные проблемы:
1. Очевидное (классическое противоречие скорость против объем):
Пакет нельзя удалить с диска пока там находится хотя бы одно сообщение. Один медленный клиент будет удерживать большие объемы от утилизации.
2. Не очевидное и понятное только тому, кто с этим уже работал, то есть специалисту:
Служба эксплуатации не сможет определить, какой объем держит каждый конкретный клиент. Как настроить лимиты?

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

И да, про деформацию.
Постоянно приходится объяснять – что я не пессимист. Это работа такая )

О пользе эволюционной архитектуры

Предложив решение, архитектор анализирует возможные риски/проблемы от его внедрения
(где проблема это тот же риск, но который стрельнет наверняка)

Нил Форд описывает различные способы выявления риска:
1. Прототипирование
2. Моделирование (в том числе математическое)
3. Эволюционный подход (пустим в прод. и посмотрим, что получилось)

Кроме этого я бы добавил очевидное:
1. Выявление рисков на основании опыта (по аналогии с предыдущими проектами)
2. Выявление рисков на основании чужого опыта (изучая архитектурные концепты, в частности паттерны)

Понятно, что в каждом конкретном случае арсенал будет более ограничен.
Кто-то не знает паттернов, кто-то не владеет мат. моделями, у кого-то опыта с гулькин нос.

В плане скорости и стоимости принятия решения ранжировал бы так
1. Опыт
2. Паттерн
3. Модель
4. Прототип
5. Проба в проде

Однако, в плане точности предсказания ранжировать достаточно трудно.
Опыт (свой и чужой) может обмануть – у каждого проекта своя специфика.
Математика – слишком абстрактна. Можно упустить значимое.
Прототип тоже не засветит всех грядущих проблем.

Единственно надежный вариант – попробовать.
Дорого и сердито.

Ещё одна классификация архитекторов

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

1. Специалист (опыт)
2. Теоретик (паттерны)
3. Инженер (модель)
4. Кодер (прототип)
5. Экспериментатор (проба в проде)

Надо бы протестировать эту модель на собеседованиях )

В продолжении темы.

Много более осмысленный текст:

Заменят ли боты технических писателей ?
PERPLEXITY
View Concise
It is unlikely that bots will completely replace technical writers in the near future
[2]
[3]
[5]
. While AI and automation tools can be used to assist with certain aspects of writing, such as generating content quickly and accurately
[1]
, they are not yet sophisticated enough to consider all the humanly factors important for good user manuals
[2]
. Additionally, AI tools are not yet able to communicate effectively with subject matter experts or other teams
[2]
.Therefore, while AI and automation tools may change the writing profession in a number of ways, such as making some roles redundant and creating new career opportunities for writers who use them
[3]
, it is unlikely that they will completely replace technical writers in the near future
[2]
[3]
[5]

Джуниор архитектор

Обобщая сказанное выше:
1. Архитектор находит и оценивает риски/проблемы, возникающие при реализации решений.
2. Архитектор находит проблемы не только по условиям задачи (дано), но и во всём контексте задачи.

Существует только три способа обнаружения риска:
1. Быстрый, на основе опыта (специалист)
2. Дорогой, через "попробовать" (экспериментатор, эволюционная архитектура)
3. "Средний путь", через делегирование проблемы (вынос обсуждения на совещания)

Может ли быть полезен начинающий архитектор без опыта, для которого первый вариант не приемлем?

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

В плане оценки архитектурных решений популярны два метода:
1. Классика ATAM от SEI (со многими альтернативными вариантами)
2. Эволюционная архитектура от Нила Форда и к.

В первом случае нас призывают собрать совещание и пригласить туда всех стейкхолдеров.
Во втором написать сценарии верификации архитектуры (фитнес функции).

У меня есть веские основания сомневаться в полезности фитнес функций при выявлении рисков в контексте задачи.

То есть вывод простой:
Джуниор архитектор возможен, но только в режиме непрерывных совещаний по оценке рисков.

#ArchReview

О шарлатанах

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

В моем понимании, "честный экспериментатор" работает "прозрачно", то есть уведомляет бизнес о возможных последствиях и о грядущих нескольких итераций переписывания.
Шарлатан напротив, заверяет стейкхолдеров в успехе и расписывает радужные перспективы:
"Продукт X решит все наши проблемы. Клянусь статьей на медиум".

Если у бизнеса нет денег на опытного архитектора, то почему бы не пойти итерационно (оно же гибко).

Если деньги есть, то не факт, что нанятый архитектор не окажется шарлатаном.
Увы.

То есть эволюционная архитектура выглядит дорогим, но предсказуемым процессом.

Поиск специалиста с опытом - рулетка.

И наконец https://chat.openai.com/
(Я однозначно буду это использовать) )


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

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

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

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

Паттерны и Сюхари

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

Но я все-таки не буду столь категоричен.
Всему своё место. Есть место и архитектурным паттернам.

Если вспомнить японскую модель обучения боевым искусствам Сюхари
(https://ru.wikipedia.org/wiki/%D0%A1%D1%8E%D1%85%D0%B0%D1%80%D0%B8
https://martinfowler.com/bliki/ShuHaRi.html),
то освоение любого материала можно разбить на три ступени:
- Сю (守) — первая ступень, означающая, что надо заучивать всё точно так, как показывает учитель.
- Ха (破) — вторая ступень, на которой ученик обдумывает свои действия, изменяет правила, пробует их нарушать
- Ри (離) — третья ступень, согласно которой нужно освободиться от правил

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

Кроме того, имена паттернов крайне удобны при коммуникации.
Сравните:
- Сервис группировки сообщений
- Message Router
Какое из этих наименований расскажет Вам больше о цели и реализации компоненты ?

#АрхПаттерны

Использование паттернов в общении

Возвращаясь к теме полезности паттернов.
Было замечено, что использование паттернов делает наши обсуждения более лаконичными.

Однако не указано одно важное ограничение - наличие общего тезауруса.

За конкретным термином участники взаимодействия должны видеть одно и тоже.

В наше время это преимущество паттернов почти утрачено.

Паттерны не в моде. Многие их не знают или знают понаслышке.

Попросил я как-то написать брокера...

Таким образом , увы, в начале пишешь текст с указанием паттернов. Потом отдельно каждый объясняешь.