Сегодня практически все компании внедрили в свою структуру множество систем. Разной архитектуры, на разных платформах, для решения разных задач — но все эти приложения и процессы нужно связать в единую комплексную систему каким-то одним удобным средством. Чтобы для пользователя процесс был цельным, понятным, всё работало слаженно и не требовалось бы двойного ввода данных.
Всё это делает возможным интеграционная шина. Знакомьтесь с особенностями её внедрения на примере кейса финансовой компании «МигКредит».
Развитие потребности
В «МигКредит» об интеграции задумались в 2011 году. Роман Можаев, директор компании по ИТ, рассказывает, что на тот момент в «МигКредит» была всего одна моно-система, одновременно фронт-энд и бэк-энд, и в ней проходило всё обслуживание. Но уже через год появилась необходимость интегрировать эту систему с другой, которая занималась андеррайтингом (с проверкой кредитных досье и т.д.). Стало понятно: нужна интеграционная шина.
Когда компания перешла на полноценный кредитный конвейер, одним из его компонентов стала интеграционная шина на СПО, связавшая в конвейер множество элементов: фронт-энд, CRM, мобильное приложение и сайты. Сайты «МигКредит» — не просто информационный портал, а среда, где клиенты могут получить услуги, — значит, всё должно происходить быстро. Шина и даёт возможность быстрой маршрутизации.
Затем «МигКредит» реализовала возможность для клиентов моментально получать услуги онлайн, а для сотрудников компании — оркестрацию процессов внутри основного бизнеса в сторону digital, не строя заново весь конвейер. Это уже не интеграция данных, а построение процессов, объединяющих систему управления бизнес-процессами, инфраструктурные сервисы, среду разработки, мониторинг, и так далее, — и это тоже делает возможным шина.
Эволюция интеграционных решений
Принято выделять три эпохи в развитии интеграционных систем.
- Интеграция типа «лапша»: все системы тянутся друг к другу, как спагетти, образуя своеобразный клубок. И, как и настоящие спагетти, шина должна сначала «переложить их в кастрюлю», стандартизировать все элементы.
- Централизованные системы: единая CRM, единая база данных.
- Микросервисные архитектуры, распределённая обработка, облака — те темы, что сейчас на слуху.
Выбранные «МигКредит» stack-технологии позволяют не только использовать системы второго поколения, но и организовать микросервисную распределённую обработку, приближаясь к третьей эпохе систем. Как говорит Роман Можаев, компания немножко опережает время.
Раньше возможности виртуализации позволяли просто добавлять виртуальной машине все больше ядер и больше памяти, создавая монструозные единые системы.
Сейчас цифровая трансформация требует разбиения этих единых решений, внедряя вместо этого интеграцию систем. Сегодня необходимо повторно использовать многие куски кода, обеспечить их независимость, возможность создания новых версий, форков этого кода.
Стоит отметить рост подобных запросов именно от бизнеса.
Тренд смещается от ИТ для ИТ, к ИТ для бизнеса.
Основных схем интеграции две: оркестровка и хореография. Оркестровка — это большая централизованная схема, где всем управляет оркестратор. Хореография — схема, где элементы распределённые, децентрализованные, и каждый, как танцор, выстраивает свой танец, взаимодействуя с другими. На уровне бизнеса схемы одинаковы, а вот на технологическом уровне — это разные процессы.
Сложности интеграции
В любой интеграции самый сложный момент — наладить грамотно и чётко взаимодействие между системами, не уменьшая их производительности и не снижая качества сервисов. По словам Романа Можаева, так было и в случае «МигКредит»: сложнее всего оказался маппинг между системами, где шина служит транспортом для переноса информации.
На этапе запуска глобальных проектов, после внедрения обращений в службу технической поддержки много: возникают инциденты, дефекты, запросы на доработку. А вот на этапе стабильной работы практически никакие изменения в систему не вносятся. Для финансовой организации есть и такая специфика: в конце года, в период высоких продаж, изменений в коде лучше избежать.
Так когда нужна шина?
Продумывая ИТ-разработки, отталкиваться нужно всегда от имеющихся бизнес-потребностей и стараться точнее предсказать будущее: вашему предприятию может потребоваться шина через несколько лет, даже если она не нужна сейчас. Возможно, стоит сразу заложить в свою архитектуру шаги для будущего перехода — в «МигКредит» поступили именно так.
Перед внедрением технологии всегда важно верно оценить затраты, которые предприятие готово понести на начальном этапе. Многие аналитические компании, такие как Forrester и IDC, отмечают: более половины провалов проектов вне зависимости от масштабов компаний объясняются недооценкой сложности интеграции.
Шина не панацея. Уместность её применения зависит от конкретных случаев: так, она однозначно подходит для разрозненных приложений, работающих с огромными массивами данных, или там, где нужно осуществлять много мелких итераций приложений между собой (например, XML).
В случае высококонкурентного бизнеса потребность в интеграционной шине диктуется необходимостью изменений бизнес-модели. Более статичный бизнес позволяет отложить такое решение: иногда вместо внедрения шины достаточно привлечь одного дополнительного сотрудника для закрытия возникших потребностей.
В последние годы всё больше запросов на интеграцию исходит от бизнеса. Часто речь идёт об инициативах запуска приложений в новых средах, интеграции с возможностями мобильного устройства — то есть о задачах фронт-офиса, а задачи бэк-офиса уже так или иначе решены.
Открытый исходный код: спасение или угроза?
Многие пользователи опасаются открытых платформ, ведь это может означать недостаточную защищённость данных. Здесь важна репутация разработчика.
Компания, много лет присутствующая на рынке, отвечает за то, что делает.
У неё есть внутренние разработчики, архитекторы, предразработка — код много раз проверяется. Роман Можаев подчёркивает, что особенно важно это для финансовой компании, ведь клиенты «МигКредит» — физлица с персональными данными. Решения, которые применяет компания, защищены и не допускают утечек.
Open-source как бизнес-модель, приносящая клиентам инновации, выигрывает. Продакт-менеджеры постоянно находятся в интернациональном сообществе разработчиков, черпая оттуда инновации, когда новый код возникает в ответ на бизнес-потребность — и в этом разительное отличие от проприетарных конкурентов и последователей. Компания-клиент иногда не может себе позволить штат даже из 50 программистов — а так она получает доступ к сотням тысяч специалистов. В современных экономических условиях это особенно важно.
Считаем затраты
Единственное, что может повлиять на интеграционные затраты, и не всегда в сторону роста, — потребности вашей компании. Например, автоматизация процессов с повторным использованием существующих технологий существенно снизит затраты и поспособствует быстрому появлению новых процессов, как и было у «МигКредит». А вот внутренних сотрудников, которые занимаются поддержкой и разработкой шины, у компании нет, всё на аутсорсе — это выгоднее.
В прежней системе 80% процентов затрат уходило на ИТ, на бизнес-задачи оставалось 20%. Во внутренней экосистеме интегрированных информационных сервисов, наоборот, 20% расходов тратится на поддержку и общие сервисы, а 80% — на то, что нужно бизнесу.
В целом, на начальном этапе выше затраты на непосредственное внедрение, чем на поддержку, а вот затем поддержка может разрастись, поскольку увеличивается количество процессов, а затраты на разработку могут сократиться.
Ярослав Макаров
Директор по развитию бизнеса ГК Аплана
