Архитектура предприятия. Процессы разработки архитектур предприятия. Планирование архитектуры предприятия. Общая схема архитектурного процесса. Сервисный подход к управлению архитектурой предприятия. Модель процесса разработки и использования архитектуры. Методика Спивака. Разработка Плана реализации

Решение задач и выполнение научно-исследовательских разработок: Отправьте запрос сейчас: irina@bodrenko.org    
математика, IT, информатика, программирование, статистика, биостатистика, экономика, психология
Пришлите по e-mail: irina@bodrenko.org описание вашего задания, срок выполнения, стоимость





Архитектура предприятия.

 

Лекция 8.

 

Тема лекции: «Процессы разработки архитектур предприятия».

  1. Планирование архитектуры предприятия.
  2. Общая схема архитектурного процесса.
  3. Сервисный подход к управлению архитектурой предприятия.

1.    ПЛАНИРОВАНИЕ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ.

 

1.1.       Семь шагов архитектурного процесса в соответствии с методикой Спивака.

 

Один из признанных авторитетов в области корпоративной архитектуры Стивен Спивак (Steven Spewak) предложил удачную модель планирования архитектуры предприятия, которая называется EAP (Entrerprise Architecture Planning – Планирование архитектуры предприятия). Модель EAP соответствует описанному нами выше принципу сегментного подхода к разработке архитектуры и включает 7 шагов, определяющих эту архитектуру и соответствующий план ее реализации (миграции). Эти 7 компонент, условно изображенных на рисунке  1  в виде «свадебного торта», обозначают смещение фокуса приложения сил на каждом из шагов.

Рисунок  1. Методика EAP планирования Архитектуры предприятия.

 

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

 

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

 

Отличительными характеристиками этого подхода к планированию архитектуры являются следующие:

1)   в основе – потребности бизнеса, а не технологические факторы;

2)   основное внимание сосредоточено более на данных и потребностях в информации, чем на процессах;

3)   ответственность за процесс в большей степени несут представители бизнес-подразделений, чем специалисты по ИТ.

 

Если «наложить» методику EAP Спивака на модель архитектуры Захмана,  то можно сказать, что методика EAP является руководством по заполнению первых двух строк таблицы Захмана, которые описывают контекст архитектуры и концептуальную модель бизнеса предприятия, т.е. это перспективы, соответствующие представлениям об архитектуре бизнес-руководителей: «планировщика» и «владельца». Проектирование систем, которое начинается с третьей строки таблицы Захмана, остается за рамками методики Спивака.

 

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

 

1.2. Архитектура предприятия как планирование города.

 

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

 

Независимо от того, отвечаете ли вы за проект архитектуры предприятия в целом, или за внедрение отдельной CRM-системы, или за проект консолидации серверов – многому можно научиться, анализируя то, как современные города приспосабливаются под потребности своих жителей и потребности бизнеса. (Альтернативный взгляд: мы, как жители, приспосабливаемся под возможности города так же, как иногда приходится приспосабливаться под устаревший интерфейс прикладных систем). Заметим, что эта аналогия не оканчивается прямыми сравнениями типа город – совокупность ИТ-систем предприятия, здания – прикладные системы, городская инфраструктура – ИТ-инфраструктура. Много аналогий прослеживается в процессах планирования и развития города и планирования и развития ИТ-архитектуры.

 

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

 

Если вы пройдетесь по Москве или Санкт-Петербургу, то увидите удивительное разнообразие зданий, построенных в разные эпохи.  Древние монастыри и Кремль Москвы, классический стиль зданий, построенных после пожара в Москве 1812 года или дворцов в Санкт-Петербурге, ампир и, наконец, современные бизнес-центры, не говоря уже о скучных спальных районах застройки 60-80-х годов прошлого века.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Какие уроки можно извлечь из этой аналогии архитектуры информационных систем предприятия и городского планирования?

 

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

 

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

 

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

 

Четвертое: важность стабильной инфраструктуры. Инфраструктура ИТ должна обслуживать текущие потребности и в какой-то степени предвосхищать будущие потребности в системах.

 

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

 

Шестой вывод заключается в максимальном использовании того, что есть. Любой город старается по максимуму использовать ресурсы существующей инфраструктуры, прежде чем запускать новые дорогостоящие проекты ее обновления. Точно также большое количество имеющихся на предприятии унаследованных систем – это, скорее, актив, чем пассив, и его можно и нужно эффективно использовать. Функционал этих систем можно, в частности, «открыть» для интеграции с новыми прикладными системами, используя адаптеры и технологии web-сервисов.

 

 

