Существует два подхода к накоплению знанияй — научный и опытный. В тех случаях когда невозможен первый, приходится использовать второй. В библиотеке лучшего ИТ-опыта ITIL накапливаются уроки, полученные на основании предоставления ИТ-сервисов. С появлением сервисной архитектуры не остается ничего иного, как пойти тем же путем и создавать новую версию библиотеки передового опыта.
Наблюдаемый на протяжении последних нескольких лет качественно новый виток в развитии корпоративных информационных систем можно объяснить воздействием множества разных факторов. Не последнюю роль играет своеобразная положительная обратная связь, которая сложилась между бизнесом, предъявляющим свои требования к технологиям, и технологиями, пытающимися этим требованиям удовлетворить. Эта связь отражает тот факт, что в рыночном сегменте, объединяющем разнообразные предложения для корпоративных информационных систем, стала складываться естественная ситуация, когда предложения определяются спросом, а не наоборот, как было на протяжении десятилетий.
Это новое явление; еще совсем недавно связь между технологиями и бизнесом была условной. «Двигателями прогресса» были сами инженеры. Они из собственных предположений старались предугадать, какие из аппаратных или программных продуктов будут востребованы, и предлагали свои новации бизнесу. Часть новаций, возможно меньшая, принималась, а другие оставались за бортом, развитие шло методом проб и ошибок.
Возможно, именно кризис «доткомов», нарушивший привычный порядок вещей, окончательно поставил точку на прежних отношениях между бизнесом и технологиями. Теперь средства, выделяемые на ИТ, стали жестче контролироваться, и в то же время запросы бизнеса заметно возросли. Как следствие, в изменившихся условиях инициатива перешла на сторону бизнеса. Складывается иерархическая система требований, где на верхнем уровне находятся те требования, которые бизнес предъявляет к ИТ-системам, от них требования транслируются на уровень ниже, на системные архитектуры и так далее. Цепочка требований, распространяющихся сверху вниз, определяет специфику эволюционного процесса; по существу, она ставит отношения между бизнесом и технологиями с головы на ноги. Результатом эволюции стали и те самые сервисные архитектуры (Service-Oriented Architecture, SOA), от рассуждения о которых, казалось бы, все уже устали, и все же они остаются темой номер один, действительно «взрывной технологией».
Бизнес и SOA
Появление SOA стало прямым следствием того, что бизнес больше не хочет и не может рассматривать ИТ только лишь как дорогостоящие центры обработки данных, способные выполнять ограниченный набор функций на ограниченном подмножестве данных. Теперь ему нужна органичная, соответствующая его задачам система информационного менеджмента, к тому же способная реагировать и видоизменяться синхронно с изменением бизнеса. Это в теории, а пока большинство компаний располагает унаследованными монолитными приложениями и платформами, ведущими свою родословную от классических транзакционных систем. Подобного рода системы не приспособлены к реализации реактивной стратегии, которую требует от них бизнес, — в значительной мере потому, что требования бизнеса, в отличие от старого доброго времени, недостаточно определенны и стабильны. Случается так, что построенная система удовлетворяет выдвинутым формальным требованиям соглашений об уровне обслуживания (Service Level Agreements, SLA), однако требования успевают устареть и на момент ввода системы в эксплуатацию заказчику требуется уже нечто иное. Поэтому сегодня приходится говорить о своего рода «метатребованиях», которыми определяется возможная область и специфика требований со стороны бизнеса по отношению к поддерживающим его ИТ-системам. Удовлетворить подобным размытым требованиям можно только в том случае, если построить гибкую, просто модернизируемую систему предоставления бизнес-сервисов.
В поисках архитектуры для подобной системы сервисов была найдена архитектура SOA. Основная инженерная находка состоит в том, что в форме сервисов был найден удачный виртуальный уровень, расположенный между бизнесом и технологиями. На какой-то момент показалось, что средствами SOA можно решить все проблемы; пару лет назад даже заговорили было о «смерти программного обеспечения промежуточного слоя». Несмотря на то что сегодня свою причастность к SOA утверждают практически все производители, эта тематика еще очень плохо изучена; показательно, что первая серьезная конференция, ACM Conference on Service Oriented Computing, состоялась всего два года назад, в 2004 году.
Архитектура SOA позволяет построить модель, состоящую из поставщиков и потребителей сервисов, устанавливая связи между ними по требованию. Она образует конструкцию для сборки композитных приложений, состоящих из сервисов со стандартными интерфейсами, эти сервисы способны полностью отразить в себе весь бизнес-процесс. Плюс к тому сервисы представляют собой многократно используемые модули, вне зависимости от используемых протоколов, платформ, языков, внутренних структур данных и алгоритмов.
Представление функций ИТ в виде автономных сервисов со стандартными интерфейсами позволяет создать среду с гибкими возможностями, поддерживающую бизнес-процессы слабосвязанными программными компонентами. Этот тип объединения компонентов обеспечивает возможность сборки начальной конструкции в соответствии с текущими запросами со стороны бизнеса и ее перестройки, в случае изменения этих запросов.
ITIL и SOA
Переход от монолитных архитектур к архитектурам, основанным на компонентах-сервисах, оказался намного тяжелее, чем его представляют проповедники новых технологий, не рассматривающие этот процесс во всей его полноте. Среди самых пугающих последствий выделяется, например такое: слабая связанность приводит к разрушению ясного представления о системе, которое существовало прежде, во времена монолитных систем.
Раньше все было предельно понятно — из чего собрана система, каковы ее отдельные компоненты (серверы, операционные системы, программные средства промежуточного слоя, базы данных, приложения). А вот в «новом прекрасном мире» подобной строгости нет. Здесь наличествуют отдельные фрагменты программного обеспечения и сервисы, физически размещенные на различных серверах, которые вполне могут находиться в различных географических пунктах, к тому же сервисы общаются между собой по собственным правилам, тогда и так, как им нужно. С точки зрения ИТ-менеджера слабосвязанные архитектуры — ночной кошмар, причем со временем с точки зрения менеджмента ситуация становится только хуже и хуже. Нет сомнений в том, что по мере развития систем со слабосвязанными сервисами в отсутствие необходимых средств администрирования сложности будут возрастать. Трудно разрешимые проблемы могут возникать и в тех случаях, когда системный администратор не сможет проследить весь ход бизнес-процесса: в отсутствие должных инструментов он не cможет удостовериться в том, нормально ли протекает процесс, а если ненормально, то обнаружить, что или кто именно в этом повинен.
Для того чтобы как-то справиться с возникающими сложностями, требуется некая новая дисциплина системного администрирования. Одним из ресурсов, который может стать «образцом для подражания» при ее создании, является библиотека лучшего опыта ITIL (IT Infrastructure Library). Некоторые эксперты даже говорят о зарождающейся тенденции к конвергенции ITIL и SOA. Почему именно ITIL? Дело в том, что обычные средства администрирования в большей степени сосредоточены на достижении наивысшей производительности аппаратного и программного обеспечения, а методы, представленные в ITIL, рассматривают администрирование шире. Они включают в себя контроль над тем, как сотрудники выполняют свои функции, какие изменения внесены в аппаратные и программные компоненты информационной системы, какова расстановка приоритетов при выполнении работ и многое иное. Но излишне уповать на ITIL, как на панацею.
Странно, но пока никто не провел параллели между библиотекой ITIL и одним из наиболее известных в авиации документов «Наставление по полетам», сводом законодательства по полетам, составленным на основании обобщения летной практики. Он пополняется, в том числе, на основании разбора катастроф; поэтому иногда говорят, что он написан кровью. Использование «Наставления» интуитивно понятно. Точно так же в ITIL накоплен опыт оказания ИТ-сервисов; использование этого опыта позволяет реструктурировать гетерогенные хаотически организованные информационные системы, принимая во внимание специфику конкретного предприятия.
При оценке сложности проблемы создания управляемых сервисных архитектур стоит вспомнить сказанное Альбертом Эйнштейном: «Ни одна из проблем не может быть решена на том же уровне сознания, на котором она была поставлена». В данном случае это означает, что бизнес-аналитики и системные архитекторы должны произвести переворот в своем сознании, уйдя от простых технических спецификаций и статических определений требований к представлению процессов и операций в динамике с элементами неопределенности. Им предстоит отказаться от тривиального представления о тождестве сервисной архитектуры Web-сервисам, признать, что SOA — это не коллекция разнородных сервисов, а способ объединения современных и вновь создаваемых технологий с целью предоставления сервисов бизнесу. А Анне Томас Манес, один из крупнейших экспертов по SOA, вице-президент и научный руководитель аналитической компании Burton Group, высказалась так: «Создание проектов из множества мелких Web-сервисов без должного руководства не имеет ничего общего с созданием настоящей сервисной архитектуры, это просто забава».
Руководство и SOA
В большинстве своем нынешние подходы к менеджменту и администрированию привязаны к существующим системам. К сожалению, классические методы управления проектами малоприменимы для создания SOA, здесь на первый план выходит новое для ИТ понятие — руководство. В общем смысле этого слова руководство (Governance) — это свод действий или некоторая конструкция, призванная обеспечить принятие решений и обеспечить возможности для учета их последствий. Руководство свободно от конкретных функций по менеджменту, которые являются рутинными; скорее, оно обеспечивает набор готовых решений и правил, а также методов, описывающих стратегию поведения. Иными словами, руководство формулирует набор правил и инструментов, позволяющих оценить соответствие реальных процессов этим правилам. На уровне предприятия руководство реализуется распределением прав и ответственности между отдельными участниками. Надо заметить, что автоматизация руководства никогда не входила в функцию ИТ.
Новым является то, что идеальная архитектура SOA начинается именно на этом уровне, в отличие от традиционных информационных инициатив она не может создаваться как часть ИТ-проекта, а затем адаптироваться к бизнесу. Сервисная архитектура выступает как равноправный компонент корпоративной стратегии; в SOA должны найти свое отражение стратегические цели всего предприятия и руководящие принципы. Почему? Прежде всего, по причине распределенной природы сервисов, которые встроены в различные структурные части бизнеса. Распространение сервисов, создаваемых и поддерживаемых различными организациями, подразделениями внутри предприятия или организациями вне него определяет важность задачи руководства.
В приложении к SOA руководство сводится к определению принципов менеджмента SOA и проверке соответствия этим принципам. Разработка и внедрение SOA должны начинаться с формулировки правил и процедур. Поэтом SOA нельзя купить как готовый продукт, в ней отражена индивидуальность поведения каждого предприятия. А далее руководство и разработка архитектуры действуют совместно, при этом руководство формирует контекст для системных архитекторов и проектировщиков. Наличие общих руководящих принципов обеспечивает проекту, состоящему из множества сервисов, целостность и предсказуемость, оно позволяет собрать сложные приложения из небольших фрагментов.
Создание SOA выводит процесс проектирования на новый, ранее неизвестный уровень; суть состоит в том, что необходимо создавать своего рода «демократические структуры», где отдельные компоненты имеют «право голоса». На протяжении столетий инженеры, не осознавая того, создавали системы, подчиненные внутренней диктатуре, а теперь предстоит строить нечто вроде «городского самоуправления». С точки зрения методологии проектирования это качественно новый шаг, который еще требует своего переосмысления на самых разных уровнях. Разумеется, самым интересным был бы научный, возможно кибернетический взгляд, но пока разрыв между ИТ и фундаментальной наукой настолько велик, что об этом не приходится и мечтать.
Уже цитировавшейся Анне Томас Манес принадлежит следующий тезис: «Самая большая ошибка организаций, внедряющих SOA, состоит в ограничении возможностей для коммуникаций и взаимодействия». Еще радикальнее высказался один из руководителей компании Infravio Мико Мацумура: «Появление социального программного обеспечения, этого феномена последнего времени, позволяет переосмыслить значение SOA и роль социальных существ. Руководство SOA должно включить в себя лучший опыт динамических работающих организаций и то, как люди ведут себя в этих организациях». Для этого нужно создавать центры компетенции или какие-то иные рабочие группы, включающие в себя специалистов по корпоративной архитектуре, которые бы коллекционировали «передовой опыт» и были бы ресурсом сведений о нем, используемым в процессе руководства SOA.
Любой специалист, принимавший участие в серьезной разработке, знает, что жесткая стандартизация полезна до разумных пределов, иначе она может стать барьером. Чтобы избежать этой опасности, предлагается создать специальную конструкцию функциональной совместимости (Interoperability Framework, IF). Ее можно представать как свод стандартов, используемых организацией, снабженных указателями о состоянии стандарта (утвержденный, принятый де-факто, развивающийся, приостановленный, выходящий из употребления и т.п.). Эти ссылки носят рекомендательный характер; скажем, если разработчик использовал где-то «выходящий из употребления» стандарт, то это значит, что ему следует по возможности скорее перейти на другой стандарт. Наличие IF позволяет избавиться от привязанности к постоянно меняющимся стандартам в пользу более стабильных правил, эксперты считают, что создание такой конструкции является неплохим началом, поскольку служит средством для выражения корпоративной политики.
В конечном итоге руководство направлено на создание правил, схем XML Schemas, документов WSDL, разного рода документации и других форм выражения мнений (артефактов), используемых соучастниками процесса создания SOA. Важна форма представления этих документов, простых электронных писем или страниц на сайте недостаточно. Артефакты руководства должны быть в форматах и формах, удобных для поиска и дальнейшего использования. Некоторые организации создают относительно простые системы регистрационных записей, более продвинутые идут дальше, они создают сложные репозитории с развитой системой метаданных. В целом можно сделать вывод о том, что предприятие должно вкладывать значительные средства в автоматизацию процесса руководства, для этого следует инвестировать в людей и инструменты и создавать контекст для будущей сервисной архитектуры.
Важно учитывать еще одно обстоятельство. Любой демократический процесс должен быть управляемым, он должен сдерживаться отрицательной обратной связью, исключающей потерю управляемости. Поэтому в процессе руководства SOA требуется наличие контролирующих органов, способных сравнить реальное положение дел с желаемым, выработать необходимое управляющее воздействие и таким образом внести нужные коррективы.
Итак, пока ничего лучшего для управления сложными системами, чем аккумулирование накопленного опыта, не найдено. В ИТ наиболее распространенной формой для представления такого опыта стала библиотека ITIL. По всей видимости, для создания руководства SOA потребуется аналогичная библиотека или может быть какая-то новая версия ITIL.
На рис. 1 представлена среда руководства и менеджмента, в центре которой находится SOA.
 |
