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

Что делается в этой области в развитых странах, которым принадлежит инициатива в области внедрения SOA?

Например, на федеральном уровне Административно-бюджетное управление США (OMB) прилагает усилия к тому, чтобы указать правительственным организациям стратегию и порядок выстраивания инициатив в области IT, а также способствовать лучшему применению IT-ресурсов, за счет бюджетных рекомендаций и инициатив, таких как Архитектура федерального предприятия (Federal Enterprise Architecture, FEA). Хотя справочные модели FEA созданы в расчете на федеральное правительство, их концепции внедрены во всех основных системах и методологических принципах Архитектуры предприятия (Enterprise Architecture, EA), поэтому приведенные примеры могут также быть применены в организациях, относящихся к частному сектору.
 
Готовность к SOA
 
В отчете Главного контрольного управления (Government Accountability Office, GAO) «Архитектура предприятия: лидерство остается ключом к созданию и применению архитектур для организационной трансформации» (GAO-06-831, август 2006 г.) сделан следующий вывод:
 
«Правильно определенная архитектура предприятия представляет собой важнейший инструмент использования информационных технологий для преобразования бизнеса и решения его рабочих задач. Попытки модернизации и развития IT-среды без архитектуры для направления и ограничения инвестиций приводят к появлению операций и систем,  которые дублируют друг друга, плохо интегрированы, неэффективны в поддержке задач миссии и требуют значительных расходов на обслуживание».
 
Для оценки зрелости EA и, соответственно, готовности SOA, имеются различные модели:
 
•         Структура зрелости управления архитектурой предприятия GAO (Enterprise Architecture Management Maturity Framework, EAMMF)
•        Структура оценки архитектуры предприятия OMB (Enterprise Architecture Assessment Framework, EAAF)
•         Модель зрелости архитектуры предприятия (Enterprise Architecture Maturity Model, EAMM) Национальной ассоциации руководителей информационных служб штата (NASCIO)
•         Самооценка зрелости программы архитектуры предприятия Гартнера (Gartner’s Enterprise Architecture Program Maturity Self-Assessment).
 
Согласно EAAF OMB, чтобы использование  SOA было эффективным, организация должна достичь, по меньшей мере, 3 уровня зрелости EA. Организации 4 уровня располагают «документированным планом развития SOA для различных сегментов бизнеса», и лишь организации 5 уровня «реализовали SOA и извлекают выгоды из ее применения».
 
Стратегия SOA
 
Так сложилось, что, как инициативы по трансформации бизнеса, так и IT-проекты нечасто оказываются успешными. Организации могут повысить свои шансы на успех за счет реализации выстроенного в виде замкнутого контура набора операций для управления формулированием и исполнением стратегии SOA — системы стратегического управления. К основным артефактам стратегического управления относятся (1) стратегия, (2) план исполнения, (3) учет SOA в отборе инвестиций и принятии решений, связанных с выделением бюджетных средств, и (4) периодическая отчетность в целях измерения, оценки и корректировки эффективности инициатив SOA.
 
С начала 90-х годов ХХ века, Роберт Каплан и Дэйвид Нортон выдвинули идею использования карт стратегии и карт сбалансированных показателей для улучшения формулирования и исполнения стратегии на всех уровнях организации. Справочная модель показателей эффективности FEA (Performance Reference Model, PRM), отчасти основанная на указанной работе, описывает концепцию "визирования" для связывания решений, относящихся к ресурсам («входа») с готовыми возможностями инициативы («выходами») и результатами («исходами»). Карты стратегии являются одним из способов создания общего вида стратегии организации, предваряющего определение и управление целями, а также измерение показателей эффективности. Общими составляющими карты стратегии являются:
 
•         Горизонт планирования: заявленный период планирования.
•         Декларирование миссии: декларирование на высоком уровне цели инициативы SOA.
•         Декларирование видения: описание на высоком уровне места, к которому инициатива SOA должна прийти к окончанию периода планирования.
•         Перспективы: немногочисленный набор категорий (как правило, от четырех до шести), позволяющий планировщикам понять вопросы, определяющие исходы. В своем первоначальном варианте, карта стратегии Каплана и Нортона идентифицировала четыре перспективы: (1) финансы; (2) клиент; (3) внутренний бизнес-процесс; и (4) обучение и рост. В PRM FEA идентифицированы шесть перспектив: (1) миссия и результаты бизнеса; (2) результаты клиента; (3) процессы и действия; (4) люди; (5) технологии; и (6) прочие основные активы.
•         Цели/Задачи: немногочисленный набор исходов бизнеса, за которые инициатива SOA несет основную ответственность.
 