2.    ОБЩАЯ СХЕМА АРХИТЕКТУРНОГО ПРОЦЕССА.

 

2.1. Модель процесса разработки и использования архитектуры.

 

Какое бы определение Архитектуры предприятия мы, в конечном итоге, ни выбрали, общими для всех методик описания архитектуры является систематическое и рекурсивное применение таких принципов, как:

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

2)   различные уровни детализации и абстракции для описания каждой из этих областей.

 

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

 

Рисунок 2. Схема процесса разработки архитектуры и стратегии ИТ.

 

Эта схема состоит из следующих шагов:

  1. Общим фоном для этого процесса является мониторинг существующих тенденций в области деятельности организации и тенденций в области развития информационных технологий.
  2. Анализ на бизнес-уровне. На первом этапе проводится анализ движущих сил, которые влияют на необходимость использования ИТ с точки зрения основных функций и бизнеса организации. Определяются требования бизнеса и технологии на текущем этапе и на перспективу, которые задают требования к информационным системам. Учитываются тенденции в развитии информационных технологий и мировых аналогов с учетом перспектив развития бизнеса.
  3. На основе этого анализа формулируются в самом общем виде требования к информационным технологиям с точки зрения информации (данных) и архитектуры ИТ.
  4. Принимаются общие для организации стандарты и понятия о том, что такое Архитектура предприятия: принципы, общие методы описания архитектуры и ее разделы, стандарты, конкретные продукты и технологии.
  5. Параллельно с этими процессами выполняется анализ на «системном уровне»: аудит используемых информационных технологий и программно-технических средств, аудит организации процессов управления ИТ, внедрения технологий и приложений.
  6. Результаты вышеперечисленных этапов являются основой для выполнения «Gap-анализа», т.е. выявления расхождений и различий между существующей ИТ-инфраструктурой и желаемой архитектурой предприятия.
  7. Результаты «Gap-анализа» ложатся в основу Плана миграции: определяются цели создания (модернизации) информационных систем и решаемых ими задач, согласовывается стратегия разработки и внедрения информационных технологий (перечень критических процессов, подлежащих автоматизации в первую очередь и т. д.), обсуждается план детального анализа.
  8. После этого начинается фаза реализации конкретных проектов в рамках выработанной на данный момент архитектуры предприятия.

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

 

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

 

Рисунок 3. Общая схема процесса разработки архитектуры.

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

 

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

 

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

 

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

 

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

 

Каждая итерация включает:

Этап 1: Описание или уточнение Общего видения (видение общих требований к архитектуре).

Этап 2: Описание или уточнение Концептуальной архитектуры, а также разработка и уточнение архитектуры отдельных представлений (или предметных областей, доменов): бизнес-архитектура, архитектура информации, архитектура приложений, технологическая архитектура и пр.

Этап 3: Разработка или уточнение Плана реализации.

 

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

 

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

 

Этап 1: Разработка Общего видения архитектуры.

 

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

 

Основными элементами Общего видения являются:

1)   описание технологических тенденций, важных для предприятия;

2)   идентификация бизнес-требований и стратегий;

3)   идентификация основных требований к информации и технологиям, которые важны с точки зрения реализации бизнес-стратегий;

4)   идентификация требований к архитектуре предприятия в целом.

 

Этап 2: Параллельная разработка Концептуальной архитектуры и частных Архитектур предметных областей.

 

На этом этапе ведется параллельная разработка Концептуальной архитектуры, основанной на ранее определенных принципах и лучших практиках, а также более детальная проработка Архитектур отдельных предметных областей.

 

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

 

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

 

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

 

Этап 3: Разработка Плана реализации.

 

Этап 3 включает в себя следующие два шага:

 

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

 

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

 

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

 

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

 

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

 

2.2. Направления разработки архитектуры: «сверху-вниз» или «снизу-вверх».

 

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

 

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

 

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

 

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

 

3. СЕРВИСНЫЙ ПОДХОД К УПРАВЛЕНИЮ АРХИТЕКТУРОЙ ПРЕДПРИЯТИЯ.

3.1. Предпосылки сервисного подхода.

