Что такое архитектура? Не города или здания, а организационная версия: архитектура предприятия, архитектура решения, архитектура приложения, архитектура программного обеспечения, бизнес-архитектура, архитектура инфраструктуры? Волосы на моей голове начинают шевелиться, когда мы, архитекторы, обращаемся к этой теме со свой раздражающей всех башни из слоновой кости, созданной для размышлений, которые тешат наше самолюбие. Но на этот раз я должен затронуть этот вопрос, потому что он является предварительным условием для рассмотрения темы (архитектурного, технического) долга и архитектуры, всё вместе станет историей из трех статей.

Agile и то, что он говорит об Архитектуре

Архитектура официально упоминается в «Манифесте Agile», в нем говорится, что один из основополагающих принципов: «Лучшие архитектуры, требования и проектные решения рождаются в самоорганизующихся командах».

The best architectures, requirements, and designs emerge from self-organizing teams.
(Из: The Agile Manifesto Principles)

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

Agile имеет не только серьезных сторонников (и я считаю себя среди них), но и свою справедливую долю фанатиков, которые склонны верить (и иногда заставляют свое руководство верить), что «работа по agile» дает вам какую-то бесконечную способность к изменениям и что можно выполнять всевозможные виды изменений, в том числе большие преобразования. У нас даже есть довольно большие фреймворки, такие как Scaled Agile Framework (SAFe), который может применяться для изменений на основе гибких принципов для самых высоких стратегических уровней.

Такие фреймворки имеют нечто общее со всеобъемлющими фреймворками, которые были созданы ранее (FEAF, MODAF, TOGAF и т.д.). Никто на самом деле не использует целиком. Масштаб фреймворков обычно не легко поддается пониманию всеми теми, кто работает в своем узком контексте. Мне представляется, что основы действующих рабочих практик были экстраполированы для создания полного фреймворка. Хотя «наполнитель» никогда не подвергался испытанию, тем не менее, всё целиком продается как «лучшая практика».

Посмотрим на TOGAF и SAFe, они прочно основаны на мире разработки приложений. Это видно, когда TOGAF основывает одно из двух своих определений архитектуры на определении архитектуры программного обеспечения ISO.

Архитектура – фундаментальные понятия или свойства системы в ее окружении, воплощенные в ее элементах, отношениях и принципах ее проектирования и эволюции.
(Из: ISO/IEC/IEEE 42010:2011)

Или, когда SAFe говорит нам, что есть features и enablers, и одним из enablers является «инфраструктура» (хотя можно, конечно, абстрагировать это понятие). Фреймворки нередко немного тяжелы в определениях и подробностях, они пытаются быть всеобъемлющими. Поэтому они часто разрастаются с течением времени, чтобы определить и охватить все больше и больше. Но большие фреймворки обычно используются только частично, потому что полный фреймворк в большинстве ситуаций является бюрократическим перегибом. То, что часто видно в «болезни определения», желании создать строгие определения для всего, включая для вещей, которые будут игнорировать такие определения в действительности (Ludwig Wittgenstein).

В то время как большие фреймворки могут рассматриваться с критическим взглядом, сама концепция Agile (хотя и не нова) действительно является очень практичным ответом (по крайней мере, частично) на сложность и, прежде всего, изменчивость. Agile это реакция на большинство изменений и преобразований в современных сложных организациях. Сложность, потому что ИТ позволило быть сложным. Изменчивость, потому что по сравнению с заводами, полными тяжелой техники, в ИТ всё довольно легко изменить. Это всё-таки software, и даже hardware не имеет такого срока службы, например, как стены здания. Сложные организации сегодня производят более автономные изменения, чем «бумажные» организации былых лет. Водопад с Big Up-Front Design (BUFD) стал настолько непрактичным, что в сегодняшнем мире с ИТ-нагрузкой он стал практически невозможным. Таким образом, мы получаем перманентную массовую параллельную эволюцию в наших организациях на основе многих (Agile) команд, работающих параллельно.

