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

Несколько лет назад, когда идея организации Web-сервисов была еще внове, многим ИТ-специалистам стало понятно, что вместе с этим эффективным средством коммуникации между приложениями появляются новые интересные возможности. Однако о конкретных сферах применения Web-сервисов (за исключением отдельных очевидных случаев) до определенной поры говорить было сложно. В 2005 году произошел качественный сдвиг: теперь ведущие ИТ-эксперты считают выросшую из идеи Web-сервисов архитектуру, ориентированную на сервисы (service oriented architecture, SOA), основой для построения всей архитектуры предприятия (enterprise architecture, EA).

Еще совсем недавно такой поворот событий невозможно было и представить. Но, хотя заверения в перспективности SOA и звучат с самых высоких трибун, в какой-то мере история Web-сервисов повторяется. Как и прежде, при всей интересности и чрезвычайной перспективности концепции очевидно, что полная ясность наступит, скорее всего, не завтра и даже не послезавтра. Как бы то ни было, тема конвергенции SOA и EA стала в 2005 году одной из самых «горячих» для компьютерной прессы и отраслевых аналитиков.

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

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

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

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

Отвечая на вопрос, почему именно SOA оказалась в центре внимания, можно привести следующее соображение. Подходы на основе SOA позволят изменить действующую парадигму, в соответствии с которой ядром любой корпоративной информационной системы служит СУБД. Эта парадигма — не единственная и не идеальная. Само появление баз данных и то, что именно они заняли центральное место в корпоративных информационных системах, стало отражением видения в компьютере лишь устройства для обработки данных.

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

Удивительно, но у SOA нет определенного автора — в отличие от другой очень интересной и актуальной идеи — предприятия, опирающегося на события (event-driven architecture, EDA), или от сервисной шины предприятия (enterprise service bus, ESB). Немало специалистов предпринимали попытки обнаружить, «кто первым сказал SOA», но они не увенчались успехом. Этот тип архитектуры сложился неисповедимыми путями в результате постепенной эволюции идеи Web-сервисов, казавшеся на первых порах странной.

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

Сильная сторона слабой связанности

В одном из недавних интервью руководитель подразделения программного моделирования IBM/Rational Джим Рамбо (наряду с Гради Бучем и Иваром Якобсоном он входит в известное «трио друзей», ставших авторами унифицированного языка моделирования UML) высказал удивительную мысль: «Времена меняются, и устойчивость способов выполнения операций больше не является обязательным атрибутом реализации бизнес-процессов». Прямо скажем, это покушение на первоосновы; здесь есть над чем призадуматься.

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

Сервисы как системообразующие средства нуждаются в более глубоком обсуждении, но пока мы ограничимся лишь одним замечанием. Из кибернетики известно, что для обеспечения эффективности системы управления ее сложность должна быть адекватна сложности управляемого объекта. Эта аксиома возникла в далекие 50-е годы, прежде всего — в приложении к техническим системам, связи между компонентами которых являются жесткими по определению. То, что они могут быть иными, тогда не предполагалось. Безальтернативность отношения к связям сохранялась долгие годы — как максимум, учитывалась вероятность событий.

Для технических систем подобное упрощение вполне приемлемо, но в реальной жизни и в бизнесе, который отражает свойства реальной жизни, практически нет жестких связей. Здесь нет прямой детерминированности и из «A» не всегда следует «B». В неопределенности и заключается основное отличие систем автоматизации бизнеса от технических систем управления, долгое время остававшееся неосознанным. Только сейчас, когда родилась идея построения архитектур, ориентированных на сервисы, это обстоятельство стало очевидным. Собственно, о нем и говорил Рамбо.

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

Эволюция архитектур или архитектурная избыточность

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

Такой объект не может строиться с использованием несогласованных архитектурных решений. Для того чтобы система управления стала работоспособной, необходим единый проект с отдельными допустимыми архитектурными особенностями компонентов и нижних уровней. На данный момент представляется, что сервис-ориентированные архитектуры могут оказаться стержневой структурой, вокруг которой будут консолидироваться разные взгляды и концепции.

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

Когда-то его смысл был чрезвычайно ограниченным, однако представление об архитектуре оставалось вполне определенным. Тогда под «архитектурой» понимали лишь набор команд арифметико-логического устройства, которое со временем стали назвать процессором. Систему команд использовали программисты, писавшие приложения в кодах, и разработчики компиляторов; в ней были выражены все архитектурные особенности процессора.

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

