Что ждет идущих по пути построения SOA?

Нельзя внедрить, но можно строить

При выборе пути развития прикладной архитектуры нет никакого смысла обсуждать, является ли SOA новой технологией или комбинацией существующих и отработанных, стоит быть первопроходцем или лучше подождать, пока другие набьют шишки, соответствует ли система X стандарту Y или нет? Имеет смысл только понять потребности бизнеса компании и оценить свою способность удовлетворить их традиционным или "новаторским" методом. Собственно, отсюда и вытекают два основных вопроса в контексте обсуждаемой темы.

1. Нужна ли нам SOA?
2. Если да, можем ли мы внедрить SOA?

Очевидно, первый вопрос — ключевой. Забегая вперед, отвечу на второй вопрос: "Внедрить SOA нельзя, SOA можно строить". Почему, посмотрим ниже.

Итак, нужна ли нам SOA? Рассмотрим несколько примеров.

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

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

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

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

Пример 4. Вот уже три примера, обосновывающих SOA, рассмотрены, однако все они носят частный характер. Самым значимым, на мой взгляд, преимуществом, которое дает SOA, является гибкость, возможность ускорения разработки и, как следствие, высокая скорость реакции на изменение рыночных условий. В самом деле, если бизнес-процессы декомпозируются на отдельные работы, которые в свою очередь соответствуют сервисам в терминах SOA, появляется возможность сборки новых бизнес-процессов из готовых кубиков. Мне посчастливилось быть свидетелем создания принципиально новой услуги кредитования с абсолютно новым, разработанным с чистого листа бизнес-процессом на базе существующих сервисов. Весь цикл от проработки бизнес-требований и согласования ТЗ до начала пилотной эксплуатации занял не более трех месяцев в банке с индустриальными системами и централизованной архитектурой, обслуживающей несколько тысяч точек продаж и несколько миллионов клиентов. Выполнение данного проекта в классической архитектуре заняло бы примерно в два раза больше времени и стоило бы примерно в два раза дороже. В этом же примере имеет смысл коснуться темы сопровождения информационного комплекса, построенного на принципах SOA. С одной стороны, появляется как минимум один дополнительный критичный для бизнеса (mission critical) компонент, Enterprize Service Bus. А с другой стороны, унифицируются и централизуются все средства интеграции, количество которых в противном случае могло бы исчисляться десятками. Это позволяет упростить и сделать более эффективными администрирование и мониторинг доступности систем.

В России есть примеры компаний, объявивших о построении SOA или использующих принципы SOA. Например, в прессе можно найти упоминания о таких банках, как "Альфа-Банк", Unicredit, "Русьфинанс", "Ренессанс Кредит", "КМБ Банк", "Ренессанс Капитал" и другие. Следует отметить, что все перечисленные банки, кроме "Ренессанс Капитала", используют ПО от IBM. "Ренессанс Капитал" использует ПО от TIBCO Software. Безусловно, список вендоров не ограничивается двумя этими компаниями. Мне неизвестны примеры использования для построения SOA Open Source проектов, хотя теоретически это возможно и существует соответствующее Open Source middleware. В большинстве случаев работы по интеграции приложений и созданию сервисов проводились и проводятся силами внешних подрядчиков, специализирующихся в этой области. Это весьма существенный момент, так как если подрядчик берется за весь цикл работ, включая разработку ТЗ, он должен обладать хорошей экспертизой в предметной области вместе с чисто разработческой экспертизой. В самом деле, если SOA помогает выстраивать управление бизнес-процессами, становится критически важным понимать предметную область, ведь автоматизация в таких условиях выходит за рамки традиционных функциональных подразделений и ограниченных зон автоматизации. Нужно видеть весь бизнес-процесс от входа до выхода. Для эффективной работы нужна специализация интегратора на определенных видах бизнеса. Например, уже существуют успешные компании, специализирующиеся на интеграции банковских приложений. Для универсальных софтверных компаний, занимающихся заказными разработками, такой подход может оказаться новым и неподъемным.

Рифы в океане SOA…

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

Далее, по мере подключения новых систем естественным образом встает задача обеспечения непротиворечивых справочных данных, например единого справочника клиентов. Строго говоря, не SOA сама по себе, а использование разных прикладных систем диктует необходимость объединения справочников. Просто SOA облегчает и ускоряет появление новых систем и приводит к сложности управления данными в масштабах всего комплекса. Например, для управления кредитами используется одна система, а для управления депозитами — другая, но при этом клиент может иметь и кредит, и депозит. В какой системе данные о клиенте будут более актуальными? Вероятно, в той, куда данные введены позже. Но что тогда делать с данными в первой системе, обновлять? Одним из подходов к решению подобных проблем является внедрение систем класса master data management. Такие системы есть практически у каждого крупного вендора (например, Oracle, IBM). А это увеличивает стоимость владения всем информационным комплексом, и к тому же в сложной архитектуре внедрение такой системы — весьма нетривиальная задача. Еще раз подчеркну, что не SOA сама по себе вызывает необходимость централизованного управления данными, а критическое количество систем, нуждающихся в единых данных. Просто SOA быстрее приводит к "критической массе".

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

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

Все это приводит к радикальному усложнению поиска проблем, требует наличия соответствующей квалификации. И, естественно, требует постановки процесса управления проблемами в соответствии с ITIL.

…и пути их обхода