Нет никакой теоретической причины, что что-то трудно изменить в отношении программного обеспечения. Если вы выбираете какой-либо один аспект программного обеспечения, вы можете легко изменить его, но мы не знаем, как сделать всё легко изменяемым. Сделать что-то легким для изменения — делает общую систему немного сложнее, а сделать всё легким для изменения — делает всю систему очень сложной.
(Ральф Джонсон, процитировано Мартином Фаулером)

Определение Архитектуры

Как я уже сказал выше, дискуссии о том, «Что такое архитектура», как правило, являются тратой энергии, лучше потратить ее на выработку хороших проектных решений для вашей организации. Существует множество определений архитектуры, выше я указал наиболее широко используемые. В Mastering ArchiMate есть другое определение, и я признаюсь, что мне оно отчасти нравится:

Архитектура предприятия – это о понимании всех различных элементов, которые составляют предприятие, и как эти элементы взаимосвязаны.

Это из Institute For Enterprise Architecture Developments. Не то, чтобы я не согласен со всем, что они пишут, но всё же это «О» чём-то не говорит «Как». И «Понимание» — столь же скользкое слово. Так что это всё не очень-то Вам помогает. Существуют множество других определений, от MIT, правительства США и т. д. Одно из них от ArchiMate Foundation: «Согласованное целое из принципов, методов и моделей, которое используются при проектировании и реализации организационной структуры предприятия, бизнес-процессов, информационных систем и инфраструктуры».

Но определение, которое сочетается с моими собственными ощущениями было то, что у Мартина Фаулера в его широко известной статье 2003 года «Кому нужен архитектор?». Там он заканчивает определение архитектуры как «вещи, которые тяжело изменить». Это не отличается от определения Гради Буча, который сказал:

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

(Примечание: более полная цитата имеет хорошее замечание о «науке и искусстве»). Я также твердо убежден, что архитектура – это, в конце концов, не что иное, как проектные решения, и что желание по-настоящему отделить их отчасти происходит от «[желания] говорить о проектных решениях, но [желая] раздувать их, чтобы они звучали важно» (Фаулер). Так, в нашем мире архитектуры, мы можем сказать: Архитектура – это проектные решения, которые тяжело изменить. Конечно, их действительно тяжело изменить, только когда они были реализованы. Бумага всё стерпит, и письма легко меняются (если вы не находитесь в 6-и месячной адской архитектурной дискуссии). Но архитектура, как измерение важности проектных решений – это хорошее определение, и гораздо лучше, чем в ISO, ArchiMate, TOGAF и т. д.

Однако, существует тонкость с характеристикой «тяжело изменить».

Предположим, у вас есть проектное решение, которое описывает для ваших разработчиков, как они должны структурировать свой код на Python. Если у вас есть много кода, для изменения всего этого кода из одной структуры в другую потребует много работы. Другими словами, это тяжело. Следовательно, это выбранное решение является «архитектурой», в данном случае программной архитектурой. Но один разработчик может легко проигнорировать это решение и написать код, который делает всё по-другому. В конце концов, вносить «изменения» в программное обеспечение легко. Хотя всю реализованную архитектуру изменить тяжело, в ней часто достаточно легко можно изменять только отдельные части (см. Ральф Джонсон выше). Архитектура, таким образом, что-то «тяжелое», которое состоит из множества «легких». Вы видите это на всех уровнях, например, если ваше проектное решение – использовать только базы данных Oracle, и вдруг, появляются отдельные базы данных PostgreSQL, которые достаточно просты в настройке, и поэтому они легко появляются (что делает ваш ландшафт более сложным, это обычно не одобряется). Но заменить все Oracle на PostgreSQL в вашем ландшафте тяжело (и это может быть даже не вполне осуществимо). Следовательно, формируется следующее определение:

Архитектура – проектные решения, которые тяжело полностью удалить из реализаций.

