Рецензии на книги главы «Непрерывное принятие архитектурных решений»

Введение

Закончил чтение третей из списка книг главы «Непрерывное принятие архитектурных решений» курса Системной инженерии. В рамках этого задания я прочитал:

  1. «Как измерить все, что угодно» Дуглас Хаббард
  2. «Building Evolutionary Architectures», Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage
  3. «Software Architecture: The Hard Parts», Neal Ford, Mark Richards, Pramod Sadalage & Zhamak Dehghani

Строго говоря там в списке на чтение есть ещё «Fundamentals of Software Architecture» от того же списка авторов. Но почему-то так у меня получилось что я их с конца начал читать, и в целом по ссылкам и сноскам +/- понимаю о чём в этой книге речь. Но при случае почитаю тоже. И есть ещё книжка по метрикам, но т. к. автор курса предложил на выбор вместо метрик почитать Хаббарда я почитал его. К тому же с Хаббардом знаком по курсу «Статистического мышления», который был у нас на Физтехе. Хотя тоже при случае почитаю и про метрики.

Своим первым впечатлением и инсайтом я уже поделился в заметке: Асинхронный офис, как признание обратного манёвра Конвея

Сейчас будут более частные замтки по отношению к конкретным книгам

«Как измерить все, что угодно» Дуглас Хаббард

image

Основная идея книги, что измерить — это не обязательно сравнить с каким-то эталоном, т. е. выдать количественный результат измерения ака «Сколько вешать в граммах?», а измерить — значит снизить неопределённость.

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

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

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

Один из интересных инструментов экспертной оценки — это ставки. Существуют букмекерские конторы, которые позволяют делать ставки не только на спортивные мероприятия, но и на любой вопрос.

Ну а применительно к менеджменту метрикой может быть и экспертное мнение управленцев. В книге даны чек-листы, как повысить точность экспертных прогнозов. Нам такие оценки нужны для того, чтобы можно было проектировать «Табло»/dashboard о которых пойдёт речь в курсе Системного менеджмента.

«Building Evolutionary Architectures», Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage

Заострю внимание на вопросе задания:

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

По отношению к уровню системы-создателя, т. е. системной инженерии организации или системного менеджмента — 100% применимо. Причём что особенно интересно, если под «кодом» подразумевать какие-то инструкции: должностные инструкции/чек-листы/кнопочки в софте, то даже эта часть аналогии верна. У меня было пару раз в книге вопросы а как этот момент может мапится на организацию, которые я для себя однозначно не разрешил, но это теории особо не разрушает. Мета-моделью постулируется, что типы будут одинаковые везде, но свои нюансы будут у каждой предметной области.

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

Основной момент, который в фоновом режиме крутился при чтении обеих книг — но если так хороши микросервисы, чем же хорош монолит? Для себя я ответил так. А тем, что можно больше ресурсов тратить на «здесь и сейчас» и меньше отдавать временному предпочтению в будущее. Иначе говоря, когда нам важен time to market, сделать MVP, быстро дойти до прототипа — для всех этих случаев допустим монолит. Получить обратную связь от надсистемы, вот что нам нужно от такой архитектуры. И уже с этим ответом можно взяться за нормальную архитектуру.

Для этого даже введён в употребление термин — a sacrificial architecture. Т.е. «жертвенная архитектура». Которую мы пожертвуем на втором такте бесконечного развития.

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

«Software Architecture: The Hard Parts», Neal Ford, Mark Richards, Pramod Sadalage & Zhamak Dehghani

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

Во-первых, это наверное для программистов очень важно, потому что обсуждаются в этих сценках чаще целевые системы, и уже в связи с ними архитектура софта. Во-вторых, очень хорошо показаны примеры как делаются ADR/Architecture Decision Records в результате обсуждения. Оказалось ничего сложного. По результатам курса я думал это что-то более громоздкое должно быть. Важным в них оказалось именно record — т. е. задокументировать!

Т. к. я имею дело с киберфизической целевой системой и организацией как своей системой, я опять параллельно чтению думал об менеджменте. И всё что говорится о софте удивительно точно относится и к организации.

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

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

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

Заключение

В двух словах об современном понимании архитектуры есть и в курсах. Но в книжках предъявлено современное понимание архитектурных характеристик. Их место в проекте. Описаны роли архитектора и разработчиков. Даны и примеры и обоснования этих примеров. Показана важность документирования! Чуть ли не математически показана важность измерения/метрик. Показано торжество бесконечного всего над водопадом.

UPD 2024-01-19

«Fundamentals of Software Architecture»

Дочитал наконец «Fundamentals of Software Architecture»

Что могу добавить к сказанному? Не пренебрегайте последовательностью прочтения учебников. :sweat_smile: У меня получилось такое забегание вперёд, и когда читал первую книгу много было Aha-моментов, когда «Ах, вот что это было!».

Поэтому для введения в архитектуру лучше с этой книги начинать. Вот что не понравилось, что последняя 3 часть книги — это уже не про архитектуру, а про архитектора, как создателя и какие ему полезны практики для работы. И описываются навыки, которые так или иначе представлены в Интеллект-стеке. Из последней части для меня интересно была только первая глава, о том как писать ADR. Хотя после Software Architecture: The Hard Parts свою нейросетку кое-как натренировал на то какими они должны быть, но получилось исподволь. В Fundamentals of Software Architecture это описывается явно.

6 лайков

Не смотрел на измерение под таким углом.
Эта книга уже в списке чтения, теперь есть дополнительная мотивация прочитать.

Спасибо за рецензии.

Дочитал последнюю книгу из серии по современному пониманию архитектуры

1 лайк

Спасибо. Как раз смотрю на книги с птицами и думала, в каком порядке читать. Начну с Fundamentals.

Поздравляю!

Спасибо!

К тому же с Хаббардом знаком по курсу «Статистического мышления», который был у нас на Физтехе

Вернули фокус, спланировал второй очередью.