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

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

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

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

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

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

Управление SOA: стратегическое и тактическое

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

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

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

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

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

В заключение обсуждения этого вопроса приведём пример. Некая вымышленная компания связи FastCom хочет объединиться с другой вымышленной компанией связи, скажем, SpeedyCable. Это объединение необходимо компаниям для того, чтобы выпустить на рынок новый продукт. Соответственно, требуется осуществить интеграцию по типу «бизнес-бизнес» (B2B). Комитеты по стратегическому управлению в обеих компаниях имеют свои разработанные идеальные корпоративные политики и SOA-архитектуры. На собрании, посвященном началу процесса интеграции, каждая из этих двух компаний представляет свои «стратегические SOA-политики». Существует большая вероятность того, что возможности и политики компаний не совпадают и не могут быть объединены.

Что же происходит дальше? Архитекторы уходят, а ответственные руководители предметных областей остаются, чтобы обсудить имеющиеся с двух сторон политики и выработать «тактический» план интеграции. И вот обе команды разработчиков и менеджеры по проекту начинают еженедельно собираться. Они пересматривают и анализируют требования к политикам безопасности, схемы, стандарты, требования к преобразованию данных и целый ряд других требований, имеющих отношение к интеграции. Логично, что если комитет по стратегическому управлению определил, какой была политика и в чем это проявляется, комитет по тактическому управлению будет решать, какие политики применить и где политика применима.

В этом и заключается разница между «стратегическим» и «тактическим» управлением: они рассматривают корпоративную SOA-политику под разным углом зрения.

Шесть столпов SOA

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

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

Вот шесть механизмов, с помощью которых поддерживается SOA-политика:

1. Операционная модель жизненного цикла SOA
2. Организация SOA
3. SOA-процесс
4. Портфель активов для сервисной интеграции в SOA
5. Инструментарий SOA
6. SOA-технологии
Эти механизмы используются обоими подходами к разработке и управлению SOA. Первый подход – это управление SOA по типу «сверху вниз». Он подразумевает, что управление по своей сути является стратегическим и начинается с модели и определённых проектов. Продвигаясь вниз, «стратегическое управление» определяет людей, процессы, сервисы, инструменты и технологии, которые будут привлекаться для поддержки корпоративного SOA-проекта. Второй подход – «снизу вверх» - соответственно подразумевает «тактическое управление», которое, наоборот, строит SOA-проект на основе создаваемых технологий, инструментов и сервисов. Большинство предприятий идет по пути «снизу в верх», начиная с конкретных сервис-ориентированных шагов, направленных на определённые предметные области. Очень редко встречаются организации, в которых создание стратегии первично по отношению к созданию необходимых отделов и бизнес-подразделений, первоначальных SOA-технологий и инструментария. Такой подход в целом только усложняет процесс налаживания управления SOA. Именно по этой причине мы считаем целесообразным начать с обсуждения подхода «сверху вниз». Для начала определимся с моделью жизненного цикла управления SOA.

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

1. Управление портфелем активов SOA
2. Планирование SOA
3. Разработка сервисов
4. Разработка клиентской части системы
5. Конфигурация интеграционного процесса
6. Поддержка SOA-платформы, сервисов и построения процесса интеграции
7. Реализация и маркетинг SOA
8. Составление отчетов и SOA-аналитика
9. Управление SOA

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

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

Четвертый механизм, поддерживающий построение SOA – «Портфель активов для сервисной интеграции». Он определяет те сервисы, которые предприятие развернуло, спланировало и задумало как «предлагаемый продукт». С помощью этого механизма корпоративные сервисы соотносятся с корпоративными функциями: таким образом, сервис становится элементом, представляющим «единицу работы», выполняемой бизнесом. Управление этим механизмом позволяет определить, кто будет заниматься созданием и поддержкой сервисов, а также когда эти сервисы будут опубликованы и начнут обслуживать предприятие. На этом же уровне определяется политика разработки сервисов, а именно – когда и на каких основаниях должны создаваться сервисы. Зачастую об этом забывают и занимаются этим в последнюю очередь. Именно здесь находится точка пересечения подходов «сверху вниз» и «снизу вверх», если они оба осуществляются на одном предприятии.

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

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

Следующие шаги на пути к управлению

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

1. Каковы органы «стратегического управления» в вашей организации? Несут ли они ответственность за принятия решений в области управления SOA на данный момент?
2. Какие группы осуществляют «тактическое управление» на предприятии? Кто руководитель SOA-проектов, кто отвечает за всю деятельность, связанную с SOA-программами и SOA-проектами? Кто создал сервисы и сконфигурировал процессы интеграции на вашем предприятии? Задокументированы ли технологические стандарты или процессы?
3. Составлялась ли SOA-модель для вашего предприятия? Кто этим занимался? Если да, то где ее можно увидеть и где можно взять и изучить информацию по ней?
4. Какие функции поддерживаются вашим предприятием на данный момент? Задокументированы ли они? Кто занимался их документированием? Кто отвечает за распределение функций, за то, какие функции какими отделами или командами будут выполняться?
5. Задокументированы ли SOA-процессы, реализуемые на вашем предприятии, которые направлены на построение модели? Кто этим занимался? Какой процесс отвечает за создание сервиса, проектирование сервиса, развертывание сервиса, регистрирование сервиса, конфигурирование интеграции, получение поддержки технического сопровождения или осуществление запроса на исключение политики?
6. Задокументированы ли те сервисы, которые ваше предприятие уже сделало доступными? Кто этим занимался? Согласованы ли эти сервисы с бизнес-сферами, программными продуктами и функциями. Кто занимался этим вопросом? Опубликован ли план предложений сервиса? Есть ли в плане какие-то недоработки? Кто занимался этими вопросами?
7. Согласован ли SOA-инструментарий, использующийся на предприятии, с базовой SOA-архитектурой? Кто за этим следит? Какие возможности дает вам имеющийся инструментарий? Каких возможностей вам не хватает? Кто отвечает за выбор инструментов?
8. Задокументированы ли технологические стандарты и предпочтения? Кто этим занимался? Какой путь к исключению для запроса технологического исключения? Что произойдет, если вы нарушите корпоративную SOA-политику на уровне SOA-технологий? Что произойдет, если вы будете следовать технологическим стандартам?

Заключение

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

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

По материалам сайта InfoQ

Комментарии