(Хотя, сокращение Фаулера «тяжело изменить» будет в большинстве случаев). Еще одно замечание, касающееся «тяжело изменяемых», их может быть трудно удалить из-за зависимости от других, поэтому смысл слова «реализация» широкий, например, изменение как производителей, так и потребителей сервиса. «Тяжелый» всегда должен рассматриваться с точки зрения вашей организации, хороший пример того, почему область архитектуры, как правило, шире, чем область решения, проекта или продукта.
Примечание: 1) Это определение не зависит от ИТ. 2) Можно утверждать, что я таким образом раскрыл значение слова «фундаментальные» в определении «Архитектуры» по ISO.

Agile и Архитектура, разные концы одной шкалы

Получается очень интересные отношения между миром Agile и миром Архитектуры. Agile предназначен для того, чтобы сделать изменения как можно более возможными, сделать изменения легкими (или, по крайней мере, не трудными). А с другой стороны: Архитектура, как мы заметили — это то, где изменения тяжелы. Другими словами, они находятся на противоположных концах спектра, они являются принципиальными качелями в вашей организации.

Я поддерживаю Agile, и заявляю, что это оптимальный способ внести изменения в наши ИТ-нагруженные сложные бизнес-ландшафты. Но это означает, что всё то, что мы находим, что тяжело достичь, используя подходы Agile – это де-факто «Архитектура». Так Agile учит нас, что такое Архитектура.

Примечание: Важно отметить, что Agile берет много от Lean, который был основан на подходе Toyota для физических заводов. Toyota хотела сделать производство более гибким, чтобы справиться со сложностью. Но есть много аспектов этой настройки, которые нелегко перевести в кремневый мир программного обеспечения. Например, Toyota поддерживала очень ограниченную изменчивость, и большинство вещей не могло измениться. В программном обеспечении всё может измениться, и не верно по определению, что метод, который (незначительно, но с большим эффектом) суб-оптимизировал физический производственный процесс, может является основой для другого производственного процесса.

Итак, где мы находим архитектуру, где Agile попадает в неприятности? Есть несколько очевидных примеров:

1. Каким бы ни был ваш подход к гибкой работе и реагированию на давление feature/defect со стороны ваших «клиентов», большие и сложные среды могут иметь множество зависимостей, которые затрудняют изменения. Это может быть несколько ключевых элементов (выбранные платформы, база данных, ESB или даже стандарты кодирования и язык программирования), которые используются многими и поэтому тяжело изменить. Или может быть, что различные компоненты имеют много хитрых взаимосвязей. В обоих случаях изменения тяжелы, поэтому выбранные проектных решений, которые трудно изменить при реализации (которые может быть даже хорошо детализированы), являются архитектурой.
2. С Agile в сложной среде, особенно, если руководствоваться мантрами наподобие YAGNI (You Ain’t Gonna Need It) сложно быть готовым к переменам (just in time). Вот почему в SAFe существует Architectural Runway, и почему элементы на нем получают особое облуживание в отличии обычных ежедневных features и defects. SAFe даже утверждает, что следует зарезервировать в спринтах определенный фиксированный объем для архитектурной работы. С точки зрения SAFe эта работа выполняется для «расширения Runway», чтобы будущие features могли ее «употребить». Вот почему YAGNI не всегда хорошая вещь (немного похожая на принципы в архитектуре, которые могут быть довольно «токсичными»). Бережливость не делать бесполезную работу – это хорошо, но превращение ее в догму – плохо. Допустим, что вы хотите, используя Agile подход, преобразовать свою инфраструктуру хостинга с большим количеством ручных работ в полностью автоматизированный «центр обработки данных, готовый к DevOps» (DRDC). Вы знаете, что вам нужны определенные платформы для поддержки приложений, таких как Tomcat, JBoss, Session state storage для обоих, File sharing, Redis, MongoDB, MQ, IIS и т.д. Но вы вдохновлены Lean (который сам по себе был разработан в гораздо менее изменчивой физической производственной обстановке и восходит к трудам Бенджамина Франклина) и YAGNI, который говорит вам, что не надо начинать работать над ними до тех пор, пока первый «клиент» не постучит в дверь («muda» или «не добавляющая стоимости работа» из Lean). Из этого следует, что, когда они действительно придут к вам, им придется подождать, пока вы готовите свои платформы (вы создали «muru» или «неравномерность»). Другими словами, преобразование приложений из старой системы хостинга в новую становится тяжелым, потому что ваш Runway не готов к тому моменту, когда это необходимо, вы не управляете им отдельно от ежедневных запросов.
3. Agile имеет проблемы, когда слишком много связанных вещей изменяются одновременно. Изменение становится тяжелыми, потому что вы должны принять много увязанных друг с другом решений, все в один отрезок времени и в ситуации, когда еще не знаете всего. Вы можете застрять на этом уровне, который выше, чем работа с Agile командами (вы создали «muri» или «переработки»). Сделать такой выбор тяжело, поэтому это архитектура. И поэтому Agile пытается сделать домены независимыми (если простыми словами: превратить их в бункеры...) – старое средство архитектуры.

