Один мой друг работал техническим руководителем в небольшой, но быстро развивающейся интернет-компании. По мере роста числа пользователей начала возрастать и нагрузка на систему. Это привело к резкому падению производительности, и компания начала терять с таким трудом обретенных пользователей.
Начальник спросил его:
— Что мы можем сделать для улучшения производительности?
У моего друга уже был готов ответ:
— Купить более мощную машину!
— А что еще?
— М-м-м… Насколько я знаю, ничего.
Моего друга немедленно уволили. Разумеется, начальник был прав.
Биография автора приведена ранее.
Осознавайте последствия измененийДуг Кроуфорд
Хороший архитектор снижает сложность до минимума и может спроектировать решение, абстракции которого, с одной стороны, обеспечивают надежный фундамент, а с другой — достаточно прагматичны, чтобы пережить изменения.
Выдающийся архитектор понимает последствия изменений — не только в отдельных программных модулях, но также в отношениях между людьми и между системами.
Изменения могут проявляться в разных формах:
• Изменения функциональных требований
• Ужесточение требований к масштабируемости
• Модификация интерфейсов системы
• Приход и уход членов команды
• и так далее…
Масштаб и сложность изменений в программном проекте невозможно определить заранее. Бесполезно пытаться объехать каждую выбоину на дороге до того, как вы на нее наткнетесь. Но переживет проект очередное препятствие или нет, в большой степени зависит от архитектора.
Задача архитектора — не столько управлять изменениями, сколько позаботиться об их управляемости.
Для примера возьмем распределенное решение, в котором задействовано несколько приложений, объединенных различным промежуточным программным обеспечением (middleware). Если набор зависимостей неверно определен или неточно представлен в визуальной модели, изменения бизнес-процесса могут привести к настоящему хаосу. Последствия изменений оказываются особенно серьезными, если изменения затрагивают модель данных или нарушают имеющиеся интерфейсы, а существующие долговыполняемые транзакции с отслеживанием состояния должны быть успешно завершены в старой версии процесса.
Пример может показаться излишне радикальным, но решения с высокой степенью интеграции в наше время применяются повсеместно. Это очевидно по ассортименту предлагаемых стандартов интеграции, инфраструктур и шаблонов. Чтобы обеспечить вашим клиентам нормальный уровень поддержки, крайне важно понимать последствия изменений в таких системах, частично лежащих за пределами вашей досягаемости.
К счастью, существует целый ряд инструментов и методов, позволяющих смягчить воздействие изменений:
• Вносите небольшие, поэтапные изменения
• Создавайте воспроизводимые тестовые сценарии и часто запускайте их
• Упрощайте построение тестовых сценариев
• Отслеживайте зависимости
• Действуйте и реагируйте систематично
• Автоматизируйте повторяющиеся задачи
Архитектор должен оценить воздействие изменений на различные аспекты масштаба проекта, времени и бюджета и быть готовым уделить больше внимания тем областям, которые способны оказать наиболее сильное влияние, став той самой «выбоиной на дороге». Оценка рисков — полезный инструмент для принятия решения о том, на что следует расходовать ваше драгоценное время.
Снижение сложности — важная задача, но низкая сложность не равнозначна простоте. Понимание возможных изменений и их влияния на решение оказывает неоценимую пользу в среднесрочной и долгосрочной перспективах.
Дуг Кроуфорд (Doug Crawford) руководит командой разработчиков промежуточного программного обеспечения для телекоммуникационной компании в Южной Африке. Последние 10 лет он с успехом совмещал несовместимое и принимал самое непосредственное участие в проектах по интеграции приложений в разнообразных отраслях: рекламе, банковском обслуживании крупного бизнеса, страховании и образовании.
Архитектор должен разбираться в оборудованииКамал Викраманаяке
Для многих архитекторов тема планирования мощностей оборудования выходит за рамки их «зоны комфорта», однако она остается важной частью работы архитектора. Причины, по которым архитекторы часто забывают уделить должное внимание оборудованию, весьма разнообразны, но все они связаны большей частью с недопониманием и нечеткостью требований.
Главная причина заключается в том, что мы полностью концентрируемся на программной стороне и игнорируем аппаратные требования. Вдобавок языки высокого уровня и программные инфраструктуры (software frameworks) естественным образом изолируют нас от оборудования.
Существенным фактором являются и нечеткие требования, поскольку они могут быть неправильно поняты или подвержены значительным изменениям. По мере развития архитектуры ее аппаратные аспекты тоже изменяются. К тому же может оказаться, что клиент не осознает или не может оценить размер контингента пользователей либо спрогнозировать динамику использования системы. Наконец, оборудование постоянно совершенствуется. То, что мы знаем о нем по прошлому опыту, может быть неактуальным сегодня.
Без знания оборудования прогнозирование аппаратной конфигурации разрабатываемых систем — занятие чрезвычайно ненадежное. В качестве компенсации некоторые архитекторы используют большие значения запаса производительности, которые обычно не опираются на какие-либо объективные оценки или методологические рекомендации. В большинстве случаев это приводит к избыточной производительности оборудования, которая не будет задействована даже в периоды пиковой нагрузки. В результате деньги клиента расходуются на оборудование более мощное, чем реально необходимо системе.
Лучшая защита от некачественного аппаратного планирования — тесное взаимодействие с архитектором аппаратной инфраструктуры. В отличие от архитекторов программного обеспечения, архитекторы аппаратной инфраструктуры хорошо разбираются в планировании вычислительных мощностей; они должны быть частью вашей команды. Впрочем, не каждому архитектору программного обеспечения доступна такая роскошь, как возможность работать с архитектором аппаратной инфраструктуры. В таких случаях архитектор системы может принять некоторые меры, снижающие вероятность ошибок при планировании оборудования.
Например, вам может пригодиться прошлый опыт. Если вы прежде уже занимались реализацией систем, то у вас имеется некоторое представление о планировании аппаратной мощности — хотя бы на основании ретроспективного анализа. Вы можете также обсудить эту тему со своим клиентом и убедить его выделить средства на планирование мощности оборудования. Финансирование такой деятельности часто оказывается намного выгоднее покупки оборудования сверх реально необходимого. В этом случае ключевая роль отводится горизонтальной масштабируемости:[36] оборудование добавляется по мере надобности вместо избыточных закупок в самом начале. Чтобы «горизонтальная стратегия» работала, архитектор ПО должен постоянно проводить измерения вычислительной мощности и изолировать программные компоненты для запуска в среде с прогнозируемыми показателями производительности.
Планирование вычислительной мощности не менее важно, чем архитектура; уделяйте первостепенное внимание этому вопросу независимо от того, имеется ли у вас под рукой специалист по аппаратной инфраструктуре или нет. Подобно тому как архитектор программного обеспечения отвечает за установление связей между потребностями и программным решением, архитектор аппаратной инфраструктуры отвечает за установление связей между аппаратной и программной частями.
Камал Викраманаяке (Kamal Wickramanayake) — архитектор аппаратного и программного обеспечения, живет на Шри-Ланке. Является обладателем сертификата TOGAF от The Open Group.
«Срезание углов» сейчас обойдется слишком дорого потомСкот Макфи
При создании архитектуры важно помнить, что на сопровождение системы в долгосрочной перспективе расходуется больше ресурсов, чем собственно на разработку. «Срезание углов» на фазе разработки проекта может вылиться в существенные затраты на этапе сопровождения.
Допустим, кто-то сказал вам, что модульные тесты не приносят непосредственной пользы, и вы даете своим разработчикам указание не углубляться в их создание. Впоследствии это значительно затруднит модификацию готовой системы и породит чувство неуверенности во внесенных изменениях. Относительно небольшие изменения потребуют гораздо большего объема ручного тестирования, что приведет к нестабильности и росту затрат на сопровождение, а получившийся дизайн нельзя будет назвать полностью тестируемым (не говоря уже о соответствии принципу «опережающего тестирования»).[37]
Серьезной архитектурной ошибкой является и попытка приспособить существующую систему к тем целям, для которых она не предназначалась, под тем предлогом, что использование существующей системы может каким-то образом снизить затраты. Например, архитектурные компоненты BPEL[38] в сочетании с триггерами баз данных можно приспособить для реализации системы на основе асинхронной передачи сообщений. Такие решения обычно возникают из соображений удобства либо потому, что эта архитектура известна вам или клиенту. Однако действительным основанием для такого выбора могут послужить только четко сформулированные требования — это обязательное условие. Неудачные решения на ранней стадии проекта обходятся очень дорого, когда архитектуру системы приходится изменять в соответствии с новыми требованиями.
В начальной фазе разработки важно не только избегать «срезания углов», но и сразу исправлять неудачные проектировочные решения по мере их обнаружения. Отдельные плохо спроектированные аспекты системы могут лечь в основу других аспектов, что сделает последующие исправления еще более затратным