| Рис. 1. Руководство SOA и окружающий контекст |
Функциями менеджмента бизнес-сервисами (Business Service Management, BSM) являются доставка и администрирование всех сервисов, которые ИТ предоставляют бизнесу, и измерение параметров, позволяющих оценить их эффективность; желательно, чтобы все это происходило в режиме реального времени. BSM строится исходя из предположения, что языком общения между ИТ и бизнесом является язык, приближенный к бизнесу. Это дает возможность не только легко использовать предоставляемые сервисы, но и возвращать по обратной связи необходимые корректирующие воздействия, позволяющие вносить усовершенствования в систему обслуживания. На этом уровне вновь просматривается аналогия с ITIL. До сих пор эта библиотека была привязана только к ИТ-сервисам и к IT Service Management (ITSM), но может стать расширением по отношению и к BSM. (По своей логике BSM это почти то же самое, что ITSM, но обернутое не вокруг технических средств и ИТ-процессов, а вокруг бизнес-процессов.)
Входящий составной частью в BSM менеджмент на уровне бизнес-сервисов (Business Service Level Management, BSLM) дает возможность контролировать качество ИТ-сервисов и готовит необходимые отчеты, используя для этого методику, близкую к мониторингу бизнес-процессов (Business Process Monitoring, BPM). И в BSLM, и в BPM используют ключевые индикаторы производительности (Key Performance Indicator, KPI), в переводе на технический язык — датчики, сообщающие метрики контролируемых ими процессов. Таким образом, BSM привносит возможность количественной оценки функционирования ИТ.
 |
