Один мой друг работал техническим руководителем в небольшой, но быстро развивающейся интернет-компании. По мере роста числа пользователей начала возрастать и нагрузка на систему. Это привело к резкому падению производительности, и компания начала
терять с таким трудом обретенных пользователей.
Начальник спросил его:
Что мы можем сделать для улучшения производительности?
У моего друга уже был готов ответ:
Купить более мощную машину!
А что еще?
М-м-м Насколько я знаю, ничего.
Моего друга немедленно уволили. Разумеется, начальник был прав.
Биография автора приведена ранее.
Осознавайте последствия изменений Дуг Кроуфорд
Выдающийся архитектор понимает последствия изменений не только в отдельных программных модулях, но также в отношениях между людьми и между системами.
Изменения могут проявляться в разных формах:
Изменения функциональных требований
Ужесточение требований к масштабируемости
Модификация интерфейсов системы
Приход и уход членов команды
и так далее
Масштаб и сложность изменений в программном проекте невозможно определить заранее. Бесполезно пытаться объехать каждую выбоину на дороге до того, как вы на нее наткнетесь. Но переживет проект очередное препятствие или нет, в большой степени зависит от архитектора.
Задача архитектора не столько управлять изменениями, сколько позаботиться об их управляемости.
Для примера возьмем распределенное решение, в котором задействовано несколько приложений, объединенных различным промежуточным программным обеспечением (middleware). Если набор зависимостей неверно определен или неточно представлен в визуальной модели, изменения бизнес-процесса могут привести к настоящему хаосу. Последствия изменений оказываются особенно серьезными, если изменения затрагивают модель данных или нарушают имеющиеся интерфейсы, а существующие долговыполняемые транзакции с отслеживанием состояния должны быть успешно завершены в старой версии процесса.
Пример может показаться излишне радикальным, но решения с высокой степенью интеграции в наше время применяются повсеместно. Это очевидно по ассортименту предлагаемых стандартов интеграции, инфраструктур и шаблонов. Чтобы обеспечить вашим клиентам нормальный уровень поддержки, крайне важно понимать последствия изменений в таких системах, частично лежащих за пределами вашей досягаемости.
К счастью, существует целый ряд инструментов и методов, позволяющих смягчить воздействие изменений:
Вносите небольшие, поэтапные изменения
Создавайте воспроизводимые тестовые сценарии и часто запускайте их
Упрощайте построение тестовых сценариев
Отслеживайте зависимости
Действуйте и реагируйте систематично
Автоматизируйте повторяющиеся задачи
Архитектор должен оценить воздействие изменений на различные аспекты масштаба проекта, времени и бюджета и быть готовым уделить больше внимания тем областям, которые способны оказать наиболее сильное влияние, став той самой «выбоиной на дороге». Оценка рисков полезный инструмент для принятия решения о том, на что следует расходовать ваше драгоценное время.
Снижение сложности важная задача, но низкая сложность не равнозначна простоте. Понимание возможных изменений и их влияния на
решение оказывает неоценимую пользу в среднесрочной и долгосрочной перспективах.
Дуг Кроуфорд (Doug Crawford) руководит командой разработчиков промежуточного программного обеспечения для телекоммуникационной компании в Южной Африке. Последние 10 лет он с успехом совмещал несовместимое и принимал самое непосредственное участие в проектах по интеграции приложений в разнообразных отраслях: рекламе, банковском обслуживании крупного бизнеса, страховании и образовании.
Архитектор должен разбираться в оборудовании Камал Викраманаяке
Главная причина заключается в том, что мы полностью концентрируемся на программной стороне и игнорируем аппаратные требования. Вдобавок языки высокого уровня и программные инфраструктуры (software frameworks) естественным образом изолируют нас от оборудования.
Существенным фактором являются и нечеткие требования, поскольку они могут быть неправильно поняты или подвержены значительным изменениям. По мере развития архитектуры ее аппаратные аспекты тоже изменяются. К тому же может оказаться, что клиент не осознает или не может оценить размер контингента пользователей либо спрогнозировать динамику использования системы. Наконец, оборудование постоянно совершенствуется. То, что мы знаем о нем по прошлому опыту, может быть неактуальным сегодня.
Без знания оборудования прогнозирование аппаратной конфигурации разрабатываемых систем занятие чрезвычайно ненадежное. В качестве компенсации некоторые архитекторы используют большие значения запаса производительности, которые обычно не опираются на какие-либо объективные оценки или методологические рекомендации. В большинстве случаев это приводит к избыточной производительности оборудования, которая не будет задействована даже в периоды пиковой нагрузки. В результате деньги клиента расходуются на оборудование более мощное, чем реально необходимо системе.
Лучшая защита от некачественного аппаратного планирования тесное взаимодействие с архитектором аппаратной инфраструктуры. В отличие от архитекторов программного обеспечения, архитекторы аппаратной инфраструктуры хорошо разбираются в планировании вычислительных мощностей; они должны быть частью вашей команды. Впрочем, не каждому архитектору программного обеспечения доступна такая роскошь, как возможность работать с архитектором аппаратной инфраструктуры. В таких случаях архитектор системы может принять некоторые меры, снижающие вероятность ошибок при планировании оборудования.