Одной из самых полезных практик в архитектурном и детальном проектировании я считаю
практику документирования архитектурных решений через ADR.
Практика, можно сказать, стартовала в 2011 году с
оригинального поста Майкл Найгарда (это автор той самой
крутой книги про production-ready системы, которую имхо стоит прочитать любому, кто себя считает причастным к архитектуре). Затем концепция ADR в том или ином виде стала проникать в различных архитектурные рекомендации и сообщества: в книги по архитектуре, методические фреймворки, например один из самых моих любимых фреймворков Well-Architected от AWS. Со временем практика ADR проникла даже в святая святых корпоративной архитектуры - The Open Group, а конкретнее - в стандарт Open Agile Architecture.
Вот тут собранная в кучу информация по разным подходам к архитектурным решениям и документированию, разные презы умных пацанов. Мои презы и выступления на тему тоже можно поискать в интернете, даже в гугле парочку находит.
Полезность этой практики я для себя легко объясняю именно в контексте популярности «гибких» жизненных циклов по созданию и развития ИТ-систем, продуктов и ландшафтов.
В концепции Big Design Up-front,
когда мы стремились проработать все архитектурные решения заранее и никогда их не менять (что никогда не работало, но кому это мешало?), итоговое состояние архитектуры (Solution Design) было важнее всего. Умные пацаны собрались, крепко подумали,
достали гадальный шар проанализировали все требования и контекст,
нарисовали кучу картинок описали итоговую архитектуру - и отдали ее другим умным пацанам, чтобы те по ней что-то реализовывали, поддерживали и развивали. В этой картине мотивация принятых решений и рассмотренные альтернативы интересуют только первых умных пацанов, называвших это фразой «обоснование архитектурных решений». Да, иногда эта итоговая картина менялась под действием изменений требований или обстоятельств - ну тогда в лучшем случае первые умные пацаны собирались и
рисовали новые картинки меняли архитектуру, а в худшем - продуманная архитектура превращалась в тыкву буквально в этот же момент.
Но в гибких жизненных циклах и концепции Just Enough Design Upfront всё поменялось! Во-первых, авторами архитектурных решений стали все умные пацаны, не только носящие гордый шильдик «архитектор», но и разные, ответственные за проектирование (формально или фактически) члены команды. Во-вторых, всем этим людям, ввиду практически непрерывности изменений и принятия решений - из-за изменений требований, контекста и новых задач - стало интересно не только «что решили», но и «почему?». И для этого недостаточно стало просто менять несколько картинок с внесением в историю изменений фразы «поменяли состав компонентов».
Решения стали важны сами по себе, каждое в отдельности, а не только как пачка принятых решений влияет на конкретный срез архитектуры продукта/ системы/ предприятия в пространстве-времени.
И поэтому ADR - как технология документирования каждого конкретного принятого архитектурно-значимого решения в определенной точке времени, и как
подход к фасилитации выработки этих решений - стала очень востребована.
И поэтому я теперь, как дурачок с писанной торбой, ношусь с этими ADR и по своим коллегам, и по конференциям, рассказывая, как это полезно и интересно, и придумывая разные способы адаптации этой практики к реальной деятельности.
Попозже расскажу про несколько интересных особенностей, с которыми столкнулся за последние годы практики ADR (и адаптации этой практики в проектах, с которыми работал).
