Про принятие архитектурных решений
#мысливслух

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

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

Если кажется, что если есть выбор, то, скорее всего, какие-то требования и ограничения просто еще не выявлены. И вот это, как по мне, самая сложная часть работы архитектора. Принять архитектурное решение таки нужно, но в условиях недостаточных знаний о реальных требованиях и ограничениях невозможно сделать это обоснованно, Приходится опираться на ненадежный фундамент - опыт, экспертное мнение и ощущения в особо чувствительных частях тела. Обосновать такое решение сложно иначе, чем "я художник, я так вижу". Некоторые прячут это за более красивыми формами "это отраслевой стандарт", "все так делают", "у меня 50 лет опыта", но сути это не меняет.

снова #мысливслух

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

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

На выпускном экзамене в школе милиции дали задание
вставить деревянные пирамиду, шар и кубик в соответствующие отверстия в доске.
Экзаменуемые разделились на две категории: очень глупые и очень сильные.

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

Но та ли эта сила, которую мы ждем от архитектора?

А вот и запись доклада подъехала

Выложили запись доклада Романова Бориса на тему «Роль аналитика в процессе создания сложных информационных систем»

В докладе Бориса Романова, выступавший на конференции Systems Education, подчеркнул важность аналитика в балансировке между требованиями заказчика и возможностями разработки. Он также описал различные модели и инструменты, используемые аналитиком для моделирования, поведения системы и предметной области, что помогает в создании эффективных информационных систем.

Тайм-кол доклада:
00:00 О себе
02:34 Разработка сложных систем
08:17 При чём здесь аналитика?
09:53 Информационные системы — это способ изменить мир
13:17 Набор связанных моделей
16:15 Моделирование ожидаемых изменений в мире
20:59 Закон Голла
21:31 Моделирование полезных инструментов: Story Mapping
22:48 Моделирование поведения системы
27:42 Моделирование предметной области
30:18 Инструментарий
31:40 Моделирование в процессе: Создание MVP
33:38 Непрерывное развитие системы через моделирование
34:18 Экспресс оценка изменений на основе изменения моделей
35:39 Заключение
36:41 Ответы на вопросы

Посмотреть можно на нашем YouTube-канале

#вебинар

#мысливслух
продолжение. Начало тут

Если продолжить эти рассуждения, то становится понятно на чем базируется "сила компетенции архитектора".

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

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

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

Т.е. базис, фундамент архитектурной работы - это арсенал решений + знание интересов, которые нужно учитывать

И, соответственно, становится понятным трек развития компетенции ИТ-архитектора.

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

Во-вторых - накопление подходов, паттернов, приёмов для решения типовых задач. Уверяю вас, лучше тратить свою творческую энергию на создание действительно уникальных, нетипичных решений. А для решения задач, уже ставших типовыми, обычными, стандартными, банально для экономии времени нужно использовать обычные, типовые, стандартные решения. Брокеры сообщений для асинхронной коммуникации. Базы данных - для хранения данных. API для синхронной коммуникации. Какой именно брокер, какая именно СУБД - это уже вопрос из предыдущего пункта, как говорится "зависит от контекста" :-)

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

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

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

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

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

Архитектура архитектуры (физика явления)

С точки зрения физика архитектура объясняется просто.)

— Система имеет некоторую энтропию (мера хаоса).
— Эта энтропия тем выше, чем сложнее система, то есть чем больше система содержит элементов.
— Высокая энтропия порождает высокую неопределённость. Мы не можем предсказать, как поведёт себя система в дальнейшем, и чего нам ждать от неё.
— Устранить риск можно, получив информацию об элементе системы. Чем больше информации мы имеем, тем меньше у системы шансов «взбрыкнуть».
— Однако для полного контроля над системой нужна вся информация об её элементах и об элементах, с которыми система взаимодействует. Это трудно достижимо.
— Решение: связываем элементы системы, подчиняем их нашим правилам. Чем меньше у элементов степеней свободы, тем предсказуемее их поведение.
Получившийся набор правил нарекаем архитектурой.
Если система реализует архитектуру, то её энтропия снижена и вместе с энтропией смягчены риски.

Ну а архитектор в этом случае — борец с энтропией.)

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

Мне же видится, что все подходы - это проявления встреченного когда-то в книге по объектно-ориентированному проектированию простого принципа "непрерывности" кода.

