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

• В рабочей среде нет отладчика.

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

• В среде разработки журналы сообщений обычно содержат гораздо более подробную информацию, чем в рабочей среде.

Некоторые из симптомов недостаточного планирования поддержки выглядят так:

• Большинство проблем требует привлечения разработчика.

• Отношения между командой разработчиков и службой поддержки весьма напряженные; разработчики считают, что в службе поддержки собрали одних идиотов.

• Служба поддержки ненавидит новое приложение.

• Команды архитекторов и разработчиков проводят много времени в рабочей среде.

• Приложение часто перезапускается для решения возникших проблем.

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

Чтобы ваше приложение успешно работало после того, как выйдет из рук разработчиков, вы должны:

• Понять, что разработка и поддержка требуют разных навыков.

• Как можно раньше вовлечь в проект руководителя службы технической поддержки.

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

• Привлечь руководителя службы технической поддержки к планированию поддержки приложения.

Проектируйте продукт так, чтобы обучение персонала службы поддержки проходило с максимальной скоростью. Трассируемость, аудит и журналы играют в сопровождении чрезвычайно важную роль. Когда довольны администраторы системы, все остальные тоже довольны (особенно ваш начальник).

Мнчедизи Каспер (Mncedisi Kasper) — директор по технологии и стратегии в Open Xcellence ICT Solutions, южноафриканской компании, специализирующейся на интеграции корпоративных приложений и консультациях в области SAP (АВАР/XI).

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

Знаменитый пример такого рода — теорема Брюэра, которая гласит, что для распределенной системы желательными являются три свойства — целостность (Consistency), доступность (Availability) и устойчивость к разделению (Partitioning tolerance) — и что достичь всех трех целей сразу невозможно. Попытки получить «все сразу» кардинально повышают затраты на разработку и, как правило, влекут за собой рост сложности, не приводя при этом к желаемому эффекту и реальному достижению бизнес-цели. Если данные должны быть распределенными и постоянно доступными, обеспечение целостности обходится все дороже и в конечном счете становится нереальным. Аналогичным образом, если система должна быть распределенной и целостной, обеспечение целостности ведет сначала к задержкам и проблемам с производительностью и в конце концов — к недоступности в то время, когда система занята проверкой данных.

Нередко встречаются ситуации, когда одно или несколько свойств считаются неприкосновенными: данные не должны дублироваться, все операции записи должны быть транзакционными, система должна поддерживать 100-процентную доступность, вызовы должны быть асинхронными, в системе не должно быть единых точек отказа, все составные части должны быть расширяемыми и так далее. Такое фанатичное отношение к свойствам не только наивно, но и мешает нам думать о тех реальных задачах, которые стоят перед нами. От обсуждения главных принципов проектирования мы уходим в обсуждение отклонений архитектуры от идеала и начинаем путать догматизм с качественным управлением. Вместо этого следует задать вопросы: Почему эти свойства так необходимы? Какие преимущества они приносят? Когда они желательны? Как разбить систему на части для достижения лучшего результата? В таких случаях всегда проявляйте здоровый скепсис, потому что архитектурные догмы способны сделать поставку продукта проблематичной. Принять неизбежность таких компромиссов — одна из самых трудных задач в разработке программного обеспечения, причем не только для архитекторов, но также для разработчиков и других заинтересованных лиц. И все же это гораздо лучше, чем иметь безграничную свободу выбора, — неизбежные компромиссы часто ведут к творческим, нестандартным результатам.

Билл де Ора (Bill de hÓra) — ведущий архитектор в компании NewBay Software, где он работает над крупномасштабными веб-системами и системами для мобильных устройств. Является соредактором Atom Publishing Protocol, ранее участвовал в работе группы W3C RDF Working Group. Признанный эксперт в области REST и архитектур на основе передачи сообщений, а также проектирования протоколов.

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

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

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

• Реализовать и адаптировать архитектуру

• Расширить архитектуру на смежные предметные области

• Модифицировать архитектуру для реализации с использованием новых технологий

• Подробно проработать граничные случаи

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

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

Майкл Хармер (Michael Harmer) занимается разработкой программного обеспечения уже 16 лет. Он был рядовым разработчиком, руководителем группы, архитектором, ведущим специалистом и руководителем направления.