Введение
Пост по заданию из курса Системной инженерии относительно литературы, описывающей непрерывное принятие архитектурных решений.
Контекст: работа у меня не связана с разработкой программного обеспечения, я куда ближе к инфраструктурным проектам. Поэтому не всегда хватало доменных компетенций, чтобы разобраться в особенностях описываемых в книжном цикле программных архитектур и шаблонов программного кода.
Читал книги, чтобы, во-первых, повысить свою осведомленность, потому что сейчас "every company is now a software company". Во-вторых, чтобы подглядеть какие-то практики организации архитектуры систем, ведь сейчас разработка программ - самый передовой домен, постоянно пробующий что-то новое. Да и не только систем, но и, по закону Конвея, команд разработки.
Так что принимаю описываемые практики как SoTA, смотрю как можно применят в моих системах, со сдвигом масштаба вверх и вниз, насколько есть смысл.
В начале краткий взгляд под обложку каждой из книг.
Building Evolutionary Architectures
Буквально на несколько дней я "разминулся" со вторым изданием этой книги. Есть ощущение, что в нем материал подали более структурированно. Но рассказывать буду про первое издание.
Прежде всего, утащил из книги попалось шикарное выражение. Объясняет многое в моих интересах: Meta-work is more interesting than work. Work is boring, mundane, and repetitive, whereas building new stuff is exciting.
Принимая во внимание постоянную эволюцию разрабатываемой, доставляемой системы в процессе ее существования, мы должны запланировать, описать, а затем отслеживать ее важные ключевые характеристики, то, что дает ей возможность продолжать приносить пользу, убережет от деградации.
Книга посвящена архитектурной мета-характеристике программных систем, которая названа развиваемость / evolvability. Развиваемость описывает защищенность других архитектурных характеристик во время существования и развития системы.
Отслеживать развиваемость предлагается с помощью прописанных наборов тестов, автоматических и ручных, вместе названных "функции соответствия" / fitenes function. Функция соответственной может быть сложной, комплексной. Но может быть и очень простой, например, один из примеров воплощения фитнес-функции - самый обычный чеклист.
Архитектура состоит из требований, и других характеристик, все они покрываются проверками функции соответствия
Авторы вводят понятие архитектурного кванта - независимо поставляемого компонента с высоким функциональным единством (cohesion), включающий все структурные элементы для функционирования системы.
Рассказывается коротко о разновидностях программных архитектур. Упоминаются плохие инженерные практики - ловушки и антипаттерны.
Fundamentals of Software Architecture
Беру на вооружение еще одну замечательну мысль: There are no wrong answers in architecture, only expensive ones.
Книга показалось полезной именно с точки зрения детального описания архитектур программных систем - с раскладами по теории, примерами, постоянными trade-offs раскладами, без категоричности и навязывания однозначных решений.
Кстати про trade-off: написано, что на практике, при необходимости пожертвовать какой-либо характеристикой, архитекторы чаще жертвуют эксплицитными, то есть вытекающими из потребностей пользователя, оставляя нетронутыми имплицитными, идущими по умолчанию характеристики.
Хорошая картинка - про ширину знаний архитектора (желтые рамки) взамен глубины у разработчика (зеленые линни)
Авторы рассказывают про katas - ситуационные задачки, тренирующие трансляцию проблемы домена в архитектурные характеристики. Записал себе в todo лист: начать использовать подобные katas, со своей спецификой, на своей работе со своей командой.
Отдельная глава: про анализ архитектурных рисков. Кстати, довольно редко эта тема в любых современных инженерных практиках описывается явным образом, отдельно. Чаще подразумевается, что мы снижаем риски, за счет коротких итераций, постоянной обратной связи и высокой скорости реагирования на ситуацию. Что верно только частично. Поэтому такой главе - порадовался.
Software Architecture Metrics
Про моделирование: The statistician George Box once wrote that “all models are wrong,” but added that “still some are useful.”
Это не книга в понимании сквозной истории, цели, сквозном стремлении выстроить у читателя новые нейронные связи. Просто набор статей по теме. Какие-то полезны и интересны, какие-то скучны и откровенно проходные. Некоторые из глав/статей их них ссылаются на хорошие книги и пересказывают часть идей оттуда, например: "Accelerate", "The Checklist manifesto".
Четыре метрики из книги "Accelerate":
- частота развертывания / deployment frequency
- время применения изменений / lead time for changes
- уровень критичных ошибок в изменениях / change failure rate
- время на восстановление сервиса / time to restore service
Первые две метрики - в паре пропускная способность развертывания, development throughput.
Вторые две метрики - в паре стабильность сервиса, service stability.
Непрерывный архитектурный цикл
Правила применения измерений (метрик) в проекте:
- начинай с малого
- измеряй то, что важно
- применяй полученные знания
- начинай как можно раньше
- делай измерения видимыми
- делай измерения постоянными
Software Architecture - The Hard Parts
Классика: All things are poison, and nothing is without poison; the dosage alone makes it so a thing is not a poison. Paracelsus
Книга с элементами бизнес-романа, рассказывающая о возможных развилках / trade-offs в процессе (непрерывном!) принятия архитектурных решений.
Дается модель с сагами - классификацией архитектур в зависимости от выбранных типов коммуникации, взаимодействия, координации и связывания.
Дается привязка архитектурной концепции к коммерческой возможности проекта: Архитекторы не должны разбивать систему на меньшие части, пока не существует бизнес-потребности. Основные бизнес-драйверы:
- скорость вывода на рынок / speed-to-market or time-to-market
- достигается через гибкость/agility
- гибкость- составная характеристика, включает, к примеру, ремонтопригодность, тестируемость и возможность развертывания / maintainability, testability, and deployability
- достигается через гибкость/agility
- достижение конкурентных преимуществ
- достигается через скорость вывода на рынок, плюс масштабируемость, общую доступность приложений и отказоустойчивость.
Факторы модульности и взаимосвязь между ними
В книге дается обзор архитектур баз данных. Подчеркивается, что это отдельный домен со своими компетенциями, ролями, архитектурными паттернами. Хотя, понятно, и тесно связанный с программной архитектурой.
Как вывод ключевые момент при работе с архитектурой:
- Удерживать внимания
- Документировать развилки
- находить запутанные между собой части
- анализировать запутанность
- изучить развилки, определяя влияние изменений на соседние системы
- Обсуждать с командой проблемы и выбранные решения
Безмасштабность архитектурных решений
Попробую покрутить описанные в книгах практики, применить их к системам на разных уровнях.
Сначала вверх:
- Общество. Вспоминаю про фитнес-функцию, вопрос можно сформулировать так для общества как эволюционирующей и развивающейся системы, какими будут фитнес-функции, которые позволят убедиться, что у нас по прежнему остается "то, которое замыслено" общество? Как минимум, такая функция должна быть, и информация должна распространться. Было бы странно, если бы тестируемое ПО целенаправленно влияло на запросы тестовой функции. А вот в обществе намеренное или ненамеренное искажение информации при попытках замерить какие-то метрики - нередкая вещь. Вспоминаем австрийскую эконочесескую школу, которые утверждают, что свободное распространение информации - необходимое условие для экономеского развития.
- Сообщество. Для моей роли сообщество - это рынок заказчики, подрядчики, вендоры на B2B рынке в стране. Размер этой социальной группы невелик, максимум одно рукопожатие до любого. Здесь приходят на ум две концепции:
- достижение конкурентных преимуществ перед конкурентами через скорость вывода продукта на рынок, модульность, масштабируемость, общую доступность и отказоустойчивость предлагаемых систем. То есть архитектурные решения, концепция систем критична для нашей роли в этом сообществе.
- развиваемость, стабильность, устойчивость моей организации как системы создания. Ведь процесс крупных продаж на B2B рынке небыстр, и преимущство получают компании, играющие вдолгую, помогающие принять правильное решение клиенту, а не закрыть продажу во что бы то ни стало здесь и сейчас. Снова помним про фитнес-функцию, чтобы в долгом процессе не потерять цель. Полезна в этом отношении будет книга "Продажи по методу СПИН" Нила Рекхэма.
- Организация. Вспоминая четыре метрики из книги "Accelerate", переказанные в Software Architecture Metrics, одним из ключевых процессов для поддержания развиваемости предпрития будет управления конфигурацией. Как гласит одна из политик в книге "Configuration Management for Senior Management": "скорость отработки изменений рассматривается как критичная для прибыли компании".
- Личность. Интересно, что будет тут фитнес-функцией? Видимо, планы на предстоящие периоды с обязательной рефлексией и анализом. Крайне желательно - в публичных постах. В выстраивании таких функций у меня пока явный пробел. Или, как аккуратно говорят аудиторы систем менеджмента качества, "точка роста".
- Существо. Здесь, кажется, все интересное еще впереди. Впоминается книга-расследование "Дурная кровь" Джона Каррейру про "Theranos". Это американский стартап, который несколько лет назад ярко и громко спекулировал идеей быстрой и удобной фитнес-функции на уровне организма - мгновенных клинических анализах крови. Обещано было, что анализы эти будут выдавать десятки метрик. Огромные инвестиции, которые до последнего момента "Theranos" получал, говорят об интересе высокотехнологичного сообщества/community к таким продуктам. Надеюсь, что следующие попытки создания таковых: а) будут и б) будут более успешными.