СО СТОРОНЫ ЭКОНОМИКИ И БИЗНЕСА:

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

 

Рисунок 4. Возрастание роли услуг в мировой экономике.

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

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

В последнее время возникают и развиваются такие направления как Service Science Management and Engineering, представленное и развиваемое компанией IBM.  

 

СО СТОРОНЫ ИТ:

Понятие «сервис» хорошо известно в программировании, и в области проектирования информационных систем.

 

SOA родилась в новом веке, под воздействием эволюционного процесса развития подходов к программированию, а также проектированию и построению ИС. Эволюция развития подходов к построению ИС представлена на рисунке  5.

Рисунок  5.  Эволюция подходов к проектированию и построению ИС.

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

Сервисы используются для организации взаимодействия между деятельностью компании и программными приложениями (рисунок 6).

Рисунок 6. Иллюстрация роли сервисов как уровня взаимодействия между ИТ и бизнесом в концепции SOA (Источник: IBM).

SOA подразумевает наличие следующих компонентов:

- поставщика сервисов,

- потребителя сервисов,

- брокера сервисов.

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

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

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

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

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

 

Возникают такие понятия как «Software as a service» (SaaS), «Platform as a service» (PaaS), «Infrastructure as a service» (IaaS) (рисунок 7). За счет таких крупных игроков как Amazon, компании перестают содержать свою инфраструктуру и предпочитают «довериться профессионалу», получая необходимые услуги и не задумываясь о том, как это реализовано. Эти подходы отражают новые бизнес-модели, новое отношение к отрасти инфокоммуникационных технологий (ИКТ). Суть нового отношения сводится к тому, что поставка ИКТ становится все более централизованной и потребляется «по требованию» по аналогии с электричеством. Компании все меньше пытаются сделать сами и все больше приобретают ИТ в виде услуг от крупных провайдеров.

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

Рисунок 7. Концепция предоставления ИТ как услуг.

 

В 2008 году компания HP анонсировала свою новую концепцию «Everything as a service» (Shane Robison, HP executive vice president and Chief Strategy and Technology Officer, March 6, 2008, HP Labs event.).

 

Мышление в терминах сервисов и их применение также лежат в основе таких ключевых стандартов как ITIL, ITSM, COBIT и др.

Рисунок 8 обобщенно представляет взаимосвязанность ориентированного подхода на различных уровнях.

Рисунок 8. Сервис-ориентированная макро- и микро-среда.

 

3.2.               Сервис-ориентированная архитектура предприятия (Service Oriented Enterprise Architecture, SoEA): актуальность применения сервисного подхода на всех уровнях.

3.2.

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

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

Таким образом, речь идет о системе управления и том, какие сильные и слабые стороны она получает при выделении различных объектов.

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

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

В своей работе Е. З. Зиндер и В. К. Батоврин (см.: Зиндер Е. З., Батоврин В. К. Результаты и перспективы «тихой революции» архитектуры предприятия и сервисного подхода. 2006.

отмечают:

 

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

SoEA — СПОСОБ ПРОЕКТИРОВАНИЯ И ПРЕДСТАВЛЕНИЯ АРХИТЕКТУРЫ ПРЕДПРИЯТИЯ (ВКЛЮЧАЯ БИЗНЕС, ИТ- И ТЕХНОЛОГИЧЕСКИЙ УРОВЕНЬ), КАК СОВОКУПНОСТЬ ПРЕДОСТАВЛЯЕМЫХ СЕРВИСОВ.

Сервис-ориентированный подход связан с несколькими тенденциями:

1)   Новая значительная роль ИТ для бизнеса (ИТ все больше участвуют в создании ценности).

1)

2)   Переход от цепочки создания ценности к (value chain) к сетям создания ценности (value nets). В настоящее время важно не столько владеть активами, сколько иметь возможность предоставить клиенту что-то уникальное во взаимодействии с партнерами и поставщиками.

2)

3)   Высокая динамичность процессов (изменения процессов) и все большая адаптивность «на лету».

3)

4)   Горизонтальная специализация.

4)

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

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

На уровне оптимизации архитектуры ориентация на сервисы позволяет снизить дублирование и повысить гибкость.

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

Некоторые универсальные принципы объектного подхода (применяются и в сервисной архитектуре):

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

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

3. Инкапсуляция (позволяет скрывать внутреннюю логику реализации, выставляя наружу лишь внешний интерфейс);

