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

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

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

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

Бабочка машет крыльями
Рассмотрим действие «эффекта бабочки» на примере конкретной ситуации. В нашем случае администратору, проверяющему отчет о продажах, требуются самые свежие данные, которых нет в CRM-системе компании. При традиционном подходе, который существовал до перехода к SOA, администратор позвонил бы в отдел информационных технологий и запросил у аналитика отчет на основе последних данных. Аналитику известно, что программа-анализатор, с помощью которой сгенерирован отчет, использует запросы к базе данных, информация в которой обновляется только по субботам. Администратору абсолютно безразлично, как всё это работает, ему нужен отчет, чтобы принять важное решение. В этом случае аналитик оценит, сколько времени займёт создание, тестирование и запуск специального запроса к системе текущих транзакций, и затребует дополнительные ресурсы для создания такого запроса. Теперь администратору придется решать, насколько важен для него отчет, и будет ли он стоить времени и денег, затраченных на его получение.

Рассмотрим, как будет развиваться действие в организации, перешедшей к SOA. В распоряжении администратора находится инструмент управления на основе заданных правил, доступ к которому осуществляется через корпоративный портал. Этот инструмент в своей работе использует несколько сервисов, являющихся частью системы управления SOA. Как и в предыдущей модели, администратор не имеет ровно никакого представления о технических аспектах. Всё, что нужно знать администраторам: они могут зайти на портал и изменить определенные корпоративные правила. Одним нажатием кнопки администратор изменяет соглашение об уровне услуг (SLA), по которому формируется нужный ему отчет: в графе «Отчетный период» он изменяет параметр «по предыдущую неделю включительно» на «по предыдущий день включительно».

Именно на этом этапе ИТ могут столкнуться с негативными последствиями «эффекта бабочки». Сможет ли система автоматически выполнить запрос в соответствии с изменениями, внесенными администратором, или же потребуется вмешательство ИТ-специалиста? Будет ли выполнено новое SLA? Что произойдёт, если несколько администраторов одновременно произведут несколько различных изменений в правилах? Которое из них должно быть выполнено в первую очередь? До перехода к SOA недостаток автоматизации приводил к тому, что любое изменение, затрагивающее ИТ, требовало вмешательства человека, следовательно, у человека всегда была возможность вмешаться в ход событий в случае возникновения непредвиденных обстоятельств. При SOA управление правилами более автоматизировано, и компании выводят человеческий фактор из процесса реализации правил на свой страх и риск.

Мета-правила спешат на помощь
К счастью, как только компания осознает опасность «эффекта бабочки», решение этой проблемы становится довольно очевидным. Следует разделить, какие изменения в правилах можно будет производить без привлечения ИТ-специалистов, а какие будут осуществляться только с их одобрения. Другими словами, для управления SOA требуется не только определенный свод правил, но и набор правил для правил – то, что можно назвать мета-правилами. Такие мета-правила могут регулировать границы, в рамках которых допустимо изменять сами правила. Например, мета-правило может регламентировать, что авторизованный администратор может изменить пороговую величину правила не более чем на 10% в любую сторону, однако для любого изменения, превышающего 10% от начального значения, будет требоваться одобрение конкретного ИТ-специалиста.

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

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

Комментарии