Затем представление об архитектуре сдвинулось в сторону систем. Появились двухзвенные клиент-серверные архитектуры, а вслед за ними — и многозвенные архитектуры. Соответственно изменился и круг специалистов, причастных к архитектурам: в него вошли разработчики приложений и проектировщики бизнес-процессов.

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

В самое последнее время появились новые архитектуры — не только ориентированные на сервисы, но и многие другие. Среди них можно назвать архитектуры, опирающиеся на события (event driven architecture), дата-центричные архитектуры (data-centric architecture), архитектуры, движимые процессами (process driven architecture), проникающие архитектуры (pervasive architecture), архитектуры, основанные на потребностях (needs-based architecture), архитектуры, опирающиеся на модели (model-driven architecture) и т.д. Все они, в конечном счете, являются попытками выйти на следующий по отношению к информационной системе уровень — архитектуры предприятия в целом.

Конечная цель большинства архитектурных подходов состоит в создании предприятия, работающего в режиме реального времени (real-time enterprise), информационная система которого поддерживает выполнение всего комплекса бизнес-процессов для обеспечения функционала такой компании. Самая знаменательная особенность перехода на следующий уровень заключается в том, что круг «причастных» специалистов еще более расширился, а архитектура предприятия (точнее, EA) становится областью интереса высших руководителей, в частности генерального директора.

Архитектура предприятия

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

Обычно под EA понимают комплексную модель предприятия, некий руководящий план его работы, который интегрирует цели бизнеса (в том числе видение, стратегию, принципы руководства) с его практическими операциями, средствами автоматизации (такими, как приложения и базы данных) и с поддерживающей технической инфраструктурой. В отечественной литературе можно найти следующее определение: «Производственная архитектура — это структурированное описание делопроизводства и бизнес-процессов предприятия, приложений и методов автоматизации, поддерживающих бизнес-процессы, а также информация, технологии и инфраструктура, необходимые для их выполнения. Производственная архитектура позволяет выработать целостный план работ и скоординированных проектов, необходимых для претворения в жизнь задач развития информационной инфраструктуры предприятия» (см. www.technical-translation.ru).

Состав EA определяют по-разному, но наиболее логичным представляется деление на четыре подмножества, отраженное в The Open Group Architecture Framework (TOGAF, www.opengroup.com):

  • архитектура бизнеса;
  • архитектура данных;
  • архитектура приложений;
  • технологическая архитектура.

