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

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

И все же некоторые архитекторы проектируют системы «на перспективу», пытаясь, так сказать, застраховать их от будущего. Однако это попросту невозможно. Какое бы архитектурное решение вы ни приняли сейчас, рано или поздно оно устареет. Новомодный язык программирования, который вы примените, завтра станет таким же ископаемым, как COBOL. Сегодняшняя распределенная инфраструктура завтра будет выглядеть такой же несовершенной, как DCOM сегодня. Короче говоря, сегодняшнее решение неизбежно превратится в завтрашнюю проблему.

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

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

Ричард Монсон-Хейфел (Richard Monson-Haefel) — независимый разработчик ПО, соавтор всех пяти изданий «Enterprise JavaBeans» и обоих изданий «Java Message Service» (все книги опубликованы, издательством O’Reilly). Занимается проектированием и разработкой multitouch-интерфейсов, является ведущим специалистом в области корпоративной обработки данных.

Проблема пользовательского признания Норман Карновейл

Люди не всегда рады появлению новых систем или крупным обновлениям. Это может поставить под угрозу успешное завершение проекта.

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

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

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

• Люди боятся новых (непроверенных) технологий.

• Люди стараются избежать дополнительных затрат.

• Люди просто не любят изменения.

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

К числу других эффективных мер относится обучение, запланированные демонстрации системы (на ранних стадиях жизненного цикла проекта) и распространение информации о том, какую пользу принесет новая система.

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

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