Извиняюсь за то, что вольно обошелся тут с японскими терминами. Таким образом, Agile фокусирует внимание на том, что Архитектура – предмет, а не практика, а разум говорит, что:

Архитектура – это каждое реализованное проектное решение, которое делает Agile трудным.

Выбор того, что вы положите в свой «план расширения Runway» зависит от того, как трудно будет сделать преобразования: таким образом, это выбор архитектуры. И его нельзя просто оставлять владельцам продуктов под давлением пользователей. Выбор также должны быть сделан с участием заинтересованных сторон архитектуры, поэтому существуют сдержки и противовесы против «бункеров» и «краткосрочности». Подробнее об архитектуре (как практике) во второй части этой мини-серии статей.

Определение архитектуры как совокупности «тяжелых вещей» не все, что нам нужно. Потому что помимо того, что «тяжело», нам нужны некоторые рекомендации относительно того, к чему стремиться с архитектурой. Часто говорят, что идея архитектуры заключается в обеспечении гибкости путем создания гибких решений. Фактически, Фаулер заявил, что задача архитектора – убрать архитектуру. Но это слишком просто. Гибкость обычно сопряжена с затратами, и эти «затраты» (время и деньги) не могут увеличиваться бесконечно (см. Джонсон выше). Все хотят, чтобы решения были совершенно гибкими, но это недешево (и никто не хочет платить по счетам), небыстро и не всегда даже возможно. Иногда ситуация проста: вы должны сделать выбор, который будет трудно изменить, вы не можете поддерживать все варианты (например, выбор платформы, вы не можете поддерживать все). Конечно, если выбор не очень дорого обойдется, то выберите гибкие решения или откладывайте выбор как можно дольше (как предлагает SAFe: не ограничивайте свои варианты). Но на практике часто приходится делать выбор. Выбор, который будет тяжело изменить – архитектурный выбор. Архитектура стремится свести к минимуму ненужную негибкость, ведь наивно думать, что будет мир, где все изменения легки и нет ничего сложно. Существуют вещи не менее важные, а чаще даже более важные, чем гибкость. Я считаю, всего их три: Надежность, Эффективность и Гибкость – Robustness, Efficiency, Flexibility (REF).

Подробнее о REF, практике архитектуры и долгах во второй части, но я вспомнил об ролике «Почему архитектура предприятия», который мы создали много лет назад, в те времена, когда мы делали архитектуру самой гибкой в мире BUFD:

Слушайте своего врача и адвоката

И в заключении, архитектура (как предмет) – это то, что «тяжело», но вы также можете сказать, что «архитектура (как практика) тяжела». Они тесно связаны, архитектура (как практика) тяжела, потому что сегодняшняя сложность делает изменения тяжелыми, а сегодняшнее непостоянство делает изменения властными. Вот почему вы должны платить хорошим архитекторам мегабаксы. Ну ладно, может быть, нет, но вы должны обязательно слушать хороших архитекторов и принимать их советы очень, очень серьезно. Остался только один простой вопрос: Как распознать хорошего архитектора?