Перечисленные проблемы могут показаться надуманными, но это до тех пор, пока не столкнешься с ними по мере усложнения архитектуры. Можно ли избежать их или по крайней мере сделать более управляемыми? Безусловно, можно. И секрет выглядит просто — для этого необходима индустриализация разработки и эксплуатации. Под индустриализацией следует понимать использование так называемых "лучших практик" (best practices) и стандартизованных процессных моделей разработки (frameworks). В области эксплуатации это в первую очередь процессы управления изменениями, проблемами, мощностями. При этом предполагается, что без поставленного управления инцидентами к построению SOA вообще лучше не приступать. Критически важным становится внедрение системы мониторинга ключевых параметров ESB, например ресурсов, размеров очередей и т.д. С точки зрения эксплуатации SOA не является чем-то особенным. В некоторых случаях эксплуатационные вопросы, например мониторинг доступности, могут упроститься за счет наличия ЕДИНОЙ интеграционной платформы. Правда, при этом требуются квалифицированные системные администраторы. Из-за отсутствия ярко выраженной специфики эксплуатации далее будем рассматривать только развитие. В области разработки (развития) становятся критически важными управление требованиями, архитектурный анализ, управление релизами.

Итак, управление требованиями. Мы говорили выше, что SOA приводит к сквозной автоматизации бизнес-процессов, в которых используются сразу несколько систем. Естественным образом это приводит к "отвязыванию" мышления от конкретной системы, в пользу мышления в терминах всего бизнес-процесса. Поскольку одни и те же сервисы будут использоваться в разных бизнес-процессах, крайне важно формулировать непротиворечивые требования к сервисам. Это краеугольный камень, без которого возможность повторного использования сервисов, а следовательно, и все основные преимущества SOA, становятся нереальными. Вроде ничего сложного здесь нет — любая задача начинается с формулирования бизнес-требований, трансформации их в системные требования и передачи их в разработку. Сложным окажется обеспечение 100%-ной воспроизводимости этих шагов по ходу развития прикладной архитектуры компании, бизнес которой не связан с разработкой программного обеспечения. Чтобы этого добиться, нужно выстроить процесс, управляющий этим развитием. В таком процессе могут быть задейст­вованы разные компании-разработчики, собственные разработчики. Для обеспечения единства и воспроизводимости процесса потребуется специализированная workflow-система (например, JIRA) и четкая организация процессов разработки, которые данная система призвана поддерживать. Важно понимать, что в основе процесса лежит управление требованиями, с него все начинается. В свою очередь, для управления требованиями также удобно использовать специализированное ПО, например Doors. Это позволит отслеживать и трассировать все требования, иметь полную картину требований с их историей.

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

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

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

Третье, на что необходимо обратить особое внимание в области разработки, — это передача функциональных изменений на вход процесса управления изменениями. В самом деле, при автоматизации нового бизнес-процесса или продукта могут оказаться задействованы несколько систем, в каждой из которых и, естественно, в самой ESB выполнены определенные изменения. При этом смысл эти изменения имеют, только если делаются совместно и одновременно, такова специфика интегрированной архитектуры. Понятно, что каждое изменение несет определенный риск, а в случае пакета одновременных изменений риск значительно увеличивается. Для управления этим риском необходимо выстраивать процесс управления релизами с сопутствующими процессами тестирования. Смысл управления релизами состоит в трансляции набора функциональных (и не только) изменений, соответствующих конкретным прикладным задачам, в запросы на осуществление физических изменений (request for change). Например, в релизе может быть 20 прикладных задач с понятным бизнес-значением, которые соответствуют на физическом уровне запуску нескольких скриптов на базе данных, замене jar-файла (архив файлов с исходным java-кодом — прим. ред.) и выполнению настройки количества потоков при работе с БД. Главная функция процесса — устанавливать эти зависимости. Соответственно для этого определяется и контролируется состав прикладных задач в релизе (что особенно важно при выполнении согласованных изменений), порядок отката изменений, возможность частичного отката, план работ по выполнению изменений и т.д. В процессе подготовки релиза он должен пройти функциональное тестирование, регрессионное и нагрузочное. Речь в данном случае идет только об интеграционном тестировании, то есть тестовая среда должна быть архитектурно полностью аналогична продук­тивной.

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

Все сказанное о разработке специалистам по разработке программного обеспечения может показаться очевидным. Однако напомню, что речь шла об управлении развитием прикладной архитектуры компании, бизнес которой не связан с разработкой программного обеспечения. Поэтому нет никакого смысла описывать весь процесс разработки, для этого созданы известные frameworks. Акцент был сделан только на особенно важных областях, без которых развитие SOA-архитектуры, особенно в условиях множества поставщиков и интеграторов, может не принести ожидаемого эффекта. Напомню, в основе лежат управление требованиями и архитектурный анализ. Без них не начинает работать служба разработки, поставляющая изменения, которые проверяются и объединяются в релизы и передаются в стандартный процесс управления изменениями. Собственно, в этом резюме прослеживается связь между SOA, как архитектурным подходом к автоматизации бизнес-процессов и процессной моделью IT-службы.

Настало время ответить на вопрос: можно ли внедрить SOA? Ответ: нет, строить можно, внедрить нельзя. SOA — это архитектурный стиль, в котором развивается прикладная архитектура компании. SOA — это путь развития. Путь, который подсказывают жизнь и… конкуренция.

Об авторе:

Ярослав Медокс, независимый эксперт.