{"id":14268,"url":"\/distributions\/14268\/click?bit=1&hash=1e3309842e8b07895e75261917827295839cd5d4d57d48f0ca524f3f535a7946","title":"\u0420\u0430\u0437\u0440\u0435\u0448\u0430\u0442\u044c \u0441\u043e\u0442\u0440\u0443\u0434\u043d\u0438\u043a\u0430\u043c \u0438\u0433\u0440\u0430\u0442\u044c \u043d\u0430 \u0440\u0430\u0431\u043e\u0447\u0435\u043c \u043c\u0435\u0441\u0442\u0435 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f71e1caf-7964-5525-98be-104bb436cb54"}

Девять главных учебников для архитектора информационных систем: от классики Клеппмана, до современного Хононова

Если разработчики при написании кода отвечают на вопрос «как?», то архитекторы стараются понять «почему?». Даже опытные технические специалисты зачастую не вникают в бизнес-процессы. Разработчики решают задачи, но не задаются вопросом, что приводит к тем или иным решениям.

Я работал в Volvo, ABAX, Intel и сейчас — практикующий тренер в Luxoft Training. Сегодня подготовил девять главных книг, которые помогут как действующим архитекторам информационных систем, так и разработчикам, желающим понять бизнес.

Michael Keeling

Книга Килинга неслучайно первая в списке. На мой взгляд, она прекрасно показывает все то, чем занимается архитектор информационных систем. Автор дает структурированный ответ, как нужно работать с архитектурой. Лейтмотив — перед стартом разработки поймите, что хочет бизнес. Важно бесконечно задавать вопрос «почему», чтобы понимать, чего хочет заказчик.

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

Килинг рассказывает о базовых инструментах, но не скажу, что книга подойдет только начинающим. Сам факт создания архитектуры не должен быть хаотичным. Design It! поможет найти структурированных подход к решению задач с помощью инструментов. Уже после прочтения вы сможете сами углубиться в комбинации и понять, как переходить от функциональных требований к решениям.

Michael T.Nygard

Хоть это уже не Килинг, я считаю книгу Нигарда логическим продолжением Design It!. Когда-то автор работал разработчиком и не задумывался о продакшене, решая задачи с помощью кода. После смены специальности в менеджера поддержки Нигард в корне изменил свое отношение к процессам работы. В книге описываются идеи и реализации, шаблоны и примеры. Главная мысль Release It!, что точки интеграции — убийцы каждой системы, которые рано или поздно приведут к проблемам в жизни приложений. Нигард описывает, как нужно подходить к реализации стабильного продукта.

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

Software Architecture in Practice — Четвертое издание

Len Bass, Paul Clements, Rick Kazman

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

Авторы Software Architecture in Practice рассматривают множество тактик и верхнеуровневых шаблонов для их реализации. Наиболее интересная часть книги — разбор атрибутов качества. Читателям предлагают различные концепты, объясняют принципы работы с виртуализацией, мобильными системами, рассматриваются вопросы масштабируемости. В конце каждой главы авторы оставили вопросы для дискуссий, которые вы можете использовать для себя или команды. Важно, что учебник представляет методы оценки архитектуры под определенные бизнес задачи.

Эта книга была сильно переработана по сравнению с предыдущими изданиями. Информация дополнена, освежена и появились восемь новых глав. Например, в четвертом издании авторы уделяют больше внимания на новые атрибуты качества Energy efficiency, Safety и Usability.

Martin Kleppmann

Труд Клеппмана стал настольной библией многих разработчиков и архитекторов. Книга вобрала в себя все основные идеи, алгоритмы и подходы работы с данными. Кто стоит за данными, что такое алгоритмы консенсуса, какие существуют уровни согласованности — важные вопросы разбираются глобально и с референсами. Прочитав книгу вы поймете, что работа архитектора — это не рисование диаграмм, а принятие сложных решений и компромиссов. Описанные в Designing Data-Intensive Applications идеи позволят правильно оценить на что способен тот или иной продукт и подойти к выбору реализации более ответственно.

Книга выпущена в 17 году, но электронная версия постоянно обновляется. Труд Клеппманна я рекомендую всем, кто каким-либо образом связан с разработкой распределенных систем. Если Design it задает вопросы «почему», то эта книга позволит понять «как».

