Батоврин Виктор Константинович,

зав. кафедрой ИС МИРЭА, ведущий консультант Фонда ФОСТАС, Москва

e-mail:batovrin@mirea.ru

Зиндер Евгений Захарович,

президент Фонда ФОСТАС, директор аналитического бюро "Группа-24", Москва

e-mail:ezinder@fostas.ru

Аннотация

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

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

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

Введение

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

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

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

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

"Тихая революция" архитектуры предприятия: мировые итоги и тенденции

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

1.      АП используется не только в больших, но и малых организациях (от 100 до 1000 работающих) и на предприятиях всех отраслей, причем программы e-Government стимулируют развитие АП в частном секторе и наоборот.

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

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

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

5.      Все больше организаций определяют свою собственную общую, "рамочную" (framework) схему АП вместо использования или простой адаптации существующих схем.

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

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

8.      OMG MDA и UML широко используются для моделирования ИС.

Что касается п. 4 этих выводов, надо заметить, что в США (где использование АП наиболее распространилось) уже имеет некоторую историю углубленное преподавание АП, включая изучение сложных многомерных общих схем АП. Это важно отметить в связи с п. 5 выводов по следующей причине.

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

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

АП в России: положение и сценарий развития

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

­       около 8% организаций, охваченных исследованием в области АП, имели нахождение в России, где отмечается начало и рост применения АП;

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

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

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

1. сложность создаваемых систем (как управленческих, так и ИТ) и проблемы преодоления этой сложности, заставят высшее руководство коммерческих компаний и органов государственной власти (как "в центре", так и "на местах") искать адекватные средства управления, в числе которых АП окажется неизбежно;
2. проблемы управления предприятиями, включая предоставление услуг внешним заказчикам и внутренним подразделениям, будут решаться с учетом передового мирового опыта (lessons learned), полученного в сфере АП и ССП.
3. понизится острота организационных проблем, которые возникают в коллективах при введении на предприятиях "архитектурных" должностных позиций и подразделений,
4. университеты-лидеры незамедлительно начнут включать в учебные планы дисциплины, связанные с АП и ССП и разрабатывать соответствующие полноценные учебно-методические комплексы, причем не только для ИТ-специальностей, но и для экономических и управленческих специальностей (похоже, что этот процесс уже начался силами кафедр и УМО нескольких известных авторам университетов);
5. не только на позиции архитекторов АП и CIO, но и на позиции директоров по развитию в организациях начнут приходить люди, имеющие достаточное образование в данной сфере (в том числе, полученное в режиме дополнительного образования и тренингов), а также имеющие индивидуальные способности к специфической архитектурной работе в данной области.

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

Факторы сложности АП - многомерность общих архитектурных схем АП

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

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

Измерения архитектурной схемы, которые включаются в различные рамочные схемы, составляют следующий, не являющийся исчерпывающим список архитектурных "осей":

1.      ось "архитектурных аспектов" предприятия или системы (соответствует столбцам матрицы Захмана),

2.      ось "представлений" предприятия или системы (соответствует строкам матрицы Захмана),

3.      ось времени развития архитектуры предприятия или системы (стадия проектного цикла, стадия ЖЦ системы, витки развития предприятия и этапы этих витков),

4.      ось обобщения/конкретизации архитектурных блоков и элементов,

5.      ось агрегации/детализации архитектурных блоков и элементов,

6.      ось прикладного сегментирования схемы (как, например, в сегментном подходе FEAF).

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

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

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