Инициатива SOA должна предусматривать разработку такой карты стратегии, которая помогла бы сфокусировать и настроить инициативу в соответствии с потребностями организации.
 
Планирование и отчетность исполнения SOA
 
План показателей эффективности представляет собой документ, сопутствующий стратегическому плану и определяющий ежегодно планируемые показатели эффективности, использование ресурсов и фактические индикаторы работы организации. Такой план не должен быть слишком пространным – достаточно одной страницы. Слишком часто имеют место технологические инициативы, предпринимаемые без предварительного определения достоверного базового уровня среды, подлежащей оптимизации. В отсутствие такого достоверного базового уровня, развитие и ценность инициатив окажутся затруднительными.
 
На основании действий по созданию карты стратегии, инициатива SOA должна:
 
•         определить, каким образом запланированные показатели эффективности соотносятся с общими целями и задачами на карте стратегии
•         установить индикаторы эффективности, которые будут использоваться при измерении или оценке соответствующих выходов, уровней сервиса и исходов для каждого вида деятельности, обозначенного в программе
•         обеспечить основу для сравнения фактических результатов программы с установленными целями показателей эффективности
•         описать средства, которые должны применяться для проверки и подтверждения измеренных значений
 
Для каждой перспективы должны быть определены индикаторы эффективности, действия и инициативы проекта. Не существует волшебного списка «правильных» индикаторов эффективности. Вам следует выбрать те индикаторы, которые имеют значение для вашей организации и инициативы, и которые оказываются полезными при оценке развития и ранней идентификации решаемых вопросов.
 
Приведем небольшой пример. В карте стратегии, в качестве одной из заявленных задач бизнеса является экономия расходов на информационные технологии. В плане показателей эффективности, соответствующим индикатором эффективности являются «тенденции в стоимости разработки или обслуживания IT». В этом примере не определены планируемые показатели эффективности, но в настоящем плане показателей эффективности они должны быть указаны. Чтобы быть полезными для отчетности о развитии и принятия решений, индикаторы эффективности должны регистрироваться в отчетах ежеквартально или хотя бы 2 раза в год. В тех случаях, когда определение исходных показателей эффективности представляется затруднительным, установление такого базового уровня должно стать одной из задач, поставленных перед начальной пробной версией SOA.
 
Если в вашей организации уже применяются карты стратегии и планы показателей эффективности, применение указанных приемов для установления инициативы SOA должно облегчить обсуждение вопросов координации [по линии «бизнес - IT»] и  обеспечение участия в программе. Если в вашей организации не применяются вышеупомянутые методы, они все равно представляют собой оперативные средства, предназначенные для ознакомления с инициативой SOA, ее целью и ценностью.
 
Определение возможностей SOA
 
В большинстве организации не имеет смысла придерживаться в отношении SOA принципа «выжженной земли», когда установка приложений SOA означает полный отказ от всех (даже вполне действенных) остальных приложений. Кроме того, сама технология SOA все еще находится в стадии развития и требует определенных навыков, которых часто не хватает. Поэтому едва ли целесообразно пытаться с самого начала установить какую-либо крупномасштабную программу. Это значит, что следует, опираясь на здравый смысл, выбрать управляемый проект с  поддающейся количественной оценке коммерческой ценностью, который, в случае его успешной реализации, может оказать поддержку и финансовое обеспечение дальнейшего устойчивого роста. Мы можем подойти к идентификации такого проекта в три этапа:
 
•         Идентификация функциональных зон, подлежащих выделению расходов на новые разработки
•         Изучение указанных зон в целях определения наиболее подходящих сервисов
•         Вовлечение заинтересованных сторон в определение приоритетов и поддержку разработки сервисов.
 
Большинство методов EA предполагают некоторое упоминание о функциональной идентификации и категоризации. Для федеральных ведомств Справочная модель описания бизнеса FEA (Business Reference Model, BRM) создает начальный пункт для определения характеристик IT-активов и инвестиций с функциональной точки зрения. В своей основе BRM представляет собой трехъярусную иерархию функций, заданных для определения характеристик деятельности по управлению, при одновременной идентификации возможностей в целях минимизации чрезмерных усилий. Верхний ярус состоит из четырех бизнес-зон; второй ярус отражает более 30 направлений бизнеса (LoB); наконец, третий ярус представляет свыше 160 подфункций. Отличительная особенность BRM FEA заключается в том, что она позволяет отделам и управлениям понять распределение их IT-активов по функции, не зависящей от их организационной структуры. С помощью концепций BRM, организации могут отделить бизнес-зоны значительных новых инвестиций от бизнес-зон номинальных инвестиций и инвестиций в обслуживание.
 
