Введение
Закончил чтение третей из списка книг главы «Непрерывное принятие архитектурных решений» курса Системной инженерии. В рамках этого задания я прочитал:
- «Как измерить все, что угодно» Дуглас Хаббард
- «Building Evolutionary Architectures», Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage
- «Software Architecture: The Hard Parts», Neal Ford, Mark Richards, Pramod Sadalage & Zhamak Dehghani
Строго говоря там в списке на чтение есть ещё «Fundamentals of Software Architecture» от того же списка авторов. Но почему-то так у меня получилось что я их с конца начал читать, и в целом по ссылкам и сноскам +/- понимаю о чём в этой книге речь. Но при случае почитаю тоже. И есть ещё книжка по метрикам, но т. к. автор курса предложил на выбор вместо метрик почитать Хаббарда я почитал его. К тому же с Хаббардом знаком по курсу «Статистического мышления», который был у нас на Физтехе. Хотя тоже при случае почитаю и про метрики.
Своим первым впечатлением и инсайтом я уже поделился в заметке: Асинхронный офис, как признание обратного манёвра Конвея
Сейчас будут более частные замтки по отношению к конкретным книгам
«Как измерить все, что угодно» Дуглас Хаббард
Основная идея книги, что измерить — это не обязательно сравнить с каким-то эталоном, т. е. выдать количественный результат измерения ака «Сколько вешать в граммах?», а измерить — значит снизить неопределённость.
И как следствие, если для измерения чего-то нет специальной линейки — это не значит, что не надо мерить. Это значит что измерить можно и грубо, если стоимость измерения ниже ожидаемой выгоды/убытков.
Всё остальное — это сборник разных техник и способов как можно измерить самые разные вещи, которые как будто бы особо и не замеришь. Например, стоимость человеческой жизни.
Второй тейкэвей ценный для меня, который интуитивно и так был понятен, но в книге показан статистически. Что хороша только та экспертная оценка, в которой люди «ставят шкуру на кон» или платят. Интуитивно это понятно, например, при игре в покер. В покер интересно играть только на деньги. Потому что игра на «фантики» — это каждый кон 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 — т. е. задокументировать!
Т. к. я имею дело с киберфизической целевой системой и организацией как своей системой, я опять параллельно чтению думал об менеджменте. И всё что говорится о софте удивительно точно относится и к организации.
Особенно когда идёт речь об архитектурах с большим количеством синхронных запросов к сервису, я так и вспоминаю моменты своей жизни, когда в первые дни отпуска не слезаешь с телефона от этих самых запросов к тебе-как-сервису 
А почему? А потому что, казалось бы, ты назначил другого исполнителя на роль сервиса, звони ему. А большая часть базы данных уехала в отпуск вместе с тобой и вот она тесная связь, и новый исполнитель всё равно продолжает делать запросы к твоей голове. ))
Короче очень жизненно. Очень захотелось органиграммой заняться как следует и сделать рефакторинг по книге.
Заключение
В двух словах об современном понимании архитектуры есть и в курсах. Но в книжках предъявлено современное понимание архитектурных характеристик. Их место в проекте. Описаны роли архитектора и разработчиков. Даны и примеры и обоснования этих примеров. Показана важность документирования! Чуть ли не математически показана важность измерения/метрик. Показано торжество бесконечного всего над водопадом.
UPD 2024-01-19
«Fundamentals of Software Architecture»
Дочитал наконец «Fundamentals of Software Architecture»
Что могу добавить к сказанному? Не пренебрегайте последовательностью прочтения учебников. 
У меня получилось такое забегание вперёд, и когда читал первую книгу много было Aha-моментов, когда «Ах, вот что это было!».
Поэтому для введения в архитектуру лучше с этой книги начинать. Вот что не понравилось, что последняя 3 часть книги — это уже не про архитектуру, а про архитектора, как создателя и какие ему полезны практики для работы. И описываются навыки, которые так или иначе представлены в Интеллект-стеке. Из последней части для меня интересно была только первая глава, о том как писать ADR. Хотя после Software Architecture: The Hard Parts свою нейросетку кое-как натренировал на то какими они должны быть, но получилось исподволь. В Fundamentals of Software Architecture это описывается явно.