Говорим SOA, подразумеваем EA

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

Леонид Черняк

Сегодня редкая ИТ-компания не говорит о 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 заключается не только и не столько в ее практической полезности. Скорее она состоит в возможности иного понимания задач автоматизации бизнеса — не такого лобового и прямолинейного, как прежде.

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

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

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

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

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

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

17.05.2005г