| Рис. 2. Роль и место ITIL |
На рис. 2 обозначена позиция, которую может занять ITIL в инфраструктуре SOA. Но пока это в теории, на практике много сложнее. Для того чтобы концепция ITIL действительно заняла это центральное место, необходимо пересмотреть определение сервисов, до сих пор ограниченное ITSM. При этом следует учитывать более сложную связь между бизнес-процессами и сервисами, чем аналогичная связь с приложениями. Функциональная составляющая сервисов не должна ставиться выше по значимости, чем каталогизация сервисов, методы их обнаружения и доступа к ним. Немалую сложность создает сохраняющееся административное разделение между ИТ-подразделениями и теми, кто руководит бизнесом. Однако главная сложность носит ментальный характер, она заключается в том, что полноценное внедрение SOA потребует произвести существенный переворот в умах. Не случайно одно из наиболее цитируемых высказываний Манес звучит почти как революционный призыв: «Интеграция приложений предприятия служит для возведения мостов между силосными башнями ИТ, а сервисная архитектура призвана эти башни сокрушить».
Литература
- R. Shewmaker, D. Brock, M. Gardner, SOA Management Landscape. www.mw2consulting.com, March 2006.
- Jon Collins, IT service management: jumping on a moving train. www.mwdadvisors.com, May 2006.
- J. Falkl, Service Oriented Architecture Compliance: Initial steps in a longer journey, www.ibm.com, December 2005.
- P. Windley, Governing SOA, www.infoworld.com, January 2006.
Все это сервисы
В последние годы невероятную популярность приобрел термин «сервис». Его применяют в различных контекстах. Приведем некоторые из них.
- Программное обеспечение, поставляемое как сервис (Software-as-a-Service, SaaS), дает пользователю доступ к расположенным на удаленных хостах программам, используя для этого тонкие, а возможно, и мобильные клиенты. В какой-то мере это является развитием того, что раньше называли поставкой приложений, осуществляемой провайдерами услуг.
- Cервисы, предоставляемые разного рода Web-сайтами (customer-facing services). Спектр сервисов этой категории невероятно широк — от бесплатной электронной почты до Internet-торговли и онлайновой поставки данных.
- ИТ-сервисы — совокупность услуг со стороны ИТ-подразделений остальным подразделениям предприятия. Этот вид сервисов управляется средствами IT Service Management (ITSM) и Business Service Management (BSM).
- Системы, построенные с использованием слабосвязанных сервисов (loosely coupled services), которые обеспечивают обмен данными и функциональностью между программными компонентами. Поначалу их отождествляли только с Web-сервисами. Однако сегодня понятно, что слабая связанность может быть реализована с использованием более широкого спектра технологий. Данный тип сервисов обычно рассматривают в качестве основы для сервис-ориентированных архитектур.
О сложностях терминологии
Известно, что у некоторых северных народов нет слова «снег», но есть десятки слов, каждое из которых относится к определенному типу снега. Нечто подобное обнаруживается в английском языке с его дотошностью ко времени и действию. С помощью словаря Multitran удалось установить, что в английском языке существует более полусотни слов, которые можно перевести на русский глаголом «управлять». Основные среди них таковы: administer, command, conduct, construe, control, cue, direct, drive, fight, fly, govern, guide, hack, handle, head, husband, keep, king, lead, manage, manipulate, master, mastermind, move, navigate, operate, orchestrate, pilot, police, rein, ride, rule, run, sail, serve, steer, steer, steward, stick superintend, supervise, sway, tend, work. Впрочем, этим перечень не ограничивается.
В русском языке, не менее богатом, но другими качествами, глаголов, выражающих те или иные способы управления, существенно меньше. Как следствие, возникают серьезные сложности со словами governance, control, administration и management, постоянно встречающимися в текстах, связанных с информационными системами. Обычно они переводятся одним словом — «управление». В случаях, когда контекст очевиден, значительных проблем не возникает (правда, встречаются чудовищные искажения наподобие «управления идентификацией», но с этим, как с неизбежным злом, приходится мириться). А вот если в одной и той же предметной области используют сразу несколько этих слов, то простое решение уже не подходит. Каждое из них имеет свой смысловой оттенок, его можно уловить даже по ограниченному перечню значений.
- Control — «контроль», «проверка», «регулирование», «ведение». Происходит от латинских слов contra и rotulus (кстати, от второй латинской составляющей происходит и router, переводимое как «маршрутизатор»).
- Management — «управление», «заведование», «руководство», «дирекция». Происходит от итальянского maneggiare, в свою очередь происходящего от латинского manus, переводимого как «рука».
- Governance — «управление», «власть», «руководство».
- Administration — «общее администрирование», «правительство», «ведомство», «управление».
Сложность современных информационных систем достигла такого уровня, когда приходится выполнять все перечисленные типы действий. Поэтому для сохранения смысла каждого слова будем переводить так: control — «регулирование», management — «менеджмент», administration — «администрирование»; governance — «руководство». Ну а слово «управление» постараемся не использовать вовсе.
