Архитектура предприятия и сервисный подход. ЧАСТЬ 2

ГРАНИЦЫ ПРИМЕНЕНИЯ СЕРВИСНОГО ПРОЕКТИРОВАНИЯ БИЗНЕСА

Ограничения подхода

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

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

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

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

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

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

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

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

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

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

Противопоказания

Следует учитывать, что сервисная трансформация предприятия далеко не всегда нужна и даже не всегда возможна или полезна.

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

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

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

ОТ БИЗНЕС-СЕРВИСОВ К ПРИКЛАДНЫМ И ТЕХНИЧЕСКИМ СЕРВИСАМ

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

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

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

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

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

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

Сервис на прикладном уровне

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

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

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

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

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

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

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

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

Таким образом, для отображения бизнес-сервиса на прикладные сервисы информационной системы необходимо:

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

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

Отображение бизнес-сервисов в системные элементы

Один из универсальных подходов отображения бизнес-сервисов в системные элементы предлагается стандартом ISO/IEC 15288.

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

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

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

Дополнения правил проектирования эталонными моделями

Помощь в разрешении вышеуказанной неоднозначности можно найти в других стандартах.

Референсная модель OASIS. Так, референсная модель для SOA, предлагаемая Organization for the Advancement of Structured Information Standards (//www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm), задает абстрактные общие требования, необходимые для понимания того, как выделяются важнейшие сущности и связи между ними в сервис-ориентированной среде. Этого недостаточно для решения конкретных задач проектирования, поскольку для этого требуется выделить несколько точек зрения на сервисно-ориентированную среду, определить механизм согласования этих точек зрения между собой и предложить эталонные модели, которые будут использоваться для выработки конкретных проектных решений, применительно к выбранным точкам зрения.

Эталонные модели FEA. Для показа возможностей и проблем поддержки отображений сервисов «верхних» уровней в сервисы более «нижних» уровней воспользуемся моделями BRM (Business Reference Model), SRM (Service Component Reference Model), TRM (Technical Reference Model), разработанными для поддержки общей схемы архитектуры предприятия в варианте FEA (Federal Enterprise Architecture). Характеристики и возможности совокупности этих эталонных моделей таковы (рис. 4):

• сервисы являются базовым элементом каждой из моделей (BRM, SRM, TRM);
• идея сквозной связи сервисов представлена в схемах взаимосвязи указанных моделей в рамочной схеме АП FEAF и в модели FEA PRM;
• бизнес-сервисы вводятся в BRM, но на очень высоком уровне агрегации и обобщения сервисов (при этом конкретное наполнение в первую очередь этой модели ориентировано на бизнес-сервисы органов государственной власти);
• если бизнес-сервисы BRM представить как «вертикальные» отраслевые функции, то прикладные сервисы SRM можно представить коллекцией прикладных сервисов, расположенной в горизонтальной плоскости и ортогональных бизнес-сервисам в том смысле, что практически каждый прикладной сервис может использоваться при реализации любого бизнес-сервиса (в том числе не относящегося к сервисам органов власти);
• аналогичным образом TRM представляет стандартизированную таксономию технических сервисов, спецификаций и технологий, которая ортогональна как прикладным, так и бизнес-сервисам в том смысле, что практически технический сервис может использоваться при реализации любого бизнес- и прикладного сервиса.

Целостный подход к ССП

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

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

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

ЗАКЛЮЧЕНИЕ

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

Об авторах:

Батоврин Виктор Константинович — зав. кафедрой ИС МИРЭА, ведущий консультант Фонда ФОСТАС,
Зиндер Евгений Захарович — президент Фонда ФОСТАС (г. Москва).