За кулисами интеграции

Виктор Галактионов, главный системный архитектор, директор департамента управления архитектурой АКБ «РосЕвроБанк», — о проблемах интеграции

Вопросами интеграции Виктор Галактионов, главный системный архитектор, директор департамента управления архитектурой АКБ «РосЕвроБанк», занимается уже почти десять лет. С его точки зрения, за это время тема интеграции данных постепенно переросла в две другие темы — интеграции приложений и построения сервис-ориентированной архитектуры. Впрочем, чтобы сделать бизнес по-настоящему эффективным, качественной бесшовной стыковки информационных систем недостаточно. Нужна интеграция на более высоком уровне — уровне бизнес-процессов, поскольку именно они стоят за приложениями и данными. В нашей беседе Галактионов рассказывает о том, как на практике выглядит интеграция, и делится секретами решения многих других тонких вопросов в этой области.

Каковы место и роль интеграционных решений в ИТ-архитектуре?

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

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

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

Отражаются ли архитектурные или иные особенности интеграционных решений на архитектуре предприятия в целом?

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

На какой стадии проектирования или развития ИТ-архитектуры требуется продумывать встраивание интеграционного слоя? Насколько радикально при этом меняется ИТ-архитектура?

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

При проектировании архитектуры и интеграционных решений важными являются требования к срокам обработки и объемам информации с учетом динамики роста этих объемов. Использование для оперативного решения этих задач сложных моделей (математических, имитационных) в современных условиях ведения бизнеса не всегда и не везде оправданно, поэтому часто прибегают к эксперт­ным оценкам, которые, однако, не всегда дают точные прогнозы. Например, при реализации требований статьи 9 закона 161-ФЗ «О национальной платежной системе» в части рассылки уведомлений клиентам о совершенных ими платежах сложно предусмотреть на ранних этапах объемы ошибок доставки почтовых сообщений с уведомлениями. Нужно быть готовым к тому, что при реализации требований, на одном из заключительных этапов проекта, сразу после начала пробной рассылки уведомлений по электронной почте, объем этих сообщений окажется настолько большим, что в связи с этим потребуется реализация новых, непредусмотренных изначально бизнес-процедур — в результате придется перепроектировать архитектурное решение, чтобы предусмотреть интеграцию с другими системами, не планируемыми к использованию изначально. Таким образом, в начале проектирования интеграционной архитектуры, на самых ранних его этапах, к сожалению, никогда нельзя гарантировать, что даже на заключительных этапах не придется подвергать серьезной ревизии ранее принятое архитектурное решение.

Виктор Галактионов, главный системный архитектор, директор департамента управления архитектурой АКБ «РосЕвроБанк»

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

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

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

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

Какие факторы наиболее сильно способствуют росту затрат на интеграцию?

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

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

Какую ошибку интеграционных проектов вы считаете самой серьезной?

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

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

За время, что занимаюсь интеграцией, я пришел к заключению, что возврат к ранее разработанному сервису с целью его доработки также следует рассматривать как ошибку. Интеграционные архитекторы должны работать подобно снайперам: пусть долго, но тщательно готовиться, чтобы потом решить задачу с одного захода. Я горжусь архитекторами, которые в течение трех месяцев провели анализ бизнес-процессов, восстановили структуры данных и сформировали функциональные спецификации, а затем в течение пяти дней выполнили разработку и внедрение интеграционного решения, которое за четыре года, прошедших с тех пор, ни разу не изменялось и не исправлялось — такова была степень его изначальной проработки!

Как считаете, кто в ИТ-службе должен отвечать за вопросы интеграции? Должен ли этот ответственный находиться в подчинении ИТ-архитектора?

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

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

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

Какими должны быть роли ИТ-архитектора и ИТ-руководителя в решении вопросов интеграции?

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

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

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

Замечу, что направления и ИТ-архитектуры, и интеграции реализуют отдельные ИТ-процессы. Они являются частью ИТ-стратегии и, соответственно, подот­четны CIO.