4. Наследуемость (наследование свойств от родительского класса).

Также важной составляющей философии SOA является децентрализованное управление.

ОТЛИЧИТЕЛЬНЫЕ ОСОБЕННОСТИ СЕРВИС-ОРИЕНТИРОВАННОГО ПОДХОДА.

Сравнительные характеристики традиционного и сервис-ориентированного подхода к архитектуре предприятия приведены в следующей таблице (рисунок 9).

 

Область

Признак

Традиционное предприятие

Сервис-ориентированное предприятие

Бизнес-системы (бизнес-модели)

Роль ИТ

Поддерживающая роль ИТ, как ресурса.

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

 

Создание ценности

Ценность создается на этапах ЦСЦ, преимущественно в рамках одного предприятия.

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

Ценность создается вместе с потребителями.

 

Бизнес-требования

Бизнес-требования формируются, как правило,  в рамках одного подразделения или предприятия.

Бизнес-требования формируются для отрасли извне и могут быть  удовлетворены различными провайдерами сервисов.

Бизнес-процессы

Потоки работ и составные сервисы.

Последовательное выполнение работ, ценность создается кумулятивно, по выполнению ЦСЦ.

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

 

Проектирование

и создание процессов.

Процесс как последовательный поток работ с точками ветвлений (принятия решений). В фокусе моделирования – принцип декомпозиции.

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

Структурная организация

Структура

Иерархическая

Горизонтальная, сетевая структура, основанная на взаимообмене сервисами.

 

Посредничество

Ограничено

 

Посредничество в предоставлении сервисов.

 

Интерпретация определения сервиса.

Ограничено

 

Неотъемлемое условие сервис-ориентированной организации.

Рисунок 9. Сравнительные характеристики предприятий.

3.3.               Сервисы в стандартах и методологиях.

3.3.

Впервые ориентация на сервисы появилась методологии FEAF — Federal Enterprise Architecture Framework (правительство США) редакции 2006 года, где обозначен фокус на потоки услуг (service flow), что позволяет избежать субоптимизации (рисунок 10).

 

 

Рисунок 10.  Компоненты методологии Federal Enterprise Architecture Framework (FEAF).

Впоследствии «Service Component Reference Model» (SRM) становится одной из референтных моделей EAF.

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

IT Service Management (управление ИТ-услугами) (ITSM) — подход к управлению и организации ИТ-услуг, направленный на удовлетворение потребностей бизнеса. Именно вокруг услуг выстраиваются люди, процессы и технологии.

Значительно проработан подход SoEA в методологии Integrated Architecture Framework (IAF).

 Согласно Integrated Architecture Framework (IAF) бизнес-сервис представляет собой уникальную единицу бизнес-активности (element of business behavior), реализуемую определенной ролью и поддерживающую определенную бизнес-цель. Объединение этих трех координат: действия (activities), роли и цели позволяет максимально точно выделить сервисы. Сервисы могу определяться через призму целей, ролей, объектов, событий или процессов.

Сервисный подход также применяется в нотации моделирования ArchiMate, которая в свою очередь интегрирована с методологией TOGAF, а также в методологиях SAP Enterprise Service Architecture, DoDAF, MoDAF и NATO Architecture Framework.

3.4.               Применение сервисного подхода (подходы к реализации).

3.4.

Сервисы и процессы.

Сервисы и процессы очень взаимосвязаны. Michael Poulin (см.: Michael Poulin. Transition of the Mindset: Business Processes meet Business Services. – Orbus white paper, 2013. – 14c.)  пишет, что:

-         каждый бизнес-процесс есть бизнес-сервис, при этом обратное верно не всегда;

-

-         некоторые операции, входящие в состав сервиса, могут быть реализованы как процессы;

-

-         процессы могут включать сервисы более низких уровней.

-

ОБЪЕДИНЕНИЕ СЕРВИСОВ С ЦЕЛЬЮ ФОРМИРОВАНИЯ НУЖНОГО БИЗНЕС-ПРОЦЕССА НАЗЫВАЕТСЯ «ОРКЕСТРОВКОЙ».

Взаимосвязь сервисов с деятельностью может быть представлена через моделирование способностей компании.

 

Факторы успеха применения сервисного подхода.

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

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