Еще помните что такое непрерывность? вот это самое - "для любого эпсилон больше нуля существует дельта, такая, что ...". Эта нудная и формальная математическая формулировка скрывает простую суть: у непрерывных функций малые изменения параметров приводят к малому изменению значения. У "непрерывного кода" похожее свойство - малые изменения требований приводят к малым изменениям кодовой базы.

Казалось бы, что может быть проще? Но, как говорится, есть нюанс. Что такое "малые изменения требований" каждый стейкхолдер понимает по своему. Для кого-то это смена используемой СУБД на другую (подумаешь, изменилась одна строчка в ТЗ!) - и вот для обеспечения непрерывности кода нужно использовать СУБД-независимую прослойку и добро пожаловать в ORM. "Малое изменение" в другом случае - это изменение атрибутивного состава сущностей - и вот мы уже на пути генерации интерфейсных форм по описанию модели.

Разбиение кода на части, компоненты, модули (что, собственно, и является существенной частью архитектуры) похоже на переборки на подводной лодке, это препятствия на пути распространения изменений. Если разбиение сделано удачно, т.е. топология разбиения кода соответствует точкам концентрации изменения требований, то изменять код относительно несложно, изменения локализуются в модулях. Проектирование такого разбиения невозможно без понимания динамики изменения требований, которое возникает только при глубоком погружении в предметную область. Чтобы сделать толковую архитектуру мало знать какие требования к системе предъявляются сейчас. Важно уметь предугадывать, какими они станут потом, или хотя бы в каких местах будут меняться.

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

Недавно слушал отличную лекцию про сценарии сериалов и про особенности кинопроизводства. Я давно интересуюсь способом организации производства в других отраслях, и кино, мне кажется, во многом похоже на ИТ (ну или ИТ на кино, всё-таки киноиндустрии уже больше ста лет, а ИТ всё ещё молодое 😉).

Вот смотрите:

Всё начинается с логлайна. Это описание идеи фильма или сериала в 1-2 предложениях. По нему продюсеры принимают решение — брать сценарий или не брать. Структура логлайна: герой — проблема — цель героя — конфликт. А, каково? В принципе подходит для описания концепции ИТ-продукта — для него есть своя формула, похожая.

Идеи фильмов делятся на high-concept и low-concept. High-concept — это такая идея, которой ещё не было, и которая захватывает сразу с логлайна. В нашем понимании — прорывной стартап. Low-concept — обычная идея, знакомая всем, из которой, тем не менее, может что-то получиться за счет каких-то особенных мелочей или общей синергии.

После логлайна (или вместе с ним) пишется синопсис. Это — короткое описание всей истории, на 1-2 странички + особенности производства + формат, жанр, аудитория, бюджет места съемок, продолжительность и т.д. Короткий, но основной продающий документ. В ИТ это концепция проекта. У нас на курсах, например, на базовом "Разработка требований в ИТ-проектах" используется шаблон как раз на 2 страницы.

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

Дальше идёт поэпизодный план — он уже имеет размер 20-30 страниц, выстроен по сценам и актам, и в том порядке, в котором их увидит зритель. Диалогов в нём всё ещё нет! Ну может только ключевые реплики. Зато есть все сюжетные повороты. В поэпизодном плане проверяется структура истории, пересечение линий персонажей и их взаимовлияние, и продумываются решения отдельных сцен — мы в этой сцене хотим, чтобы зритель понял вот это, а как мы это покажем? Как эта сцена двигает сюжет или раскрывает персонажей? В большой ИТ-системе это соответствует схеме навигации с описанием экранов (но без дизайна!)

И уже после этого пишется сценарий со всеми диалогами (причем часто сюжет придумывает один человек, а диалоги пишет другой, вот это разделение труда!). Диалоги пишут вообще в последний момент, и могут переписать прямо на площадке. Это как сценарии вариантов использования и конкретные объекты данных — самый детальный уровень проработки.

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

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

Или костюмер говорит: если вы хотите в этой сцене героя облить супом, то нужно будет минимум 3 экземпляра его костюма, а лучше 5.
Дрессировщик говорит: тут у вас обезьяна со злостью стучит по решетке. Это можно, но потом ей нужно будет недели две успокаиваться, имейте в виду.
Продюсер говорит: тут у вас гонки, но это очень дорого, давайте что-то другое.

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

