В современных реалиях разработки ПО классическая модель архитектора как единоличного автора решений утрачивает эффективность. Книга предлагает практический подход к архитектуре как к непрерывному процессу принятия решений с участием всей команды. Вводится понятие архитектурно значимых решений, и даются инструменты для работы с ними. Основной метод — «процесс архитектурных советов», сочетающий скорость разработки с архитектурной целостностью через быструю обратную связь. Читатель освоит документирование решений (Architecture Decision Records), организацию архитектурных форумов, формулирование тестируемых нефункциональных требований и построение технологических радаров.
Для архитекторов программного обеспечения
Роль архитектора ПО постоянно эволюционирует. Системы усложняются. Командам становится всё труднее взаимодействовать с архитектурами, которые они разрабатывают, запускают и развивают. Специалисты, традиционно выступающие в роли архитекторов, часто не успевают быть везде, где нужно. Просто слишком много работы над архитектурой, и ситуация достигла критической точки.
Но есть способ лучше. Автор книги показывает, как архитекторы и команды разработчиков могут работать сообща над созданием и развитием более эффективных архитектур систем. Благодаря представленным методам вы сможете сформировать новый образ мышления и выйти на новый уровень создания по-настоящему эффективных систем
С помощью этой книги вы:
- Поймёте новую динамику, влияющую на разработку современного ПО
- Изучите подход, объединяющий архитектуру ПО и разработку
- Поймёте фундаментальную взаимосвязь между решениями, советами, архитектурой и обратной связью от используемых систем
- Научитесь внедрять практики, способные максимизировать выгоду и снизить риски
- Сформируете подход, в котором будут учитываться ваша архитектура, навыки каждого сотрудника и культура вашей организации
Эндрю интуитивно понимает архитектуру. Перед вами книга, полная практической мудрости, основанная на обширном опыте, с захватывающим повествованием и оформленная так, чтобы донести суть того, что такое архитектура, чем она не является и как воплотить ее в жизнь.
Гради Буч, член IBM Fellow
Лучшие архитектуры ПО создаются усилиями всего коллектива. В книге Эндрю представлена практическая реализация этого видения: вовлечение широкого круга людей и ведение точного учета принятых решений.Мартин Фаулер, главный научный сотрудник компании Thoughtworks
Эндрю Хармел-Лоу — технический директор компании Thoughtworks, специализирующейся на предметно-ориентированном проектировании, крупномасштабной модернизации и организационных преобразованиях. Активный сторонник открытого исходного кода. Делится своим опытом через онлайн-тренинги, статьи, публичные выступления и наставничество.
Книгу “Программная архитектура: практика командного принятия решений” можно купить в нашем интенет-магазине.
Отзывы.. 15
Предисловие. 21
Введение. 23
Кому предназначена эта книга. 25
Зачем я написал эту книгу. 27
Содержание книги. 29
Условные обозначения. 29
Дополнительные материалы.. 30
Онлайн-обучение в O’Reilly. 30
Как с нами связаться. 30
Благодарности. 31
ГЛАВА 1. Централизованные практики архитектуры
в децентрализованном мире. 33
Создание успешной архитектуры ПО в равной степени зависит от практик
и конечного результата. 33
Как выглядят традиционные практики архитектуры?. 35
Архитекторы в “башне из слоновой кости”. 36
Практико-ориентированные архитекторы.. 37
Что не так с этими традиционными подходами?. 38
Пять переломных моментов, раскрывающих мощь ПО.. 39
Влияние пяти революций на практики разработки архитектуры.. 43
Рассвет децентрализации. 44
Закат практик разработки централизованной архитектуры.. 49
Что должна предлагать новая практика архитектуры?. 54
Ни один подход не защитит нас от фактора хаотичности. 55
Архитектуры должны учитывать неопределенность. 55
Архитектура должна допускать эмерджентность. 57
Вывод. 60
Часть I. Первые принципы.. 61
ГЛАВА 2. Практика создания архитектуры означает принятие решений. 63
Решения — главный компонент архитектуры ПО.. 64
Что представляет собой архитектурное решение?. 65
Структура. 65
Кросс-функциональные характеристики. 66
Зависимости. 67
Интерфейсы.. 67
Техники построения. 67
Некоторые примеры архитектурных и неархитектурных решений. 69
Кто принимает архитектурные решения?. 71
Значимые архитектурные решения. 71
Что делает архитектурное решение “значимым”?. 71
Что не следует учитывать в контексте архитектурной значимости?. 74
Архитектурная значимость в контексте развернутого ПО.. 75
Некоторые примеры значимых архитектурных решений. 77
Вывод. 79
ГЛАВА 3. Масштабные решения. 80
Процессы принятия решений. 80
Этап 1: потребность в принятии решения. 81
Этап 2: акт принятия решения. 81
Этап 3: внедрение решения. 83
Где лежит баланс сил в процессах принятия решений?. 83
При традиционных архитектурных подходах команды недостаточно
вовлечены в выбор вариантов решений. 85
Масштабные процессы принятия решений. 86
Стандартные подходы к принятию масштабных решений. 86
Процессы принятия решений в революционном мире разработки ПО.. 94
Вывод. 98
ГЛАВА 4. Процесс архитектурных консультаций. 99
Потребность в быстрых и децентрализованных процессах принятия решений. 99
Процесс архитектурных консультаций: одно правило, две группы консультантов и один контракт 100
Процесс архитектурных консультаций является быстрым.. 102
Процесс архитектурных консультаций является децентрализованным.. 103
Процесс архитектурных консультаций порождает заключение общественного договора 105
Два примера процесса архитектурных консультаций в действии. 106
История 1: команда разработки решает использовать релизные переключатели 107
История 2: архитектор решает устранить проблему с рабочим процессом.. 114
Центральная роль консультаций. 122
Совет как совокупность предполагаемого направления и аргументации. 122
Советы помогают тем, кто выбирает варианты и принимает решения. 125
Подотчетность приходит с принятием решений, а не предоставлением совета 126
Важность диалога. 128
Важность доверия. 129
Вывод. 130
ГЛАВА 5. Внедрение процесса архитектурных консультаций. 131
Первые шаги. 131
Если у нас уже есть полномочия принятия решений. 131
Если у нас нет полномочий принятия решений. 132
Следует начинать с малого, независимо от отправной точки. 134
Преодоление сложностей на ранних этапах. 136
Объяснение процесса архитектурных консультаций всем участникам.. 136
Обращение за советом к нужным людям.. 136
Вопросы следует адресовать нужным людям и искать ответ на вопрос “Почему?” 138
Следует явно объяснить, кто несет ответственность за каждое решение. 140
Недостаток уверенности относительно процесса архитектурных
консультаций. 142
Нехватка уверенности в ваших и чужих навыках принятия решений. 142
Нехватка уверенности в том, что нужно обращаться за советом
и предлагать его. 143
Нехватка уверенности в том, что мы знаем всё, что происходит. 143
Вывод. 144
ГЛАВА 6. Архитектурные записи решений. 145
Введение в архитектурные записи решений. 145
Структура архитектурных записей решений. 147
Название. 148
Метаданные. 149
Решение. 150
Контекст. 151
Варианты.. 152
Результаты.. 153
Совет. 154
Создание шаблона архитектурной записи решения. 156
Этап 1: создадим пустую архитектурную запись решения и набор связанных метаданных 156
Этап 2: внесем сведения о контексте. 157
Этап 3: сформируем список вариантов и спрогнозируем возможные результаты 161
Этап 4: предложим выбранный вариант. 165
Использование архитектурных записей решений для упрощения процесса консультаций 167
Когда и как обращаться за советами. 167
Создание раздела “Совет”. 169
Сбор советов. 170
Внесение изменений в архитектурную запись решения для отражения вклада других лиц 172
Принятие решения и итоговый вариант архитектурной записи. 177
Выбор варианта решения. 177
Составление раздела “Решение” и обновление названия. 179
Изменение статуса архитектурной записи решения на “Принято”. 180
Оглашение решения. 181
Жизненный цикл архитектурной записи решения. 181
Стандартные статусы: “Черновик”, “Предложено”, “Принято”
и “Заменено”. 181
Нестандартные статусы архитектурных записей решений. 182
Управление архитектурными записями решений. 184
Основополагающие аспекты управления архитектурными записями решений. 184
Архитектурные записи решений на вики и RTF-файлы в системе контроля версий 185
Архитектурные записи решений в тикет-системах. 186
Контроль над архитектурными записями решений. 187
Вывод. 188
Часть II . Взращивание и развитие культуры децентрализованного доверия 189
ГЛАВА 7. Децентрализация доверия вместо иерархии. 191
Перенос ответственности и подотчетности. 192
Большинство традиционных методов управления устаревают. 192
Процесс консультирования совместим с существующими структурами корпоративной архитектуры 193
Отчетность через архитектурные записи решений — сдерживающий
фактор против безрассудства. 194
Команды не обязаны принимать решения. 194
Раскрытие потенциала пространства для архитектурных практик. 195
Создание условий для формирования культуры обучения и доверия. 196
Два примера доверия (или его отсутствия) в действии. 197
Нам сложно представить возникновение культуры доверия и обучения. 197
Необходимо тщательно взращивать культуру доверия и обучения. 198
Понимание динамики изменений в организациях разного размера. 198
Использование вспомогательных элементов для защиты пространства
для доверия. 202
Защита пространства для практик архитектуры.. 202
Отсутствие стандарта для вспомогательных элементов. 203
Адаптация вспомогательных элементов под себя. 203
Netflix: пример мышления, основанного на поиске потока. 205
Опасность сирен, призывающих к определенности и предсказуемости. 206
Поиск оптимального потока для нашей организации лежит через эксперименты 207
Вывод. 207
ГЛАВА 8. Консультативный форум по архитектуре. 209
Знакомство с консультативным форумом по архитектуре. 209
Простая постоянная повестка дня. 210
Чем консультативный форум отличается от совещаний в традиционных подходах 211
Проведение консультативного форума по архитектуре. 212
Перед консультативным форумом.. 212
Обнародование программы.. 213
Открытие сессии консультативного форума по архитектуре. 213
Презентация архитектурной записи решений. 214
Предложение и получение совета. 214
Документирование совета. 215
Социальная динамика на консультационном форуме. 215
Взаимодействия по вопросам архитектуры изначально являются состязательными и иерархическими 216
Коалесцентная аргументация: альтернатива состязательной. 217
Процесс архитектурных консультаций и ADR как коалесцентный
подход. 219
Консультативные форумы создают мощную групповую динамику. 220
Опыт для предоставляющих советы.. 221
Опыт для тех, кто ищет совета. 222
Опыт для обучающихся наблюдателей. 223
Совместное участие в творческой деятельности. 224
Консультативный форум по архитектуре способствует формированию концептуальной целостности и социальной сплоченности. 225
Децентрализованное выполнение при централизованной координации. 226
Глубокая экспертиза в предметной области: когда централизация
работает лучше. 228
Повышение социальной сплоченности и доверия за счет прозрачности. 229
Ритм как ритуал усиления. 233
Запуск процесса консультаций с помощью консультативного форума. 235
Условия ведения (ToR) 235
Если вы используете консультативный форум для инициации процесса консультаций 236
Кто должен организовать первый консультативный форум?. 236
Чем первый консультативный форум будет отличаться от последующих. 237
Вывод. 238
ГЛАВА 9. Проверяемые кросс-функциональные требования и технологическая стратегия 240
Важность согласованности внутри организации. 240
Согласованность не гарантирует эффективность. 241
Выявление недостаточной организационной согласованности. 244
Четыре способа обеспечения согласованности. 246
Согласованность не оставляет места для сюрпризов. 247
Минимальное жизнеспособное соглашение. 251
Кросс-функциональные требования. 252
Технологическая стратегия. 262
Работа над формированием минимального жизнеспособного соглашения организации 269
Вывод. 269
ГЛАВА 10. Совместно разрабатываемые архитектурные принципы.. 270
Архитектурные принципы должны формировать все участники процесса. 270
Примеры архитектурных принципов. 271
Признаки хороших архитектурных принципов. 273
Признаки плохих архитектурных принципов. 274
Принципы могут оказаться замаскированными кросс-функциональными требованиями 275
Архитектурные принципы дополняют процесс консультаций
и архитектурные записи решений. 276
Фиксирование архитектурных принципов на семинаре по принципам.. 277
Подготовка материалов для вашего семинара по принципам.. 278
Организация семинара по принципам.. 282
Проведение семинара по принципам.. 286
Представление ваших готовых принципов. 295
Поддержание полезности принципов. 298
Обратная связь после принятия решений должна влиять на архитектурные принципы 298
Обновление и поддержка принципов. 300
Обратная связь после принятия решений может повлиять на техническую стратегию 302
Вывод. 303
ГЛАВА 11. Использование технологического радара. 304
Отслеживание технологических тенденций и учет рекомендаций. 304
Технологические радары как источник рекомендаций. 305
Как работает технологический радар Thoughtworks. 306
Ваш внутренний технологический радар будет иметь другую структуру. 310
Место вашего радара в процессе консультаций. 310
Создание собственного технологического радара. 313
Сбор информации об эхосигналах. 314
Сортировка и валидация эхосигналов. 317
Фокусировка эхосигнала. 319
Позиционирование эхосигналов. 322
Документирование эхосигналов. 323
Публикация радара. 323
Обновление ваших эхосигналов. 325
Периодическая развертка радара. 326
Специальные обновления, основанные на совместном опыте. 328
Фиксация предыдущих эхосигналов и их истории. 329
Вывод. 329
Часть III. Поиск собственного пути в процессе принятия решений. 331
ГЛАВА 12. Искусство принятия решений. 333
Важность более мягкой стороны.. 333
Фрейминг контекста. 333
Исключение так же важно, как и включение. 334
Вопросы, помогающие усовершенствовать фрейминг. 336
Вовлекайте правильные заинтересованные стороны.. 337
Продуманные варианты и их последствия. 338
Не позволяйте фрейму ограничить вашу креативность. 338
Поиск вдохновения. 340
Уточнение контекста и вариантов решения с помощью советов. 341
Развитие навыков метапознания. 343
Упражнение 1. Поделитесь своими идеями. 344
Упражнение 2. Вы реагируете или отвечаете?. 344
Упражнение 3. Намеренно обращайтесь за советом, который
противоречит вашим представлениям.. 345
Умение справляться с несговорчивыми личностями. 346
Выбор вариантов решения. 349
Преодоление страха. 350
Преодоление личных предубеждений. 352
Принятие решения. 353
Когда решение принимаете вы.. 353
Когда решение принимают другие. 354
Вывод. 357
ГЛАВА 13. Борьба с архитектурной изменчивостью.. 358
Влияние изменчивости на практику архитектуры.. 359
Изменчивость затрудняет разработку систем.. 359
Изменчивость как основа разработки ПО.. 362
Эффективная работа с архитектурной изменчивостью.. 363
Борьба с изменчивостью путем быстрого принятия и тестирования
решений. 365
Углубленная проверка решений с помощью функционального контекста. 365
Метод “ходячего скелета” для тестирования решений в их
функциональном контексте на самых ранних этапах. 366
Борьба с изменчивостью через небольшие решения. 368
Влияние архитектурных решений на будущий поток. 377
Хорошая техническая инфраструктура позволяет принимать небольшие решения 377
Хорошая социотехническая инфраструктура также позволяет принимать небольшие решения 378
Используйте процесс консультаций, чтобы разделить решения по потоку. 379
Использование изменчивости для борьбы с рисками и выявления ценности. 380
Лучше быстро и неправильно, чем медленно и правильно. 380
Следите за выбросами. 381
Сначала упорядочьте наиболее ценные решения. 382
Вывод. 383
ГЛАВА 14. Изменчивость и взаимосвязанность решений. 385
Противодействие изменчивости. 385
Введение в спайки. 386
Спайки помогают справиться с архитектурной изменчивостью путем меньших затрат 387
Где применяются спайки в процесс принятия решений?. 388
Использование спайков для составления архитектурных записей
решений. 388
Архитектурные записи решений на основе спайков по-прежнему должны проходить через процесс консультаций. 394
Изучение взаимосвязи между принимаемыми решениями. 395
Решение — это последовательность. 395
Решение — это обратная иерархия. 399
Атомарные решения. 409
Принятие решений оказывает двунаправленное воздействие. 412
Взаимосвязанные решения являются социально сложными. 415
Вывод. 417
Часть IV. “Социальный” аспект нашей архитектурной практики. 419
ГЛАВА 15. Передача власти и подотчетности. 421
Переход власти никогда не бывает простым.. 421
Переход власти с позиции тех, кто ее получает. 423
Все ли верят, что у них есть право решать?. 423
Все ли понимают свою подотчетность?. 426
Почему люди не пользуются доступной им властью?. 430
Важность безопасности. 431
Переход власти с позиции тех, кто должен ею поделиться. 445
Страх тех, кто отдал власть. 446
Поведение тех, кому не нравится факт разделения власти. 449
Передача власти вызывает дискомфорт. 452
Вывод. 453
ГЛАВА 16. О лидерстве. 454
Ошибочные представления о лидерстве. 454
Заблуждение 1: лидерство — это врожденное качество. 455
Заблуждение 2: лидерство неразрывно связано с иерархией. 456
Заблуждение 3: лидерство носит однонаправленный характер. 456
Заблуждение 4: лидерство — это управление. 457
Что такое лидерство. 458
14 ключевых принципов Деминга. 459
“Служащее лидерство” 460
Адаптивное лидерство. 461
Лидерство через подход “лидер – лидер”. 464
Трудности при внедрении лидерства через подход “лидер – лидер”. 466
Потребность в постоянном моральном лидерстве. 473
Реагирование на моральные вызовы.. 474
Проявляйте внимание, но не привязывайтесь ко всем культурам
в компании. 476
Отсутствие “постоянных лидеров”. 477
Вывод. 478
ГЛАВА 17. Адаптация процесса консультаций под нашу организацию.. 479
Субкультура в сфере разработки ПО.. 479
Причина 1. Разработка ПО не следует стандартным ментальным
моделям создания. 480
Причина 2. Темпы изменений в ИТ-подразделениях намного выше,
чем где-либо еще. 481
Причина 3. Точек соприкосновения между отделом разработки ПО и остальной частью организации не много, и они четко различимы.. 481
Причина 4. Культурное разделение между разработчиками ПО
и остальной частью организации уже признано. 482
“Пузыри” процесса консультаций. 483
“Пузыри” видны только тем, кто их ищет. 484
Самоорганизация “пузырей”. 485
“Пузыри” проницаемы.. 488
Внешние ожидания в отношении тех, кто находится внутри “пузыря”. 488
Очевидные ожидания. 489
Менее очевидные ожидания. 490
“Пузыри” — это интерфейс, не зависящий от реализации. 495
Контракт интерфейса “пузыря”. 495
Перевод идей для всех. 496
Рост числа “пузырей”. 498
Постепенный рост, от команды к команде. 498
Убедитесь, что вы защищаете основные цели своей архитектурной практики. 500
Разделение “пузырей” по мере их увеличения. 500
Ничто не может расширяться вечно. 501
“Пузырь” следует разделить, когда ключевые ценности практики архитектуры находятся под угрозой 501
Как разделить “пузырь”. 502
Поддержание согласованности между “пузырями”. 505
Защита и поощрение различий между “пузырями”. 505
Вывод. 506
Предметный указатель. 508
Об авторе. 510
Об изображении на обложке. 511