Первым, еще в 60-е годы, начал разрабатывать архитектурные методики в приложении к проблемам управления предприятием Дэвид Уолкер, директор по архитектурным разработкам одного из подразделений корпорации IBM. Он создал набор документов, ставший позднее известным как система планирования бизнеса (business systems planning, BSP). Непосредственным учеником Уолкера и продолжателем его дела стал Джон Захман, который на основе BSP предпринял исследование Business Information Control Study и в 1982 году опубликовал его результаты в журнале IBM Systems Journal. На основе последующих исследований он в 1987 году написал еще один ставший классическим труд — A Framework for Information Systems Architecture. «Каркасная модель» Захмана на протяжении последующих лет эволюционировала, но до сих пор является основополагающей во всех работах института Zachman Institute for Framework Advancement (ZIFA, http://www.zifa.com).

Вплоть до последнего времени направление EA занимало место, несколько изолированное от общего потока ИТ и достаточное скромное по масштабам. Из доступных русскоязычных источников, дающих представление о EA в традиционном (существующем более десяти лет) понимании, можно рекомендовать статью Георгия Калянова «Архитектура предприятия и инструменты ее моделирования» («Автоматизация в промышленности», 2004, № 7). Из нее же можно узнать, что во всем мире в этом сегменте рынка работает примерно семь компаний со средним доходом 10-15 млн. долл., что, по меркам ИТ-производителей, совсем немного.

Однако оторванности EA от реальных информационных технологий поддержки бизнеса подходит конец. Нынешний ограниченный экономический потенциал этого направления находится в явной диспропорции с чрезмерно оптимистичными прогнозами аналитиков относительно того, что можно ожидать в ближайшие годы в сфере EA. Опыт подсказывает, что следует доверять не всем радужным прогнозам, в том числе со стороны Gartner, но находящиеся в гуще событий эксперты этой компании иногда вполне корректно определяют основные тенденции. Так вот, менее года назад Gartner опубликовала отчет, в котором утверждается, что основными источниками грядущей трансформации EA в одно из важнейших направлений развития корпоративных информационных систем станут архитектуры, ориентированные на сервисы и на управление бизнес-процессами (business process management, BPM). Комбинация SOA и BPM позволит создать новый класс бизнес-приложений SOBA (service-oriented business applications), пик интереса к которым предсказывают на 2007 год.

Если обратиться к известной «кривой хайпа» Web-сервисов, публикуемой Gartner, можно обнаружить следующее: в качестве средств, служащих для создания бизнес-моделей, Web-сервисы уже перешли через пик ожидания, а в качестве средств управления бизнес-процессами находятся на подходе к пику. Соответственно, время их внедрения в первом случае находится в интервале от двух до пяти лет, а во втором — от пяти до десяти лет.

EA и феномен SOA

Одно из возможных объяснений того, почему классическая архитектура EA остается в большей мере бумажной и почему именно сервисы могут исправить сложившееся положение, дал Клив Финкельштейн, известный специалист в области информационной инженерии и близкий соратник Захмана. В своей статье «Предприятие, переход в XXI век» (Clive Finkelstein, Evolution to the 21st Century Enterprise, DM Review Magazine, May 2004) он приходит к парадоксальному выводу.

Несмотря на очевидный технический прогресс, автоматизацию технологических процессов и прочие достижения, говорит Финкельштейн, с организационной точки зрения современные предприятия остались теми же сложными цепочками, составленными из множества преимущественно ручных операций, какими они были в два предшествующих столетия. Организационные принципы производственных процессов остались практически неизменными и сейчас являются примерно такими же, какими их описал в конце XVIII века великий политэконом Адам Смит (да-да, тот самый, которого читал Евгений Онегин). Для управления этими несовершенными производственными процессами потребовалось создать сложную, фактически управляемую тоже вручную систему бизнес-процессов. В результате и система управления бизнесом оказалась несовершенной.

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

Скверная ситуация еще больше усугубляется тем, что со второй половины 90-х годов с внедрением Internet-технологий хаотическое состояние мигрирует из внутренних систем на внешнее клиентское представление, на системы «переднего края», на Web-сайты предприятий. Благодаря новым технологиям партнеры, клиенты и другие желающие, казалось бы, получили техническую возможность доступа корпоративным ресурсам, но в той форме, которая не дает им реальных преимуществ.

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

Устранение «зазора»

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

В опубликованном компанией Mega отчете Challenges and Methods for the Implementation of Service Oriented Architectures: An Updated Enterprise Architecture (www.bptrends.com/publicationfiles) находим такое описание: «Сервис — это автономный (самоуправляемый) модуль, способный обрабатывать данные и оперировать ими, имеющий возможность взаимодействовать с окружающей средой посредством сообщений. Обмен сообщениями осуществляется через «обменные контакты». По сравнению с традиционными описаниями сервисов, новым здесь является следующее:

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

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

Взаимосвязь между ИТ и бизнесом с использованием сервисов

Но как реально отобразить бизнес в форме сервисов? Аналитики Mega Group предложили свой подход, практическую сторону которого пока оценить сложно, но который очень интересен как пример приложения SOA к EA. В его основу положена метафора плана городской застройки, которая позволяет создать План ИТ-застройки (IT City Plan). За свою историю человечество выработало стратегию построения громадных городских инфраструктур, связанных теми или иными сервисами. Подобно городу, предприятие нужно разбить на отдельные «дома, районы, улицы и проспекты». Они должны бесконфликтно распределять между собой основные сервисы, как в городе распределяются энергия, водоснабжение, канализация и т.д.

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

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

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

  • Бизнес предъявляет требования к сервисам, а сервисы определяют развитие технологий. Другими словами, сервисы выполняют функцию промежуточного уровня между бизнесом и технологиями, абстрагирующего требования и переводящего потребности бизнеса на язык технологий.
  • Самое критичное из этих требований, business agility, заключается не в удовлетворении сиюминутных запросов, а в учете комплекса «метазапросов».
  • SOA не существует в законсервированном виде. Один из бытующих ныне афоризмов гласит: «Успешная архитектура SOA всегда в движении». В новых условиях нормальным состоянием ИТ-среды становится ее постоянное обновление.