Gregor Hohpe

Книга Хоп более высокоуровневая и, скорее, пригодится тем, кто уже работает в роли архитектора. Однако интересующимся, что же происходит на уровне enterprise и solution архитектуры разработчикам тоже будет полезна. Я рекомендую использовать электронный вариант, так как с 2015 года книга регулярно обновляется в сети.

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

Хоп рассматривает вопросы архитектуры и коммуникации, оценивает какими навыками и качествами должен обладать специалист. Приведенные в A Chief Architect's Journey идеи заставляет задуматься над тем, как процессы происходят в вашей компании. Когда я работал в Volvo, то дал почитать книгу коллегам из других организаций. Архитектурный комитет отметил ее полезность, но, что более важно, спустя время в компаниях произошли положительные изменения или тенденции.

Gregor Hohpe и Bobby Woolf

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

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

Martin Fowler

Аналитические шаблоны — одна из самых важных тем в работе архитектора информационных систем. Фактически вам предстоит построить метамодель архитектуры тех структур, которые будут использоваться бизнесом для описания домена. Книга Фоулера написана в 96 году, но информация в ней остается актуальной и сегодня. Автор рассматривает шаблоны решений из нескольких областей — медицины, банковской сферы и других. Analysis Patterns расширит взгляд, как строится архитектура, и как выразить работу целой enterprise системы в нескольких элементах.

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

Vlad Khononov

Хононов просто и понятно объяснил идею domain-driven дизайна в своей книге. Автор объясняет разделение стратегического от тактического контекста и показывает, что происходит на каждом этапе. В книге демонстрируются подходы работы с доменами, монолитами, применение ключевых строительных блоков, событийная система и прочее.

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

Gene Kim, Kevin Behr, George Spafford

В конце списка книги, скорее, увлекательные, чем информативные. Однако полезное из Project Phoenix и Project Unicorn почерпнуть можно, с ужасом обнаружив параллели с вашей организацией. Авторы на примере вымышленных команд DevOps и разработчиков описывают процесс работы над продуктом. Это интересное чтиво заставляет задуматься об организации в собственной компании. Внимательные читатели найдут здесь подсказки, выпадающие из фокуса внимания у архитектора и разработчика.

Конечно, список полезной литературы не зациклен только на приведенных книгах. Однако, получив приведенные из твердых переплетов знания, вы сможете самостоятельно двигаться дальше, штудируя Reddit, Хабрахабр, доклады и блоги корпораций. Я настоятельно рекомендую присмотрется к трудам Mike Amundsen, Michael Plod, Stefan Tilkov, Sam Newman, Luca Mezzalira, а также подписываться на них в сети. Инструменты и методы архитектора информационных систем постоянно дополняются и важно не останавливаться в изучении нового.

0
13 комментариев
Написать комментарий...
Louis Cyphre

Странно что в подборке нет «Мифический человеко-месяц, или Как создаются программные системы» (англ. The Mythical Man-Month: Essays on Software Engineering) Фредерика Брукса

Ответить
Развернуть ветку
Александр Соколов

у меня в твердом переплете есть))) отец в сохранил с прошлого века, правда все никак до неё руки не дойдут...

Ответить
Развернуть ветку
Louis Cyphre

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Александр Соколов

В том, что не смотря на возраст, она до сих пор актуальна, а это говорит о многом))

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Александр Соколов

Я сам не читал, но там речь про разработку по и управление проектами в этой области)) кто с этим связан может быть полезно

Ответить
Развернуть ветку
Louis Cyphre

Монументальный дядька делится монументальным опытом архитектора информационных систем. Если у тебя такого опыта нет и он тебе нужен, то будет полезна, а если не нужен, то полезной будет только халявная бумага)

Ответить
Развернуть ветку
Stanislav Pletenev

Прекрасная статья - ни одного комментария =(

Большое спасибо за подборку!

Ответить
Развернуть ветку
Александр Соколов

designing data-intensive applications

супер, как раз хотел подтянуть теорию в архитектуре, а ничего интересного не мог найти!

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Александр Соколов

От себя добавлю "Deadline. Роман об управлении проектами", "психбольница в руках пациентов". Это если хочется отдохнуть от технической литературы))

Ответить
Развернуть ветку
10 комментариев
Раскрывать всегда