Еще одна проблема внедрения, которая часто разрушает самые перспективные SOA-проекты – абсолютная непроработанность вопросов обучения конечных пользователей. А ведь именно от их мнения о системе зависит ее будущее.

Этап эксплуатации

Рассмотрим важные моменты при эксплуатации проекта.

Нужно ли гибкое конфигурирование и настройка в SOA-решении?

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

Самые известные средства данного класса решений – это поддержка бизнес-правил, изменение маршрутизации запросов средствами шины сервисов и формирование «на лету» цепочек утверждения документов. Все эти средства есть и поддерживаются, но они требуют более чем тщательного и продуманного подхода к использованию. Только представим себе, к каким последствиям может привести неправильное бизнес-правило о предоставлении скидки?! А ведь большинство таких ошибок не будут видны без специальных средств диагностики.

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

«Сильное взаимодействие» или «Слабое взаимодействие»

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

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

24*7 или 8*5?

Практически каждое техническое задание, где есть требование высокой готовности, требуется готовность на уровне 24*7. Причем одни хотят высокую готовность, выражаемую как 99,9, другие как 99,99, а некоторые и как 99,9999. Получается своего рода негласное соревнование. А ведь конечная цена SOA-решения в зависимости от числа этих девяток увеличивается по экспоненциальному закону.

При анализе же задачи часто убеждаешься, что заказчику достаточно и скромной величины 8*5. В крайнем случае, с учетом шестидневной рабочей недели и при работе во всех часовых поясах России это будет 16*6. Конечно же, режим 24*7 нужен для некоторых компаний, но уж точно не для всей SOA-системы. И здесь очень важно еще на этапе проектирования провести группировку участков системы, к которым предъявляются различные требования по уровню поддержки высокой готовности.