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

«ТИХАЯ РЕВОЛЮЦИЯ» И «СЕРЕБРЯНЫЕ ПУЛИ»

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

Чтобы разобраться в АП, ССП, SOA, рассмотрим, как связано проектирование сервисно-ориентированной системы с современным пониманием сервиса и последовательным проведением сервисного подхода на всем пути архитектурного проектирования и перехода к реализации систем. Определим границы применения сервисного проектирования бизнеса.

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

Но начать статью следует с обзора состояния проблемы.

АРХИТЕКТУРА ПРЕДПРИЯТИЯ: МИРОВЫЕ ТЕНДЕНЦИИ

Одним из важнейших итогов последних лет в области стратегии использования ИТ и проектирования систем уровня предприятия стало выделение архитектурного подхода в качестве необходимого и приоритетного. На рис. 1 представлены данные IFEAD (Institute For Enterprise Architecture Developments) о доле предприятий, активно работающих с АП. Происходит резкий рост числа таких предприятий всех масштабов и отраслей, коммерческих компаний и государственных органов (рис. 2). В развитых странах вопрос о том, что полномасштабное использование АП действительно дает принципиально новые возможности, практически уже не дискутируется.

Что касается России, то по данным IFEAD около 8% организаций, охваченных исследованием в области АП, находились в России. По уровню реального интереса к АП Россия не вошла в группу первых 20 стран, оставшись позади Китая, Бразилии и Испании (14, 19 и 20 места соответственно). В российской практике попытки использования АП нередко сводятся к частным областям (ИТ-архитектура, «системная архитектура»). Начали появляться должности и подразделения, в названиях которых есть слово «архитектура», но большинство из них находится ниже того уровня, за которым начинается переход от работы с технологической архитектурой к работе с АП как с комплексной архитектурой. Можно предположить, что период заметного отставания России в этой области продлится не менее пяти лет. Это отставание может быть преодолено при выполнении нескольких условий. В частности, если:

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

Проведенные IFEAD исследования показали, что:

АП используется не только в больших, но и в малых организациях (от 100 до 1000 работающих) и на предприятиях всех отраслей;
• АП используется как инструмент стратегического управления, при этом из инструмента ИТ-директора, используемого только для планирования ИТ и создания ИС, она стала инструментом (и областью ответственности) советов директоров, применяемым для планирования изменений в организации;
• организации, которые используют инструмент АП, имеют в своем штате позиции «архитектора предприятия» и архитекторов других областей деятельности;
• разворачивание АП как профессиональной дисциплины все еще продолжается, продолжается сдвиг от технологических вопросов к обще-деловому спектру проблем, растут потребности в образовании и тренинге в области АП;
• в части архитектурной работы с бизнес-процессами широко используются принятые техники моделирования бизнес-процессов, при этом стандартом является BPML (Business Process Modeling Language);
• все больше организаций определяют собственную общую, «рамочную» (framework) схему АП вместо использования или простой адаптации существующих схем.

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

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

ФАКТОРЫ СЛОЖНОСТИ — МНОГОМЕРНОСТЬ АРХИТЕКТУРНЫХ СХЕМ

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

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

• ось «архитектурных аспектов» предприятия или системы (соответствует столбцам матрицы Захмана);
• ось «представлений» предприятия или системы (соответствует строкам матрицы Захмана, см. рис. 3); ось времени развития архитектуры предприятия или системы (стадия проектного цикла, стадия ЖЦ системы, витки развития предприятия и этапы этих витков);
• ось обобщения/конкретизации архитектурных блоков и элементов;
• ось агрегации/детализации архитектурных блоков и элементов;
• ось прикладного сегментирования схемы, как, например, в подходе FEAF (Federal Enterprise Architecture Framework).

Измерения, указанные в этом списке, можно обнаружить в схемах, базирующихся на международных стандартах (ISO 15704 GERAM, CEN/ISO19439) и на стандартах де-факто (схема Захмана, а также схема FEAF и ряд других), а также на схемах, которые включаются в известные системы моделирования (например ARIS).

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

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

СЕРВИСНАЯ АРХИТЕКТУРА ПРЕДПРИЯТИЯ

Одним из важных итогов и одновременно одной из тенденций развития является появление сервисно-ориентированной АП (не путать с SOA). Она отличается фокусированием на предоставление услуг (сервисов) и на работе с сервисами как с центральным архитектурным элементом предприятия. Такая АП существенно шире, чем SOA, она охватывает сервисное осмысление и представление бизнеса как такового, а также некоторые сервисные структуры вычислительных ресурсов — SOC (Services Oriented Computing). Вместе с тем сервисно-ориентированная АП может рассматриваться как одно из упрощений АП, достигаемое за счет достаточно сильного упрощения некоторых архитектурных аспектов и измерений.

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

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

Согласно стандарту ISO/IEC 15288, анализ и проектирование системы (в нашем случае — системы типа «предприятие») начинается с выяснения потребностей заинтересованных лиц (ЗЛ, рис. 5), выраженных в «необходимых им сервисах».