Мне кажется, это очень классная практика, и её нужно повсеместно в ИТ внедрять. Вот именно в виде синхронной читки документов всеми цехами. Вообще на планировании спринта именно это должно происходить, но на практике, кажется, идея потеряна, а стоило бы на всех проектах ввести!

Годная статья про GIN индексы в #PostgreSQL
https://pganalyze.com/blog/gin-index

Давно хотел разобраться как оно работает, да все руки не доходили. Оказалось, что все не так уж сложно. Но интересно.
Прямо вспомнились 1990-2000-е годы, Cognitive Technologies, Электронный Архив (!) Евфрат, организация индекса в иерархической СУБД НИКА...

Имеем: Система А обращается к системе B, которая состоит из N экземпляров с отдельными урлами (B1, B2, B3 и т.п.)
Если мы точно знаем, на каком экземпляре обрабатывается запрос, то можем обращаться напрямую к нужному экземпляру, например A -> B3.
Но если точно не знаем, то есть система M, которая по параметрам запроса умеет определить правильный экземпляр B и адресовать запросу туда, куда нужно. Т.е. запрос идет так:
A —[запрос]—> M —> {B1 | B2 | B3 .... }. И, соответственно, есть накладные расходы на вычисление правильного экземпляра, т.е. такой запрос, по идее, должен выполняться дольше, чем прямой.

Однако, если верить замерам времени выполнения на стороне системы А, то для одного (!!WTF??) из экземпляров B ситуация ровно обратная - прямые запросы выполняются примерно на 100 мс дольше чем через промежуточный маршрутизатор. Для остальных экземпляров ситуация обратная (т.е. ожидаемая).

Почему может быть такой эффект?
Накидайте гипотез, будем проверять.

Вдруг вы еще не слышали - с 14 по 18 октября пройдет онлайн-конференция Podlodka Techlead Crew, посвященная вопросам проектирования надёжных систем.

Мне лично показались потенциально интересными:
- стартовый доклад про ключевые архитектурные принципы обеспечения надёжности (Александр Поломодов (Т-Банк) и Олег Бондарь (Яндекс) )
- доклад про фичетоглы от Николая Тимонина. Тема вроде бы уже не новая, но интересно послушать прикладной опыт.
- Подкупает название доклада Александра Агейченко «Надежный как кирпич» и цифры 99.9999% в описании.
- Интересно послушать рассуждения Филиппа Дельгядо про надежность взаимодействия сервисов, на которую заметно влияет кафка между ними.

Да, честно говоря, всё бы послушал, если удастся выбрать время :)

Если тоже соберетесь - то организаторы подвезли промокод на скидку в 500р : techlead_crew_7_SeusjW

— — — — — —
https://podlodka.io/techcrew

Что такое Eventual Consistency и как с ней бороться.

Когда процессоры были большими, базы данных - маленькими, а приложения - монолитными (а то и вообще пользовательскими 😉) все активно топили за строгую согласованность. В самом деле, удобно - целостность данных обеспечивается, что один записал - то другой и прочитал, красота, да и только. Тогда придумались транзакции, ACID и прочие премудрости, сводящиеся к тому, что Strong Consistency - это хорошо и правильно.

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

Хотел коротко, не получилось, пришлось освоить telegraph.
Продолжение тут https://telegra.ph/CHto-takoe-Eventual-Sonsistency-i-kak-s-nej-borotsya-11-09

Случайно занесло на #softweekend. Спасибо родной компании за билет.Глоток свежего воздуха социализации после заточения удаленки ;) Доклады, правда, послушать почти не получается пока, зато получается много потрепаться 😉. Если кто-то ещё из подписчиков тоже тут - заходите пообщаться.

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

Больше всего голосов набрал вопрос "как из разработчика стать архитектором", так что начнем с него.

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

Я старался покороче, но все равно получилось длинновато. Я не верю, что кто-то будет читать лонгрид, поэтому будет несколько постов.

Поехали!

Итак, "я разработчик, хочу расти в архитектора, куда смотреть, что изучать?"

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

Со стороны разработчиков часто может показаться, что архитекторы - это такие странные люди, которые приходят со своими странными и не всегда понятными идеями и говорят, как нам надо жить и что мы должны делать. И это иногда, наверное раздражает. Чем же занят архитекторы и откуда у них берутся идеи и почему компании стремятся их завести?

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

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

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

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

Или другая, не менее частая история.

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

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

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