Сервис-ориентированная архитектура: от концепции к применению

--> Дата: Июн 16, 2008 696

Превращение SOA из концепции в инструмент возможно только тогда, когда все заинтересованные стороны понимают принципы процессного подхода и готовы применять его в качестве основы для управления изменениями в компании.

Уже несколько лет в России, как и во всем мире, обсуждаются вопросы, связанные с применением принципов сервис-ориентированной архитектуры (Service Oriented Architecture, SOA). Многие производители информационных систем уже заявили о поддержке принципов SOA, но реализация этих принципов на практике пока ограничивается единичными случаями. Мы рассмотрим предпосылки появления SOA и основные требования, которые должна выполнить компания, чтобы успешно применять концепцию SOA в своей практике.

«Проблема в том, что в аббревиатуре SOA люди больше обращают внимание на «service oriented», нежели на «architecture». Однако именно архитектура и дисциплина могут помочь SOA принести реальный результат».

Джеймс Гавернор (James Governor), ведущий аналитик, компания Redmonk

Термин SOA пока что несет на себе сильный маркетинговый отпечаток, а для самого понятия SOA на сегодняшний день все еще существуют различные трактовки. Многие отождествляют SOA с технологией Web-сервисов или определенными информационными системами, например, системами для управления бизнес-процессами (Business Process Management, BPM). Но SOA — это не коробочный продукт или технология, а идеология информатизации бизнеса, основанная на процессном подходе и методологии управления бизнес-процессами BPM.

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

Можно сказать, что SOA — это развитие известных принципов структурного и объектно-ориентированного программирования: разработка элементарных стандартных процедур и функций, годных к многократному повторному использованию, но на новом витке. SOA требует перехода с уровня разработки, каталогизации и типизации отдельных детальных операций и алгоритмов на уровень бизнес-функций и бизнес-процессов. В случае использования SOA создание, внедрение или изменение бизнес-процесса представляет собой компоновку (оркестровку) ранее разработанных сервисов, предназначенных для автоматизации бизнес-функций.

Принципы SOA

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

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

Аналогичная ситуация складывается сейчас с информационными решениями. Многие уже поняли на своем опыте, что монолитные системы (ERP, CRM, SCM и т. д.) обладают двумя врожденными пороками: ограниченной гибкостью (не всегда позволяют внести требуемые изменения в необходимые сроки) и высокой стоимостью владения и внесения изменений. Эти два фактора критичны для современных компаний, работающих в высококонкурентном и динамичном мире, что заставляет их уделять пристальное внимание оптимизации в данной области.

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

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

Оценив сложившуюся маркетинговую ситуацию и потенциал SOA для бизнеса, ведущие поставщики информационных систем поспешили заявить о своей готовности к SOA. Не отставали здесь ни пресса, ни аналитики. Если вспомнить начало кампании в 2005 г., то все единодушно говорили о большом потенциале SOA, и как следствие в 2006–2007 гг. было начато множество пилотных проектов SOA. Затем появилась информация о первых результатах, первых трудностях и неудачах. Темпы развития рынка SOA оказались не столь высоки, как ожидалось. По данным аналитиков, 90% компаний, запустивших пилотные проекты, завязли в них.

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

Цели и средства внедрения SOA

Изначально при внедрении SOA ставятся следующие цели:

сокращение времени адаптации сложных информационных систем к постоянно изменяющимся бизнес-процессам компании;
снижение стоимости владения ИТ (Total Cost of Ownership, TCO) в масштабе времени — за счет сокращения затрат на проектирование, внедрение, документирование, внесение изменений и т. п.;
систематизация компонентов ИТ-архитектуры и повышение степени интегрированности информационных систем компании.

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

Так какие же технологические средства необходимы для внедрения SOA? Для начала это инструментарий документирования бизнес-процессов, далее репозиторий — библиотека унифицированных сервисов, позволяющая быстро компоновать новые автоматизированные процессы, далее — технология перехода от описания бизнес-процессов и определения сервисов к их реализации, например, с возможностью генерации BPEL, и, наконец, среда вызова сервисов и выполнения бизнес-процессов (рис. 1).

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

Помимо перечисленного инструментария для применения SOA очень важно обеспечить правильное выделение сервисов (рис. 2). Если сервисов будет очень много, то требуемая типизация не будет достигнута, но если сервисы будут слишком высокоуровневыми, то их применение будет затруднено из-за специфических различий в бизнес-процессах. При этом, с одной стороны, размер сервиса не должен сдерживать изменения процесса, с другой — он должен быть таким, чтобы им можно было свободно оперировать на уровне изменяемых бизнес-процессов.

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

Условия успешного применения SOA

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

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

Доходы будущих периодов

Этот тезис подтверждают и данные аналитиков: по прогнозу Aberdeen Group, в течение следующих пяти лет крупнейшие глобальные компании ожидают экономии до 53 трлн долл. за счет внедрения SOA. Эти данные заставляют задуматься над стратегическими вопросами применения SOA.

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

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

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

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

Игнорирование перечисленных условий и требований, чрезмерное увлечение технологической стороной в ущерб процессной грозят привести к совершенно противоположным результатам:

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

Заключение

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

Уроки первых проектов позволяют утверждать, что:

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

Не следует ждать немедленного сокращения времени внедрения и экономии от SOA: это «доходы будущих периодов», базирующиеся на предварительно созданной SOA-инфраструктуре и репозитории сервисов. Но если мы не хотим «остаться за бортом» и рассчитываем получить стратегические бизнес-преимущества, этим надо заниматься уже сейчас — потому что к 2010 г., согласно прогнозу аналитиков Gartner Group, по меньшей мере 65% больших компаний переведут более 35% своего портфеля приложений на SOA.

Андрей Коптелов, директор департамента развития и внедрения ИТ

Виктор Голубев, директор департамента продвижения продуктов и услуг компания «IDS Scheer Россия и страны СНГ»