Перечислим, описанные в литературе,  критические факторы успеха внедрения сервисного подхода:

  1.  Модель зрелости, ориентированная на сервисы (Services Oriented Maturity);
  2.  Хореография сервисов (Choreography of Services). Как проектировать и создавать сервисы таким образом, чтобы с выгодой использовать их во вновь создаваемых бизнес-процессах и сложных сервисах.
  3. Уровень качества сервисов (Quality of Services);
  4. Грануляция сервисов (Granularity of Services).

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

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

3.5.               Методы проектирования и выделения сервисов.

3.5.

Сервисный подход сопровождается рядом методологий и стандартов по проектированию и моделированию сервис-ориентированных архитектур, а именно: стандарты OASIS, методологии IAF, SOMF, IBM SOMA. Краткий обзор представлен ниже:

Integrated Architecture Framework (IAF)

В методологии Integrated Architecture Framework (IAF) (см.: Wout J., Waage M., Hartman H., Stahlecker M., Hofman A. The Integrated Architecture Framework Explained. – Springer, 2010. – 245 c.)  предлагается проектировать SoEA «снизу-вверх», начиная с:

– идентификация сервисов (без структуризации),

– определение критериев группировки на базе архитектурных принципов,

– группировка сервисов и создание «компонентов» (то есть, сервисы сбиваются в компоненты).

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

The service-oriented modeling framework (SOMF) содержит:

- шесть дисциплин (например, «Сервис-ориентированная бизнес-интеграция»);

- нотацию, которая позволяет создавать артефакты и диаграммы. Выделяют 8 диаграмм в трех областях (область анализа, область проектирования, область архитектуры),

- шаблоны и стили моделирования.

SOMA (service-oriented modeling and architecture).

SOMA разработана и внедряется в рамках деятельности IBM Global Business Service и основана на выделении активностей и процессов. SOMA — это методология, позволяющая внедрить SOA в организации и имеющая фазы анализа, проектирования, разработки и внедрения. Для каждой фазы определены роли, технологии, задачи, правила, входы и выходы (результаты).

OASIS Service Oriented Architecture Reference Model (OASIS SOA RAF)

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

КЛАССИФИКАЦИЯ СЕРВИСОВ.  

 

Сервисы могут быть классифицированы по разным основаниям:

  1.  Основные типы (относится как к бизнес-, так и к техническим сервисам): Функциональные, Ценностные, Информационные.
  2.  Относительно предприятия: Внешние, Внутренние.
  3. Относительно владельца: Частные, Общие.
  4. Относительно ролей: Поставщик, Провайдер, Владелец, Исполнитель, Посредник.
  5. Относительно типа: Автоматизированные, Не автоматизированные, Многофункциональные.

Соглашение о качестве сервиса (Service Layer Agreement (SLA)).

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

Потенциальные преимущества SOEA

1)    Оптимизация затрат за счет повторного использования и снижения дублирования (Бизнес и ИТ).

1)

2)   Дополнительные возможности специализации (фокус на основных компетенциях) (Бизнес и ИТ).

2)

3)   Гибкость (Бизнес и ИТ).

3)

4)   Дополнительные возможности взаимодействия и интеграции (новые бизнес-модели) (Бизнес).

4)

5)   Четкое управление ценностью (Бизнес).

5)

Таким образом: важно выделять подходы к сервисам на уровне ИТ и комплексное SOEA, которое включает в себя взгляд на бизнес и через призму сервисного подхода, — выделение бизнес-сервисов.

 

СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ.

 

[1] Данилин А., Слюсаренко А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия.     М. Интернет Ун-т Информ. Технологий, 2005. – 504 с.

 

[2] Калянов Г. Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе. Учебник для вузов. 2-е изд., доп. – Горячая линия-Телеком М., 2014. –  210 с. 

[3] Кудрявцев Д.В., Арзуманян М.Ю.,  Григорьев Л.Ю. Технологии бизнес-инжиниринга.  Учебное  пособие / под редакцией Д.В. Кудрявцева. — СПб.:  Изд-во Политехн. ун-та, 2014.

 

[4] Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: РИА «Стандарты и качество», 2004 – 408 с. (Серия «Практический менеджмент»).

 

[5] Трутнев Д.Р.  Архитектуры информационных систем. Основы проектирования: Учебное пособие. – СПб.: НИУ ИТМО (Санкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики), 2012. – 66 с.