Бизнес-сервисы в системном проектировании

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

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

В подходах к бизнес-сервисам многое позаимствовано из современных представлений об ИТ-сервисе. В то же время в контексте проектирования АП речь идет о бизнес-сервисах как о продуктах особого рода (слово «бизнес» понимается здесь как любая деятельность людей, не обязательно связанная с извлечением прибыли). Это особенно важно, поскольку побуждает смотреть на систему не как на ИС в узком ее смысле, а как на автоматизированное предприятие (подразделение, организацию, объединение или кооперацию организаций или их подразделений). Однако отметим наличие и в самих стандартах многих «недосказанностей». Так, тот же стандарт ISO/IEC 15288 не говорит ничего о том, как с бизнес-сервисами связываются сервисы других типов, а выявление потребностей ЗЛ в терминах сервисов в недостаточном объеме предполагает решение специфической проектной задачи преобразования самого предприятия к сервисной форме.

В связи с этим надо уточнить трактовку услуги (сервиса) как понятия — по крайней мере для использования в ССП и в сервисно-ориентированной АП (которая существенно шире SOA). При этом наибольшее внимание мы будем уделять т. н. бизнес-сервисам и вопросам перехода от них к прикладным сервисам ИС.

Определения бизнес-сервиса

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

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

Во избежание подобных последствий начиная со следующего раздела здесь употребляется единственное слово «сервис». (Конечно, этим не делается попытка искоренения из ИТ-обихода слов «услуга» и «служба» как таковых.) Для выбора трактовки в ССП рассмотрим три толкования слова «услуга»: общенормативное толкование в русском языке, термин service в ISO 9000:2005 и тот же термин в рамках архитектурного подхода IFEAD и ряда других организаций.

Толковый словарь Ушакова (современная редакция) первым значением определяет услугу как действие, приносящее пользу другому.

По ISO 9000 service — это результат действия. При этом сервис самостоятельно не определяется, но вводится как одна из разновидностей продукта (product) , возможно, запрошенного заказчиком, хотя явного указания на это нет, но всегда предоставляемого поставщиком заказчику. Для этой разновидности продукта говорится, что в общем случае результат действия носит «нематериальный» (intangible) характер.

Трактовка сервиса-услуги именно как результата действия (данная даже не в определении как таковом, а в примечаниях к определению термина «product») в рамках ISO 9000 не совсем однозначна, т. к. в пояснениях к стандарту в одних случаях service — это транспортировка (процесс), а в других — данное продавцом объяснение (результат).

В трактовке IFEAD (более близкой Ушакову, чем ISO 9000), service — это осуществление хорошо определенной деловой функциональности, которая действует независимо от состояния любого другого сервиса, определенного в системе. Сервисы имеют хорошо определенный набор интерфейсов и действуют через предопределенный контракт (т. е. посредством строгого выполнения некоторых соглашений) между клиентом сервиса и самим сервисом. Сервис — это строго определенная работа, выполненная поставщиком сервиса («сервис-провайдером») для достижения желаемых конечных результатов для потребителя сервиса. Поставщик и потребитель — роли, которые играют организационные единицы или программные агенты от имени их владельцев.

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

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

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

Результативность сервиса

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

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

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

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

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

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

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

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

Среда и качества бизнес-сервисов

Чтобы осуществить сервис, помимо его действия и результата, необходимо обеспечить доставку сервиса (service delivery) клиенту (заказчику), доступ к нему (service access), причем действия по доставке результата и организации доступа к нему также могут рассматриваться как сервис. Это значит, что к сервисам имеют отношение и некоторые характеристики внешней среды, с которыми может быть связана реальная выполнимость сервиса и достижение для его потребителя желаемых конечных результатов. Например, реальность, требующая учета при планировании сервисов, может состоять в том, что сервис предоставляется сервис-провайдером, но блокируется в каналах доставки, или сервис предоставляется, но в среде, в которой использование результатов приносит вред вместо ожидаемой пользы. Возможны много причин конфликтных ситуаций, существующие в реальной бизнес-среде, отличающейся от идеальной сервисно-ориентированной абстракции. Для реализации сервиса важны и другие характеристики внешней среды.

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

ЗАКЛЮЧЕНИЕ

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

Одной из актуальных разновидностей АП является «Сквозное Сервисно-ориентированное Проектирование» (ССП), охватывающее гораздо большую область, чем широко рекламируемый сегодня подход SOA. ССП может опираться на современные подходы и стандарты системного проектирования, которые понимают систему, в том числе, как предприятие (обобщенное) и предусматривают применение сервисной идеологии в той или иной форме с самых первых шагов проектирования предприятия, а также его ИС. В ССП бизнес-сервисы рассматриваются в первую очередь как часть хорошо и особым образом организованного предприятия — сервисно-ориентированного (SOE, Service Oriented Enterprise).

Об авторах:

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