Сама по себе, всякая функциональная иерархия едва ли интересна и относительно бесполезна. Но применительно к процессам выбора инвестиций и планирования бюджета, она может стать источником глубокого понимания предпочтений и склонностей организации в том, что касается распределения ресурсов. Большинство исполнительных федеральных ведомств ежегодно представляют в OMB таблицы в формате MS-Excel, содержащие детализированный перечень их инвестиций в IT и информацию о соответствующем бюджете IT. При этом, отчет содержит сравнительно небольшое число характеристик, среди которых:
 
•         Уникальный ID-номер проекта (уникальный идентификатор каждой IT-инвестиции)
•         Название инвестиции
•         Описание инвестиции (краткое изложение в объеме не более 255 символов)
•         Тип инвестиции (основная, не основная, доля перемещения IT, вклад партнеров)
•         Картирование инвестиции для первичной BRM FEA (функциональная категория)
•         Ежегодные инвестиции в долларах для 3-годичного «скользящего окна» с идентификацией общей суммы и разбивкой расходов на Расходы на поддержание устойчивого состояния (Steady State, SS) и Расходы на развитие, модернизацию и расширение (Development, Modernization, and Enhancement, DME).
 
OMB объединяет и публикует эти данные на сайте www.whitehouse.gov/omb/budget. Для бюджетного отчета за 2008 финансовый год (FY2008), соответствующая ведомость значится под заголовком «Вспомогательные документы» (“Supporting Documents”) и озаглавлена «Отчет о расходах на информационные технологии (IT) для федерального правительства (“Report on Information Technology (IT) Spending for the Federal Government”).  Положительным для федеральных отделов является то, что они могут использовать ежегодно обновляемую ими информацию для того, чтобы попытаться определить потенциальные возможности SOA. Что касается предприятий частного сектора, они могут получить отраслевые функциональные иерархии из различных источников либо создать их самостоятельно. Фактически, организации, относящиеся к государственному и частному секторам, могут применять анализ одного и того же вида. 
 
Извлечение выводов и призыв к действию
 
Ранее разработанные примеры используют концепции картирования стратегии, планирования эффективности и архитектурно-ориентированного анализа бизнеса для того, чтобы (1) определить программу SOA, соответствующую потребностям организации, и (2) идентифицировать естественные возможности дальнейшего развития сервисов SOA. В зависимости от зрелости EA вашей организации, такие артефакты могут служить в качестве данных, на основании которых можно будет инициировать обсуждение SOA и учредить орган, занимающийся руководством SOA (или EA). Организации с высоким уровнем зрелости EA могут обращаться к ним как к постоянно используемым артефактам для облегчения определения приоритетов SOA и оценки инвестиций.
 
Придется нарушить сложившиеся организационные схемы. В таких ситуациях, лучше всего быть как можно более объективным и беспристрастным. Покажите, куда бизнес распределяет свои IT-ресурсы, и предоставьте возможности размещать эти ресурсы более эффективно. Будьте готовы идти до конца и продемонстрировать, что SOA можно доверять.
 
Ниже приведены некоторые ключевые вопросы, которые обязательно следует учитывать:
 
•         Наибольшую трудность для успешной реализации SOA представляют управление и процесс, а не технология. Сосредоточьтесь на продвижении понимания SOA, обеспечения контактов и участия.
•         Используйте планирование, EA и портфельные дисциплины для (1) идентификации возможностей создания сервисов; (2) составления описи ресурсов; (3) выполнения функционального анализа; (4) формулирования планов перехода и экономических аргументов; и (5) обеспечения взаимодействия SOA с EA, инвестиционными и прочими управляющими органами.
•         Запустите программу или Офис управления проектом (Project Management Office, PMO) для управления начальными (пробными) технологическими версиями SOA и управления изменениями, Управление взаимоотношений с клиентами (Customer Relationship Management, CRM), Соглашения об уровне сервиса (Service-Level Agreements, SLA) и управления убытками.
•         Сотрудничайте с поставщиками SOA-технологий для достижения решений, соответствующих потребностям и ограничениям конкретного бизнеса.
•         Используйте карточки показателей и информационные панели для демонстрации результатов и ценности, а также для определения дополнительных возможностей дальнейшего улучшения.
 
В этой статье, коммерческие перспективы получили более выраженный акцент, по сравнению с техническими аргументами. Хотя последние крайне важны, именно деловая составляющая имеет критическое значение для вовлечения лиц, отвечающих за принятие решений, в обсуждение и поддержку того, что, в основе своей, составляют совместные сервисы.

При подготовке статьи использовались публикации Остина Расса и Лоры О‘Нил