97 этюдов для архитекторов программных систем - Нил Форд

редко возникает из-за реального отсутствия альтернатив. Гораздо более вероятное объяснение — неопытность архитектора в предметной области конкретной задачи. Если вы знаете, что это относится к вам, не постесняйтесь обратиться за советом к кому-нибудь из более опытных в этом вопросе коллег.

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

Один мой друг работал техническим руководителем в небольшой, но быстро развивающейся интернет-компании. По мере роста числа пользователей начала возрастать и нагрузка на систему. Это привело к резкому падению производительности, и компания начала терять с таким трудом обретенных пользователей.

Начальник спросил его:

— Что мы можем сделать для улучшения производительности?

У моего друга уже был готов ответ:

— Купить более мощную машину!

— А что еще?

— М-м-м… Насколько я знаю, ничего.

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

Биография автора приведена ранее.

Осознавайте последствия изменений

Дуг Кроуфорд

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

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

Изменения могут проявляться в разных формах:

• Изменения функциональных требований

• Ужесточение требований к масштабируемости

• Модификация интерфейсов системы

• Приход и уход членов команды

• и так далее…

Масштаб и сложность изменений в программном проекте невозможно определить заранее. Бесполезно пытаться объехать каждую выбоину на дороге до того, как вы на нее наткнетесь. Но переживет проект очередное препятствие или нет, в большой степени зависит от архитектора.

Задача архитектора — не столько управлять изменениями, сколько позаботиться об их управляемости.

Для примера возьмем распределенное решение, в котором задействовано несколько приложений, объединенных различным промежуточным программным обеспечением (middleware). Если набор зависимостей неверно определен или неточно представлен в визуальной модели, изменения бизнес-процесса могут привести к настоящему хаосу. Последствия изменений оказываются особенно серьезными, если изменения затрагивают модель данных или нарушают имеющиеся интерфейсы, а существующие долговыполняемые транзакции с отслеживанием состояния должны быть успешно завершены в старой версии процесса.

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

К счастью, существует целый ряд инструментов и методов, позволяющих смягчить воздействие изменений:

• Вносите небольшие, поэтапные изменения

• Создавайте воспроизводимые тестовые сценарии и часто запускайте их

• Упрощайте построение тестовых сценариев

• Отслеживайте зависимости

• Действуйте и реагируйте систематично

• Автоматизируйте повторяющиеся задачи

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

Снижение сложности — важная задача, но низкая сложность не равнозначна простоте. Понимание возможных изменений и их влияния на решение оказывает неоценимую пользу в среднесрочной и долгосрочной перспективах.

Дуг Кроуфорд (Doug Crawford) руководит командой разработчиков промежуточного программного обеспечения для телекоммуникационной компании в Южной Африке. Последние 10 лет он с успехом совмещал несовместимое и принимал самое непосредственное участие в проектах по интеграции приложений в разнообразных отраслях: рекламе, банковском обслуживании крупного бизнеса, страховании и образовании.

Архитектор должен разбираться в оборудовании

Камал Викраманаяке

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

Главная причина заключается в том, что мы полностью концентрируемся на программной стороне и игнорируем аппаратные требования. Вдобавок языки высокого уровня и программные инфраструктуры (software frameworks) естественным образом изолируют нас от оборудования.

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

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

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

Например, вам может пригодиться прошлый опыт. Если вы прежде уже занимались реализацией систем, то у вас имеется некоторое представление о планировании аппаратной мощности — хотя бы на основании ретроспективного анализа. Вы можете также обсудить эту тему со своим клиентом и убедить его выделить средства на планирование мощности оборудования. Финансирование такой деятельности часто оказывается намного выгоднее покупки оборудования сверх реально необходимого. В этом случае ключевая роль отводится горизонтальной масштабируемости:[36] оборудование добавляется по мере надобности вместо избыточных закупок в самом начале. Чтобы «горизонтальная стратегия» работала, архитектор ПО должен постоянно проводить измерения вычислительной мощности и изолировать программные компоненты для запуска в среде с прогнозируемыми показателями производительности.

Планирование вычислительной мощности не менее