ССП и сервисно-ориентированное предприятие (SOE). Ограничения подхода

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

В ССП бизнес-сервисы рассматриваются в первую очередь как часть хорошо и особым образом организованного предприятия - сервисно-ориентированного (SOE, Service Oriented Enterprise). Причем, такая организация предприятия в качестве обязательного начального условия не выдвигается, а для того, чтобы она могла возникнуть, выполняется набор специальных мероприятий, в том числе:

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

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

3) Формализация бизнес-сервисов и достижение определенного уровня абстракции и агрегации в описании моделей бизнес-сервисов. Целесообразно сохранение этого уровня в пределах всего предприятия, что иногда доводится до принципа: компоненты бизнес-сервиса не являются бизнес-сервисами. Это необходимо для обеспечения изолированности сервисов и для сохранения целостной и однородной, то есть достаточно прозрачной и устойчивой к изменениям картины взаимодействия сервисов. Желательно представление таким образом всех функций/процессов предприятия (его достаточно крупной части).

Если трансформация предприятия и его бизнес-архитектуры в SOE будет оценена как целесообразная, формализация бизнес-сервисов может включать в себя "задел" для выполнения работ по их отображению на уровень прикладных сервисов. Для этого целесообразен акцент на организации информационных потоков, на природе и характеристиках сущностей (entities), участвующих в формировании сервисов и на взаимодействии между ними.

Отметим, что в настоящее время даже для сравнительно узких предметных областей отсутствуют обоснованные критерии и однозначные правила выделения на предприятии базового набора бизнес-сервисов и определения их характеристик (в том числе грануляции, "размера" связанных с ними действий). При осуществленной ориентации предприятия на процессный подход обычно используется подход декомпозиции сверху-вниз. Базовые бизнес-процессы (процессы "верхнего уровня детализации") подвергаются нескольким шагам декомпозиции на более простые бизнес-процессы (бизнес-процедуры), с достаточной для адаптированной парадигмы сервисного подхода степенью изолированности и грануляции. Коренные причины неоднозначности в выделении сервисов аналогичны тем, что порождают неоднозначность выделения самих бизнес-процессов. Однако к ним на каждом шаге добавляются неоднозначности, порождаемые недетерминированными решениями по декомпозиции и неопределенностью будущих требований к грануляции бизнес-сервисов.

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

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

Следует учитывать, что сервисная трансформация предприятия далеко не всегда нужна и даже не всегда возможна или полезна. Например, при реальных ограничениях предприятия на бизнес-ресурсы обеспечивать независимость, изоляцию бизнес-сервисов друг от друга, как это рекомендуется рядом методик, далеко не всегда возможно. К этому же может привести, например,  наличие некоторых сервисов или требований к их выполнению с наивысшим приоритетом, требующим изъятия ресурсов у других сервисов. Требования соблюдения жестких графиков выполнения тех или иных преопределенных комплексов строго взаимосвязанных работ, может лишать смысла изоляцию таких работ, и т.п. Могут существовать предприятия (подразделения организаций), для которых как минимум SOE, а возможно и SOA нерационально или даже вредно. Однозначной общей рекомендации (по крайней мере, на данном периоде развития и бизнеса и ИТ) без учета конкретных особенностей предприятия давать в этом вопросе нельзя. Стоит учитывать наличие больших участков бизнес-структур, отличающихся между собой по характеру производства и стилю управления, например, жесткой дисциплиной, большими детерминизмом и консервативностью процессов. Либо, напротив, большими требованиями к взаимовыручке и требованиями к изменению работ по ходу их выполнения. В конкретных условиях переход на сервисную ориентацию может губительно сказаться на предприятии.

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

От бизнес-сервисов к прикладным и техническим сервисам: проблемы и рамочные стандарты

Дальнейшее изложение не будет повторять достаточно широко тиражируемые материалы по развитию SOA и SOC (Service Oriented Computing). Его задача - показать наиболее принципиальные проблемы ССП и возможности его поддержки существующими стандартами, включая признанные эталонные архитектурные модели, имеющие сервисную ориентацию.

Для решения задачи определения взаимосвязей между бизнес- и прикладными сервисами  приходится предлагать специальные методы анализа и синтеза "сквозной" сервисной архитектуры. Эта работа для больших организаций, как правило, весьма объемна и сложна. Примером может служить набор нормативных документов министерства обороны США по основам архитектурного проектирования (DoD Architecture Framework), где вопросам связывания между собой сервисов различных типов и уровней посвящено несколько сот страниц.

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

(а) прикладных сервисов ИС и

(б) базовых ИТ-сервисов (технических сервисов).

При этом существенно, что сервисы этих архитектурных слоев не являются ни конкретизацией/обобщением, ни непосредственной агрегацией/детализацией друг друга.

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

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

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

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

В соответствии с Web Services Glossary сервис (в общей трактовке этого глоссария, а не, например, Веб-сервис только) понимается как

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

Это не только абстрактное, но и не очень конструктивное определение.

В соответствии с определением [13] под сервисом понимается

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

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

Надо учитывать, что бизнес-сервис

- инициируется или выполняется проактивно по любому каналу, не обязательно связанному с ИТ,

- может состоять полностью или частично из неавтоматизированных операций и интерфейсов,

- при своем выполнении оперирует как информационными, так и любыми иными ресурсами (людскими, материальными средствами, финансовыми, энергетическими),

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

Таким образом, для отображения бизнес-сервиса на прикладные сервисы ИС необходимо

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

- перейти от рассмотрения бизнес-сервиса как "черного ящика" к рассмотрению вариантов внутреннего устройства реализующего этот сервис действия (бизнес-процесса, бизнес-процедуры) и выделить совокупности автоматизируемых действий пользователя и оператора,

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

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

(Очевидно, что на всех шагах этого перехода постоянно приходится решать архитектурные задачи, не имеющие однозначного решения.)

В соответствии с рекомендациями стандарта ISO/IEC 15288 также предусмотрены отображения [бизнес-]сервисов, определенных  с точки зрения ЗЛ, в "функции системы", и отображения [бизнес-]сервисов и функций ИС в архитектурные "системные элементы".

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

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

Возможности и проблемы дополнения правил проектирования эталонными моделями сервисов

Референсная модель для SOA, предлагаемая в драфте [13], задает абстрактные общие требования, необходимые для понимания того, как выделяются важнейшие сущности (entities) и связи между ними в сервис-ориентированной среде. Этого недостаточно для решении конкретных задач проектирования, поскольку для этого требуется выделить несколько точек зрения на сервисно-ориентированную среду, определить механизм согласования этих точек зрения между собой и предложить эталонные модели, которые будут использоваться для выработки конкретных проектных решений, применительно к выбранным точкам зрения.

Для показа возможностей и проблем поддержки отображений сервисов "верхних" уровней в сервисы более "нижних" уровней воспользуемся моделями BRM, SRM и TRM, разработанными для поддержки общей схемы АП в варианте FEAF [10].

Характеристики и возможности совокупности эталонных моделей FEAF таковы:

- сервисы являются базовым элементом каждой из моделей: BRM (Business Reference Model), SRM (Service Component Reference Model), TRM (Technical Reference Model),

- идея сквозной связи сервисов, представлена в схемах взаимосвязи указанных моделей в рамочной схеме АП FEAF и в модели FEA PRM (Performance Reference Model),

- бизнес-сервисы вводятся в BRM, но на очень высоком уровне агрегации и обобщения сервисов (при этом конкретное наполнение в первую очередь этой модели ориентировано на бизнес-сервисы органов государственной власти),

- если бизнес-сервисы BRM представить как "вертикальные" отраслевые функции, то прикладные сервисы SRM можно представить коллекцией прикладных сервисов, расположенной в горизонтальной плоскости (см. рисунок),  ортогональных бизнес-сервисам в том смысле, что практически каждый  прикладной сервис может использоваться при реализации любого бизнес-сервиса (в том числе, не относящегося к сервисам органов власти),

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

В итоге, возникает схема проектирования, в которой

- стандарт ИСО/МЭК 15288 используется для организации ССП в целом: сквозного сервисного  проектирования на пространстве от бизнес-сервисов до базовых технических ИТ-сервисов; при этом он не охватывает стадию проектирования сервисного предприятия SOE в смысле, описанном выше, из-за чего эту стадию надо включать дополнительно,

- "недосказанности" этого стандарта возмещаются возможностями использования согласованных совокупностей моделей сервисов в эталонных архитектурных сервисных моделях (например, моделях FEA),

- возникает концепция трехмерной (как минимум) схемы взаимосвязей сервисов, которые можно использовать в проектировании; эта схема может быть представлена как совокупность двух (или более) двумерных матриц, что проще в использовании, чем трехмерная схема,

- схема взаимосвязи сервисов используется при выборе отдельных архитектурных решений и элементов, а также для установления горизонтальных и вертикальных связей между ними,

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

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

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

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

Заключение

За последние 3-5 лет в мире в области стратегии использования ИТ и проектирования систем уровня предприятия произошел переход к широкому практическому использованию дисциплины "Архитектура Предприятия" (АП, Enterprise Architecture) на качественно новом уровне рассмотрения действительно комплексной архитектуры, не ориентированной только на ИТ. Это касается предприятий всех масштабов и отраслей, коммерческих компаний и государственных органов. АП используется не как "системная" и/или "ИТ-архитектура" (в смысле архитектуры информационных систем, ИТ-инфраструктуры и т.п.), но как инструмент стратегического управления предприятием. При этом из инструмента ИТ-директора и CIO она стала инструментом и областью ответственности Советов Директоров, применяемым, в том числе, для планирования изменений в организации.

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

Говоря о развитии и перспективах АП в России можно отметить, что уже цитированный анализ мирового применения АП в 2005 году показал следующее:

несмотря на отмечающееся начало и рост применения АП по уровню реального интереса к АП Россия не вошла в группу первых 20 стран, оставшись позади Китая (14 место), Бразилии и Испании (19 и 20 места).

Наблюдающиеся попытки использования АП сводятся к частным, ограниченным областям (ИТ-архитектура, "системная архитектура"). Должности и подразделения, в названиях которых есть слово "архитектура", стали появляться, но еще не наполняются полноценным содержанием АП. Можно предположить, что период заметного отставания России в этой области продлится не менее, а скорее более пяти лет. Это отстав

Источник: http://www.fostas.ru/library/batovrin_zinder_2006.doc